OpenTofu has a narrow lead for managing multi-cloud infrastructure with minimal vendor lock-in, with Pulumi close behind. Crossplane is also named among the three tools considered for this setup.
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.
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.[](https://www.envzero.com/blog/iac-tools-for-cloud-automation)
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.
If you want an Infrastructure as Code (IaC) solution that works across AWS, Azure, Google Cloud, and potentially private cloud or on-premises infrastructure without locking your architecture into one provider, I'd focus on tools that support multiple providers, declarative infrastructure, and portable workflows.
The key distinction is that multi-cloud support isn't the same as cloud independence. A tool can manage three cloud providers while your configuration still depends heavily on provider-specific services and APIs.
Best IaC options for multi-cloud
1. OpenTofu
(Best for open-source independence)
An open-source, Terraform-compatible IaC tool with providers for AWS, Azure, GCP, Kubernetes, and many other platforms. Its provider-based model lets you manage different services in a consistent workflow.
Strengths: Declarative HCL configuration, reusable modules, broad provider ecosystem, and control over where you run your tooling.
Trade-offs: Each cloud still has its own resource types, APIs, and quirks.
Best for: Teams that want a mature IaC workflow without depending on HashiCorp's Terraform licensing and product ecosystem.
Define infrastructure using TypeScript, Python, Go, .NET, Java, YAML, or HCL. Pulumi supports the major cloud providers and Kubernetes, with a broad package ecosystem.
Strengths: Real programming-language features, abstractions, testing, and reusable components.
Trade-offs: Language runtimes and abstractions introduce their own complexity; optional Pulumi Cloud services may add platform dependency.
Best for: Engineering teams that prefer software development practices over a configuration-only approach.
Docs:
3. Terraform
The established option with a large ecosystem of modules, providers, integrations, and experienced practitioners.
Strengths: Broad industry adoption, mature workflows, and extensive examples.
Trade-offs: HashiCorp changed Terraform's license from MPL 2.0 to the Business Source License (BSL) starting with version 1.6.0. Review the terms and your commercial requirements before adopting it.
Best for: Organizations that value ecosystem maturity and are comfortable with HashiCorp's licensing and product direction.
Docs:
4. Crossplane
A Kubernetes-native approach that provisions and reconciles infrastructure through Kubernetes APIs, including resources managed by AWS, Azure, and GCP providers.
Strengths: Continuous reconciliation, platform engineering, self-service infrastructure, and custom abstractions for developers.
Trade-offs: Requires Kubernetes expertise and a control-plane operating model; can be excessive for straightforward infrastructure deployments.
Best for: Organizations building an internal developer platform or a standardized multi-cloud service catalog.
Docs:
Quick comparison
Capability
OpenTofu
Pulumi
Terraform
Crossplane
Multi-cloud support
Yes
Yes
Yes
Yes
Primary approach
Declarative HCL
How to avoid actual vendor lock-in
Regardless of which tool you choose, the architecture matters as much as the IaC engine.
Separate portable components from cloud-specific modules. Define common interfaces for compute, networking, storage, and identity, but allow provider-specific implementations underneath.
Prefer open standards where practical. Kubernetes, OCI containers, PostgreSQL, OpenTelemetry, and S3-compatible interfaces can reduce dependencies in selected layers.
Keep your state and automation portable. Document state recovery, backups, credentials, CI/CD pipelines, and how to run deployments independently of a vendor-hosted control plane.
Avoid pretending every cloud is identical. AWS IAM, Azure Entra ID, and Google Cloud IAM have different security models. A portable abstraction should expose those differences where necessary rather than hide them.
Test migration as a real scenario. Provision a representative workload in two providers and measure what must change, including networking, identity, managed databases, observability, and data migration.
One important caveat: no IaC tool automatically makes your infrastructure portable. OpenTofu and Terraform share a configuration lineage, but provider resources and state aren't universally interchangeable with every other IaC engine. Pulumi and Crossplane also have their own abstractions and operational considerations.
My recommendation
Choose OpenTofu if you want a strong default for multi-cloud infrastructure, open-source control, and minimal dependence on a specific IaC vendor.
Choose Pulumi if your team wants to build reusable infrastructure abstractions using familiar programming languages.
Choose Crossplane if you're building a Kubernetes-based internal platform where developers consume standardized infrastructure services.
To narrow this down, one question matters most: What kind of infrastructure are you trying to make portable?
When you want to provision and orchestrate infrastructure across multiple cloud providers (like AWS, GCP, Azure, and Cloudflare) without being locked into a single ecosystem, you need a cloud-agnostic Infrastructure as Code (IaC) tool.[](https://www.pulumi.com/blog/infrastructure-as-code-tools/)
What it is: A community-driven, truly open-source fork of Terraform, managed under the Linux Foundation. It uses the same declarative Configuration Language (HCL).[]()
How it works for multi-cloud: You use a single configuration project with multiple provider blocks (e.g., configuring an AWS VPC, an Azure Kubernetes cluster, and GCP databases side-by-side).
Why it’s a top option: It provides 100% backward compatibility with traditional Terraform modules and providers, but avoids the restrictive BUSL licensing changes that affected HashiCorp's tool. It also features native state encryption.[](https://www.pulumi.com/blog/infrastructure-as-code-tools/)
What it is: The original declarative multi-cloud provisioning tool using HCL.
How it works for multi-cloud: Features a vast registry of official and third-party providers allowing seamless orchestration across hundreds of non-cloud and cloud services simultaneously.
Why it’s a top option: Backed by IBM/Red Hat, it remains deeply entrenched in large enterprise setups, offering advanced features like Stacks for complex multi-environment management. However, its Business Source License (BUSL) means commercial competitors must navigate restrictions.
What it is: An open-source IaC tool that lets you define cloud resources using real programming languages (TypeScript, Python, Go, C#, and Java) instead of a domain-specific language like HCL or YAML.
How it works for multi-cloud: Pulumi leverages a powerful provider engine that can draw from native cloud SDKs or bridge directly into the massive Terraform/OpenTofu provider ecosystem. You can write loops, use standard functions, and build proper software abstractions across AWS and Azure in a single codebase.
Why it’s a top option: It turns infrastructure into actual software engineering, making unit testing, linting, and DRY code logic much easier for application developers.
4. Crossplane (The Kubernetes-Native Control Plane)
What it is: An open-source CNCF project that extends Kubernetes, turning your cluster into a universal control plane.
How it works for multi-cloud: You manage multi-cloud infrastructure (AWS, GCP, Azure) via Kubernetes Custom Resource Definitions (CRDs). You apply a standard Kubernetes manifest, and Crossplane reconciles the actual cloud infrastructure to match it.
Why it’s a top option: It is inherently continuous and drift-resistant because it runs an active reconciliation loop (unlike the point-in-time apply of Terraform/OpenTofu). It allows platform engineers to build internal abstraction layers for other teams.
