Three years ago, the Infrastructure as Code conversation was effectively settled. You used Terraform. You argued about modules and remote state and occasionally workspaces, but the tool was the default and everyone moved on to more interesting problems.
That consensus is gone. HashiCorp’s license change and subsequent acquisition by IBM cracked the foundation. OpenTofu forked. Pulumi has gained real traction in engineering-heavy organizations. Crossplane offers a different philosophy entirely. And platform teams are now making a choice they had not seriously considered for nearly a decade.
This piece lays out the landscape as it stands in 2026, and offers a decision framework based on team skills, existing estate, and what actually breaks when the tool is put under real scale.
The landscape, briefly
Terraform (HashiCorp, now IBM)
Still the largest installed base. License is now Business Source License, which restricts competitive hosting but does not affect the overwhelming majority of users. The module ecosystem remains the richest of any IaC tool. Development velocity has slowed somewhat since the acquisition, though the core product is stable and well-supported.
OpenTofu (Linux Foundation fork)
Fork of Terraform 1.5, governed by the Linux Foundation. MPL-2.0 license. Drop-in compatible with Terraform for the majority of real-world configurations. Active community, increasing corporate contributions, and a roadmap that has begun to diverge slightly from Terraform in ways that favor state management and policy features. The migration path from Terraform is effectively a command rename for most estates.
Pulumi
Infrastructure as code in general-purpose programming languages — TypeScript, Python, Go, C#. Not a domain-specific language. You get loops, conditionals, functions, unit tests, and your IDE’s full tooling. The cost is that you have to treat infrastructure code like any other code, which some organizations view as a feature and others as a risk.
Crossplane
Kubernetes-native infrastructure provisioning. You define infrastructure as Kubernetes custom resources and a controller reconciles the desired state. Philosophically closer to GitOps than to traditional IaC. Excellent when Kubernetes is already your control plane. Awkward when it is not.
The decision axes that actually matter
Most comparison articles rank these tools on feature matrices. We find feature matrices misleading because the features that matter depend heavily on who is using the tool and what they have already built. The four axes below tend to resolve the question in practice.
Team fluency
A team of platform engineers who have written Terraform modules for five years will be dramatically more productive in OpenTofu than in Pulumi, even if Pulumi is the objectively more capable tool. A team of software engineers assigned to own infrastructure for the first time will usually be more productive in Pulumi, because it speaks a language they already know. The tool that wins is the one your team can ship with on day one.
Existing estate and module ecosystem
If you already have thousands of lines of Terraform modules in production, migrating to Pulumi is a project. It is a doable project, but a project. Migrating to OpenTofu is not a project — it is a command substitution. If you are greenfield, the ecosystem differences matter less. If you are brownfield, they usually dictate the answer.
State management at scale
All three of Terraform, OpenTofu, and Pulumi use a state file. At single-team scale this is fine. At five-hundred-engineer scale it becomes the single most important operational concern. State file locking, splitting, drift detection, and recovery from partial-apply failures are the differences between an IaC program that works and one that requires a dedicated on-call rotation. Crossplane sidesteps this by making Kubernetes the state authority, which is either elegant or a different set of problems depending on your Kubernetes maturity.
Policy-as-code integration
Mature infrastructure programs run policy checks against IaC before apply. Sentinel, OPA, Checkov, and similar tools integrate differently across these platforms. Terraform and OpenTofu have the richest policy tooling. Pulumi’s policy-as-code is capable but a smaller ecosystem. Crossplane inherits Kubernetes admission controllers, which is a powerful model if you have invested in it.
What actually breaks at scale
The failure modes differ by tool, and the list below reflects what we have seen break in real production environments as team size crossed the hundred-engineer mark.
- Terraform and OpenTofu: state file fragmentation, module versioning coordination, provider upgrade coordination, and the occasional corrupt state recovery. The community tooling for these problems is mature, but the problems are inherent to the model.
- Pulumi: the flexibility that comes with general-purpose languages becomes the liability. Teams build abstractions that other teams cannot read. “Infrastructure code as regular code” means regular-code problems — bad abstractions, over-engineered inheritance hierarchies, and the occasional circular dependency.
- Crossplane: if Kubernetes has problems, Crossplane has problems. Control plane performance, CRD proliferation, and reconciliation storms all show up under load. The compensation is that the problems have Kubernetes-shaped solutions.
A practical recommendation
For most organizations making a fresh decision in 2026, the answer is one of three:
OpenTofu for greenfield or migration. If you are starting new, or if you are on Terraform and considering your next move, OpenTofu is the default. The ecosystem is the same, the license is permissive, and the governance model removes the commercial risk. The community has momentum.
Pulumi for software-engineering-first teams. If your infrastructure is being managed by product engineers rather than a dedicated platform team, and those engineers think in code rather than in configuration, Pulumi will produce better results faster. The risk is governance — make sure you have someone whose job is to prevent infrastructure code from turning into an unbounded Python project.
Crossplane only if Kubernetes is the control plane. If your platform is Kubernetes-first, if your developers already deploy applications via GitOps, and if the idea of infrastructure-as-custom-resource aligns with how you already think, Crossplane is excellent. If you are adopting Kubernetes specifically so you can use Crossplane, reconsider. That is solving one problem by creating three.
What to stop arguing about
Two things we see teams argue about that rarely affect the outcome.
First, performance. All four tools are fast enough for the vast majority of estates. If your plan-and-apply cycle is slow, the cause is almost always state file size or provider API throttling, not the tool itself. Changing tools will not fix this.
Second, DSL purity. The argument about whether HCL is a “real” language or whether general-purpose languages are “too dangerous” for infrastructure is a distraction. Both models work. What fails is underspecified ownership and weak review practices. Neither of those is a tool choice.
The tool is the smallest part of a functioning IaC program. Pick one your team can ship with, invest in the operating practices around it, and revisit the choice only when you hit a concrete scaling wall. Most organizations never do.
Top comments (0)