When managing a multi-cloud setup with minimal vendor lock-in, the choice generally comes down to three top contenders. True "cloud-agnosticism " is a myth because cloud providers use completely different underlying APIs, but these tools minimize the tooling lock-in and make shifting or combining providers as painless as possible.
The three leading Infrastructure-as-Code (IaC) tools mapped to this goal are compared below:
OpenTofu
What it is: The open-source, community-driven fork of Terraform managed under the Linux Foundation.
Vendor Lock-in Risk:Very Low. Because it is entirely open-source (free from HashiCorp’s Business Source License restrictions) and acts as a drop-in replacement for Terraform, you aren’t bound to a single commercial vendor's roadmap or sudden pricing changes.
Multi-Cloud Strengths: Features thousands of community and official providers (AWS, Azure, GCP, Kubernetes). You write declarative HCL to orchestrate resources across multiple clouds using a unified workflow.
What it is: An IaC tool that lets you write infrastructure using real, general-purpose programming languages (TypeScript, Python, Go, C#).
Vendor Lock-in Risk:Low to Moderate. The core engine and SDKs are open-source, though advanced enterprise features (like their managed service/state backend) are commercial. However, because you use real programming languages, you can abstract multi-cloud components into clean software packages and easily migrate logic if needed.
Multi-Cloud Strengths: Excellent for complex multi-cloud logic. You can use native loops, classes, and conditionals to spin up interdependent resources across AWS and GCP in a single program, enjoying strong IDE type-checking.
Crossplane
What it is: A Kubernetes-native control plane extension that turns your Kubernetes cluster into a universal API manager for cloud infrastructure.
Vendor Lock-in Risk:Lowest (Architecturally). It decouples your infrastructure definitions from specific cloud APIs by letting you define custom composite resources. Your developers deploy a generic "database," and Crossplane translates it to AWS RDS or Google Cloud SQL behind the scenes.
Multi-Cloud Strengths: Ideal if you are already heavily invested in a Kubernetes workflow and want continuous infrastructure reconciliation across multiple clouds without relying on external CI/CD pipelines.
To help narrow down the best fit, tell me:
What programming languages does your team know best (HCL, TypeScript, Python, etc.)?
Are you already running workloads inside Kubernetes?
Real programming languages; excellent developer experience
State/tooling can create more ecosystem dependence
Crossplane
Excellent
Low
Kubernetes-native control planes and platform engineering
Much heavier than traditional IaC
Why OpenTofu
OpenTofu separates the IaC engine from the cloud providers: providers are plugins, and the public registry supports providers for major infrastructure platforms. That makes it a good fit for an architecture spanning AWS, Azure, GCP, Kubernetes, SaaS APIs, etc.
It also gives you a relatively portable Terraform-compatible configuration model. Provider configurations are explicitly passed into modules, so you can structure reusable modules independently of a particular cloud account or region.
Most importantly for your criterion, you don't need to make a proprietary hosted control plane the center of your architecture. You can run OpenTofu yourself and control the state/backend and provider installation.
Where I'd choose the others
Pulumi is compelling if your engineering team strongly prefers TypeScript, Python, Go, Java, or .NET over HCL. It supports AWS, Azure, GCP, Kubernetes and many other providers, and you can use your own S3/Azure Blob/GCS/Postgres/local backend rather than Pulumi Cloud.
Terraform remains a very reasonable choice if ecosystem maturity and existing organizational expertise outweigh the desire to minimize dependence on a particular vendor. Its provider/version-locking model is well established.
Crossplane is different: I'd use it when you're building an internal developer platform where Kubernetes is the control plane, rather than simply wanting conventional IaC. Crossplane continuously reconciles desired state and can manage resources across cloud APIs.
My recommendation
For a new multi-cloud environment:
OpenTofu + cloud-native providers + self-managed/object-storage state + CI/CD
That combination gives you a strong balance of portability without giving up the mature declarative IaC model that made Terraform popular.
One important caveat: no IaC tool can eliminate cloud lock-in at the resource level. If your configuration says "create an AWS Lambda with these AWS-specific properties," the infrastructure itself is still AWS-specific. The practical goal is to avoid tool/vendor lock-in while keeping cloud-specific modules isolated behind clean interfaces.
