The Monday morning standup turned tense when Alex, the operations lead, projected an email onto the conference room screen. IBM’s Terraform Enterprise renewal notice showed a 40% price increase over last year. Three seconds of silence, then chaos.
“I told you we should have jumped ship the day HashiCorp switched to BSL,” Marcus, the backend lead, was first to speak.
“Jump to where? We’ve written three years of HCL, hundreds of modules. You think we can just migrate on a whim?” Alex shot back.
“Doesn’t OpenTofu let you move without changing a single line of code?”
“What about Terraform Cloud’s state management and policy checks? Who handles those if we switch to OpenTofu?”
This conversation is playing out in countless engineering teams across 2026. A year has passed since IBM’s $6.4 billion acquisition of HashiCorp, and while Terraform’s commercial strategy remains uncertain, the bills have already arrived. The options on the table have never been more numerous, and never more paralyzing.
The Most Direct Escape Route: OpenTofu
If your pain point is purely about licensing and pricing, OpenTofu offers the path of least resistance.
This Linux Foundation-backed fork of Terraform launched its GA release in January 2024 and became a CNCF Incubating project by 2026. Its promise is straightforward: 100% compatibility with existing Terraform code, forever open source. Swap the terraform command for tofu, leave your .tf files untouched, and read your state files directly. For teams with hundreds of modules and dozens of pipelines, this zero-friction migration is often the only realistic short-term option.
But OpenTofu solves the question of “who owns this tool,” not “is this tool good enough.” The expressive ceiling of HCL remains unchanged. While the provider ecosystem is shared, development velocity has begun to diverge, with contributor attention split between two projects. Teams choosing OpenTofu typically reason this way: shed the licensing risk first, address everything else later.
In practice, many companies have CI/CD pipelines with hardcoded terraform binary paths, version locks, and provider mirror addresses. What looks like a simple command swap actually requires hunting down dependencies in every pipeline. If you relied on Terraform Cloud’s remote execution, you’ll need to self-host or purchase an alternative remote execution environment. These hidden costs don’t appear in official migration docs, but they’ll consume two to three weeks of your team’s time.
Rethinking Infrastructure with Code Primitives: Pulumi
Marcus later told me privately that what he really wanted to push was Pulumi.
“Have you ever seen HCL for batch-creating VPCs with a for loop? That mess of count and for_each becomes unreadable after three months.” He opened VS Code to show me infrastructure code written in TypeScript. Functions, type inference, conditional logic, unit tests, identical to writing application code.
Pulumi has been betting on this approach since 2019: describe infrastructure using real programming languages like TypeScript, Python, Go, and C#. By 2026, its biggest differentiation has become AI integration. Pulumi AI generates infrastructure code from natural language descriptions, while Pulumi Insights uses AI to analyze your cloud resource topology and suggest optimizations. For teams already staffed with software engineers, this eliminates the cognitive overhead of learning a DSL.
What’s the tradeoff? Ecosystem coverage and team fragmentation. Terraform providers cover nearly every cloud service and SaaS platform. While Pulumi can bridge Terraform providers, its native provider count and maturity still lag. If your stack includes obscure cloud services or internal systems, you might hit walls. The more subtle issue is internal team dynamics: operations-oriented engineers think declaratively, while developer-oriented engineers prefer imperative logic. Pulumi naturally favors the latter, potentially creating a new skill divide within your team.
The Battle for the Control Plane: Spacelift and env0
Alex’s real concern wasn’t about which language to write IaC in. It was about who manages execution flow. Everything Terraform Cloud does (remote state, plan approval, policy checks, drift detection, cost estimation) vanishes in a bare OpenTofu setup.
This is precisely where Spacelift and env0 enter. They’re fundamentally orchestration and governance platforms for IaC, agnostic to the underlying engine.
Spacelift’s selling point is exceptionally granular policy-as-code. Using Open Policy Agent, you can write rules down to “this team can only create t3.medium instances or smaller in us-east-1.” Its drift detection periodically scans for divergence between actual and declared state, automatically generating remediation plans. For compliance-heavy industries like finance and healthcare, this is table stakes. A typical scenario: someone manually modifies a security group rule through the console at 3 AM to troubleshoot an incident. The next day, Spacelift detects the drift and prompts you to either revert or accept the change.
env0 takes a different direction: developer self-service. It lets teams provision environments through a catalog interface, with IaC code, approval workflows, and cost budgets pre-configured behind the scenes. Imagine a new developer clicking two buttons to spin up a complete staging environment, no need to queue with SRE for three days. env0 also invests heavily in cost management. Every plan displays estimated cost changes, and you can set budget caps that automatically reject applies when exceeded. For teams whose cloud bills regularly overshoot and whose finance departments constantly chase DevOps for reconciliation, this feature alone justifies the investment.
Both platforms support Terraform, OpenTofu, Pulumi, and even CloudFormation as underlying engines. The logic for choosing them: IaC engines are replaceable, but the control plane is a long-term investment.
The Kubernetes Purist Route: Crossplane
There was another voice in the room, from Sam, the Kubernetes specialist. His perspective was more radical: if everything ultimately runs on K8s, why not manage cloud resources the Kubernetes way?
Crossplane models every cloud resource as a Kubernetes CRD. An RDS instance becomes a YAML manifest. Apply it to the cluster, and the Crossplane controller calls AWS APIs to provision it. State lives in etcd, reconciliation loops natively handle drift, and GitOps tooling (ArgoCD, Flux) gets reused directly. For teams already managing application deployments with GitOps, infrastructure management can leverage the same PR review and auto-sync workflows, eliminating the need to maintain a separate IaC pipeline.
This sounds elegant, provided your team has deeply embraced Kubernetes. If your operators are fluent in the K8s operator pattern, Crossplane will feel natural. But if some team members barely know kubectl, forcing Crossplane adoption creates new knowledge barriers. The learning curve isn’t the tool itself. It’s the entire K8s ecosystem’s mental model. You need to understand controllers, reconciliation, finalizers, and composition before you can troubleshoot effectively.
The Comparison Table
| Dimension | OpenTofu | Pulumi | Spacelift | env0 | Crossplane |
|---|---|---|---|---|---|
| Positioning | Open source Terraform alternative | General-purpose language IaC | IaC orchestration platform | IaC self-service + cost mgmt | K8s-native resource mgmt |
| Language | HCL | TS/Python/Go/C# | Agnostic (orchestration layer) | Agnostic (orchestration layer) | YAML (K8s CRD) |
| Migration Cost | Very low | Medium-high (rewrite) | Low (wraps existing code) | Low (wraps existing code) | High (new paradigm) |
| License | MPL 2.0 | Apache 2.0 | Commercial | Commercial | Apache 2.0 |
| Best For | Existing TF users escaping BSL | Software engineering teams | Compliance-driven orgs | Dev self-service needs | Deep K8s teams |
| State Management | Self-hosted/S3/PG | Pulumi Cloud/self-hosted | Built-in | Built-in | etcd (K8s) |
| AI Capabilities | Community exploration | Native integration | Limited | Limited | None |
What Nobody Tells You
The variable most easily overlooked in these discussions is team cognitive load. All five tools solve “manage cloud resources,” but they impose radically different cognitive demands. OpenTofu requires HCL fluency, Pulumi requires programming expertise, Crossplane requires K8s mastery, Spacelift and env0 require understanding platform engineering philosophy.
Another overlooked factor is that lock-in is simply shifting layers. Teams used to fear AWS lock-in, then Terraform lock-in. Now, if you choose Spacelift or env0, the lock-in point moves to the orchestration layer. Every choice just relocates the dependency. What you can control is choosing a lock-in position you’re willing to bear.
There’s also a practical reality: these tools aren’t mutually exclusive. Many teams simultaneously use OpenTofu for underlying declarations, Spacelift for orchestration governance, and Crossplane for K8s-side resources. The complexity of tool combinations is itself a cost, but for organizations of sufficient scale, letting different sub-teams choose tools that fit them best while converging approval and compliance through a unified control plane turns out to be the path of least resistance.
Alex’s final decision was to run a two-week proof of concept: OpenTofu to verify compatibility with existing code, while Marcus rewrites infrastructure for a new project in Pulumi. Two paths in parallel, then review the data after three months.
This is probably the most honest answer for 2026. No tool is a silver bullet, but at least now you have choices. Three years ago, when Terraform dominated alone, there wasn’t even the opportunity to choose. And choice itself is the greatest gift open source ecosystems give engineers.
Stay updated with our latest AI insights
