Three tools, one job: describe your cloud infrastructure as code so it is version-controlled, reviewable, and repeatable. Until 2023 the answer was simply "use Terraform." Then HashiCorp changed the license, the community forked OpenTofu, and Pulumi's real-programming-language approach kept winning over engineering teams. Here is the honest side-by-side that cuts through the noise.
Key takeaways
- Terraform and OpenTofu speak the same language (HCL); Pulumi lets you write infrastructure in TypeScript, Python, Go, C#, or Java.
- This comparison exists because of licensing — HashiCorp relicensed Terraform to the BSL in August 2023, and the community forked OpenTofu under the Linux Foundation.
- For most end users the BSL is a non-issue; switch to OpenTofu for open governance, licensing comfort, or features like state encryption.
- Pulumi's superpower is real testing and reuse; its risk is that infrastructure code can become as complex as application code.
- All three are production-grade — choose on your team's skills, your licensing stance, and how much you value declarative config over a general-purpose language.
The TL;DR comparison
Terraform in one paragraph
Terraform, released by HashiCorp in 2014, is the tool that made infrastructure-as-code mainstream. You describe resources in HCL, a declarative domain-specific language, run terraform plan to preview changes, and terraform apply to make them. It has the largest provider registry, the deepest documentation, the most community modules, and by far the biggest hiring pool. It is still a safe default for a greenfield project, with one asterisk: since August 2023 it ships under the Business Source License, not an open-source license. If IaC is new to your team, start with our primer on what DevOps is and where infrastructure-as-code fits in the workflow.
OpenTofu in one paragraph
OpenTofu is the community fork of Terraform, created in direct response to the license change. The initial code was forked from Terraform 1.5.x, the last version under the open-source MPL 2.0, and the project is now governed by the Linux Foundation with sponsorship from Spacelift, Gruntwork, Harness, env0, and others. It keeps HCL, the state format, and the provider ecosystem, so for most teams the tofu binary is a near drop-in replacement for terraform. Since the fork it has shipped features Terraform lacked at the time, most notably client-side state encryption and early variable evaluation. It is open source, vendor-neutral, and free.
Pulumi in one paragraph
Pulumi, generally available since 2018, takes a different bet: define infrastructure in a general-purpose programming language rather than a DSL. You write TypeScript, Python, Go, C#, or Java, using real loops, functions, classes, and package managers, and you test infrastructure with the same frameworks you use for application code. Pulumi is Apache 2.0 licensed with an open-core model; the CLI and SDKs are free, and Pulumi Cloud is the paid state-and-secrets backend. It can drive nearly the entire Terraform provider ecosystem through a bridge, so you are not giving up cloud coverage to get a real language.
Why this comparison exists now
For most of the last decade there was no real debate: Terraform was the standard. That changed in August 2023, when HashiCorp relicensed Terraform and most of its products from the open-source Mozilla Public License (MPL 2.0) to the Business Source License 1.1. The BSL is source-available, not open source: you can read, modify, and run the code, but you cannot use it to build a product that competes with HashiCorp. Within days a coalition of vendors and users forked the last MPL version as OpenTF, quickly renamed OpenTofu, and handed it to the Linux Foundation for neutral governance. In 2024, IBM announced its acquisition of HashiCorp, which concentrated Terraform's stewardship further under a single corporate owner. That is the backdrop for every "Terraform vs OpenTofu" search: the tool did not get worse, but its governance and licensing changed, and teams now have a genuine choice to make.
HCL vs a general-purpose language
This is the real fault line, and it separates the Terraform/OpenTofu camp from Pulumi. HCL is a purpose-built configuration language: declarative, constrained, and easy to review. Those constraints are a feature. A junior engineer can read an HCL module and reason about it, and the blast radius of a clever trick is limited. The cost is that complex logic gets awkward, and you lean on constructs like count, for_each, and dynamic blocks that can read like workarounds for not having a real language. Pulumi flips it: you get loops, conditionals, functions, classes, unit tests, and your language's package ecosystem. For a platform team building reusable abstractions, that is genuinely powerful. The risk is equally real: infrastructure code can grow as complex, and as buggy, as any application, and not every team wants a Turing-complete language sitting between them and production. Neither approach is wrong. They suit different teams.
State, providers, and testing
These three dimensions decide most of the day-to-day experience:
- State. All three track the real-world mapping of your resources in a state file. Terraform uses remote backends (S3, GCS, Azure Blob) or the hosted HCP Terraform; OpenTofu uses the same backends and adds client-side state encryption; Pulumi defaults to Pulumi Cloud but supports self-managed backends and encrypts secrets in state by default.
- Providers. Terraform's registry is the largest, OpenTofu consumes the same providers and modules through its own registry, and Pulumi bridges the Terraform provider ecosystem while shipping native providers too. Cloud coverage is effectively a wash across all three.
- Testing. This is where they diverge most. Terraform and OpenTofu offer an HCL-based test framework (with provider mocking in OpenTofu) plus third-party tools like Terratest and policy engines such as OPA or Sentinel. Pulumi lets you write true unit and property tests in your language's native framework and enforce policy as code with CrossGuard. If testing infrastructure like software matters to your team, that is Pulumi's strongest argument.
Which one should you choose?
A pragmatic decision framework, and yes, this is the section most people scroll to:
Choose Terraform if you want the safest, most widely understood default, the largest ecosystem and hiring pool, and commercial support from HashiCorp/IBM, and the BSL does not restrict what you do. Most end users running their own infrastructure are simply unaffected by the license, and there is nothing wrong with staying put.
Choose OpenTofu if you want everything good about Terraform without the licensing questions: open source, open governance under the Linux Foundation, a near drop-in migration path, and features like state encryption. It is the natural pick when your legal team is uneasy about a source-available license, when you build tooling that could be read as competing with HashiCorp, or when vendor neutrality is a principle you actually care about. For most teams weighing "OpenTofu vs Terraform," this is a low-risk, high-comfort switch.
Choose Pulumi if your infrastructure is owned by software engineers who want to reuse a real language, test infrastructure the way they test code, and build rich internal abstractions. It shines for platform teams and for shops already standardized on TypeScript, Python, Go, or .NET. Weigh that power against the added complexity and the smaller community before you commit. Not sure which fits your stack? That is exactly the kind of call our DevOps consulting engagements start with.
Migration effort, honestly
Terraform to OpenTofu is the easy one. Because OpenTofu forked from Terraform 1.5.x and kept the state format, most teams migrate by installing the tofu binary, pinning versions, and running a plan to confirm there is no drift. Budget a day for a small estate, more if you rely on provider features that have diverged. Terraform or OpenTofu to Pulumi is a bigger move, since you are translating HCL into a general-purpose language, but Pulumi's converter automates much of the mechanical work and can import existing state so you do not rebuild from scratch. Whichever direction you go, treat it like any migration: do it in a non-production workspace first, keep changes reversible, and expect a few surprises. Our writeup on three Kubernetes migration mistakes applies here more than you would think.
The 2026 picture
Nearly three years after the fork, the market has settled into a stable shape. Terraform remains the most-used tool and the default in most job descriptions, backed now by IBM. OpenTofu has proven it is not a flash in the pan: it ships regularly, has real corporate backing, and is the pragmatic choice for teams that want open licensing without relearning anything. Pulumi continues to win the segment that thinks of infrastructure as software. The practical takeaway for engineering leaders: there is no wrong answer among the three, only a wrong process for choosing. Decide based on your team's existing skills, your organization's stance on source-available licensing, and how much you value a general-purpose language over declarative config, then commit and standardize. Churning between tools, or letting three of them sprawl across your estate, costs far more than any difference between them, and it quietly inflates your cloud bill through duplicated, unreviewed infrastructure.
Trying to standardize your infrastructure-as-code before it sprawls across three tools and five conventions? InfraZen runs a free 30-minute architecture review that ends in honest, vendor-neutral advice on which IaC tool fits your team and how to get there without a risky big-bang rewrite. Book the review.
Related: What is DevOps? · DevOps consulting · Cloud engineering · Cloud cost & FinOps · DevOps vs SRE vs Platform Engineering · DevOps consulting rates · All services