Pick Terraform if you want the largest ecosystem and hiring pool and the BSL does not restrict you; pick OpenTofu for the same HCL workflow under an open-source license and Linux Foundation governance, with a near drop-in migration; pick Pulumi when software engineers want a real language and native testing. All three are production-grade.
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 (the fork's reasoning is laid out in the OpenTofu manifesto), 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
| Dimension | Terraform | OpenTofu | Pulumi |
|---|---|---|---|
| Authoring language | HCL (declarative DSL) | HCL, compatible with Terraform | TypeScript, Python, Go, C#, Java, YAML, HCL |
| License | Business Source License 1.1 (source-available; relicensed from MPL 2.0 in Aug 2023) | MPL 2.0 (open source) | Apache 2.0 (open source); open-core with Pulumi Cloud |
| Governance & backing | HashiCorp, now an IBM company; single vendor | Linux Foundation; open, vendor-neutral governance | Pulumi Corp; single VC-backed vendor, permissive core |
| First released | 2014 | 2023 (fork of Terraform 1.5.x) | 2018 |
| State management | State file + remote backends; HCP Terraform | Same backends, plus client-side state encryption | Pulumi Cloud by default or self-managed backends; secrets encrypted |
| Provider / module ecosystem | Largest; Terraform Registry | Same providers and modules via its own registry | Bridges Terraform providers + native providers |
| Testing story | terraform test (HCL) with provider mocking, Terratest, Sentinel/OPA | Test framework with provider mocking, OPA | Native unit tests, property tests, CrossGuard policy |
| Maturity & community | De facto standard; largest community and hiring pool | Young but growing fast; broad corporate backing | Established since 2018; smaller, engineer-heavy community |
| Migration effort | Baseline | Low; near drop-in from Terraform 1.5.x | Higher; rewrite in a real language, converter assists |
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, first released in 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 hosted state-and-secrets backend, free for individuals and paid for teams. 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. As of August 2026, Pulumi also supports HCL as a first-class Pulumi language, so choosing Pulumi no longer strictly means leaving HCL behind.
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, completed in February 2025, 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 both; Terraform added it in v1.7) 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.
What does each one cost, and what does the license allow?
The cost question splits in two: what the license lets you do with the tool, and what the optional managed service charges for state, runs, and governance. The license terms below come from each project's own LICENSE file; plans and prices are as listed on 2026-10-03, and vendors change them, so check the linked page before you budget.
| Dimension | Terraform | OpenTofu | Pulumi |
|---|---|---|---|
| License | Business Source License 1.1 for Terraform 1.6.0 and later; the licensor is now IBM | Mozilla Public License 2.0, the license Terraform used before August 2023 | Apache License 2.0 |
| What the license allows | Production use, unless you offer Terraform to third parties on a hosted or embedded basis to compete with IBM’s paid versions; internal use within an organization is not a competitive offering. Each version converts to MPL 2.0 four years after it is published. | Open source, with no competing-use restriction | Open source and permissive; Pulumi Cloud is a separate, optional service |
| Governance | HashiCorp, an IBM company | Linux Foundation project since September 2023; accepted into the CNCF at Sandbox level on April 23, 2025 | Pulumi Corp |
| Managed service | HCP Terraform | None required; free, using the same remote backends as Terraform | Pulumi Cloud (the default backend; self-managed backends supported) |
| How the service bills | Per managed resource, per hour; a partial hour is billed as a full hour | No vendor bill; you pay for the storage behind your backend | Per resource-hour beyond each plan’s included credits; a partial resource hour is billed as a full hour |
| Plans | Free up to 500 managed resources; Essentials is pay-as-you-go per managed resource; Standard and Premium are priced through HashiCorp sales | — | Free at $0 for 1 user; Essentials $40/month (up to 500 managed resources); Pro $400/month (up to 2,000); Enterprise $2,000/month (up to 4,750, self-hosting available) |
Two things follow. First, the BSL text itself backs up the point above: using Terraform for internal purposes within your own organization is not a competitive offering, so for most end users the license is a non-issue. Second, both paid services meter managed resources by the hour, so the bill grows with the number of resources you manage; OpenTofu has no vendor bill at all.
Which one should you choose?
A pragmatic decision framework, and yes, this is the section most people scroll to:
| Choose | If | Trade-off you accept |
|---|---|---|
| Terraform | 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 | A source-available license and a single corporate owner |
| OpenTofu | Your legal team is uneasy about a source-available license, you build tooling that could be read as competing with HashiCorp, or you want open governance and features like state encryption | The two projects have diverged since 2023, so pin versions and test before you cut over |
| Pulumi | Software engineers own your infrastructure and want a real language, native unit tests, and rich internal abstractions, especially if you have standardized on TypeScript, Python, Go, or .NET | Infrastructure code that can grow as complex as application code, a smaller community, and a bigger migration |
| Stay on Terraform | You already run Terraform for your own infrastructure and none of the above applies | Nothing new: most end users are unaffected by the license, and there is nothing wrong with staying put |
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
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 · Terraform consulting · Cloud engineering · Cloud cost & FinOps · DevOps vs SRE vs Platform Engineering · DevOps consulting rates · All services