Infrastructure as Code changed how teams manage cloud resources. But the IaC landscape shifted dramatically in 2024 when HashiCorp switched Terraform to a Business Source License, which sparked the OpenTofu fork and pushed many teams to reconsider their options.
I have used all three — Terraform, Pulumi, and OpenTofu — in production environments over the past year. Here is an honest comparison for teams deciding which direction to take in 2026.
The State of IaC in 2026
Terraform still dominates by market share, but the BSL license change created genuine uncertainty for companies building products on top of it. OpenTofu emerged as the community-maintained fork under the Linux Foundation, and Pulumi has gained significant ground by letting developers use real programming languages instead of HCL.
Your choice comes down to three factors: language preference, ecosystem maturity, and how much you care about licensing.
Terraform
Terraform is the incumbent. The provider ecosystem is unmatched — over 3,000 providers covering every major cloud service, SaaS platform, and infrastructure component you can think of. If you need to manage a niche AWS service or configure a third-party tool, there is probably a Terraform provider for it.
HCL (HashiCorp Configuration Language) is a love-it-or-hate-it choice. It is declarative, which means you describe what you want and Terraform figures out how to get there. For straightforward infrastructure — VPCs, EC2 instances, RDS databases — it works well. The syntax is readable even for people who do not write it daily.
Where HCL struggles is complex logic. If you need conditional resources, dynamic blocks, or loops with transformations, the syntax gets awkward fast. The for_each and dynamic blocks work but are not intuitive, and debugging plan errors in complex modules can be frustrating.
The BSL license is the elephant in the room. For most end users, the license change does not matter — you can still use Terraform to manage your own infrastructure. It only restricts companies building competing commercial products. But the principle bothered many in the community, and the risk of future license changes is real.
Terraform Cloud and Terraform Enterprise are solid if you want managed state, policy enforcement, and a UI for your team. The pricing model is per-resource, which scales predictably. If your team is already running CI/CD through GitHub Actions, Terraform integrates cleanly into deployment pipelines.
Best for
Teams already invested in the Terraform ecosystem who value provider breadth and community resources. If your infrastructure is complex enough to need modules from the registry, Terraform is still the safest bet.
Pulumi
Pulumi lets you write infrastructure in Python, TypeScript, Go, C#, or Java instead of a domain-specific language. If you have ever wished you could use a for loop, an if statement, or import a library while defining infrastructure, Pulumi is the answer.
This is a genuine advantage for development teams. Your infrastructure code lives in the same language as your application code, uses the same IDE support, the same testing frameworks, and the same package managers. You can write unit tests for your infrastructure with pytest or Jest and run them in the same CI pipeline.
In my experience, Pulumi shines in two scenarios: complex infrastructure with lots of conditional logic, and teams where developers (not dedicated DevOps engineers) manage infrastructure. A Python developer can be productive with Pulumi in an afternoon. Teaching the same developer HCL takes longer.
The provider ecosystem is good but not at Terraform’s level. Pulumi can use Terraform providers through a bridge layer, which covers most gaps, but the bridged providers sometimes lag behind the native Terraform versions.
State management is handled through Pulumi Cloud (free for individuals, paid for teams) or self-managed backends like S3. The built-in secrets management is a nice touch — secrets are encrypted in state by default, which is something Terraform requires additional tooling for.
Best for
Development teams that want to write infrastructure in a real programming language and value testability. Especially strong for Python and TypeScript shops. Pairs well with container orchestration setups where infrastructure complexity is high.
OpenTofu
OpenTofu is the Linux Foundation’s community fork of Terraform, created in response to the BSL license change. It is fully compatible with Terraform 1.5.x — your existing Terraform code, providers, and state files work without modification.
The pitch is straightforward: it is Terraform without the licensing risk. Same HCL syntax, same provider ecosystem, same workflow. You can migrate by swapping the binary and running tofu init. In my testing, migration took under 10 minutes for a project with 200+ resources.
OpenTofu has started diverging from Terraform with its own features. State encryption is the headline addition — you can encrypt your entire state file at rest, which Terraform does not support natively. Client-side state encryption is a significant security improvement for teams that self-manage state in S3 or similar backends.
The concern with OpenTofu is long-term viability. The Linux Foundation backing provides stability, but the project needs sustained community contribution to keep pace with cloud provider changes. So far, the contribution rate has been healthy, but it is still a younger project than Terraform.
Provider compatibility is excellent since OpenTofu uses the same provider protocol. Every Terraform provider works with OpenTofu, and the registry mirrors are maintained by the community.
Best for
Teams that want Terraform’s functionality without the licensing risk. If you are starting a new project and have no existing Terraform investment, OpenTofu is the pragmatic choice — same capabilities, truly open source. Also essential if you are managing sensitive infrastructure where security best practices demand state encryption.
Verdict
OpenTofu is my recommendation for new projects. It is functionally equivalent to Terraform with better licensing terms and the state encryption feature alone is worth the switch.
Pulumi is the best choice if your team prefers real programming languages over HCL, or if your infrastructure logic is complex enough that HCL becomes painful.
Terraform remains a solid choice if you are already invested in the ecosystem, use Terraform Cloud, or depend on modules and providers that have not been tested with OpenTofu. Migration is easy if you change your mind later.
Whatever you choose, pair it with proper network security and a CI/CD pipeline that plans and applies changes through code review, not manual runs.
About Brian Detering
Brian Detering is a software engineer, educator, and tech writer based in Los Angeles. He teaches programming and software engineering at the University of Southern California, where his work spans programming languages, systems architecture, and applied AI. With over a decade of hands-on experience building production systems, Brian writes about the tools and workflows that actually make developers more productive — from CI/CD pipelines and containerization to API testing and security best practices. When he's not teaching or writing code, he's usually benchmarking the latest dev tools or tinkering with homelab infrastructure.
