OpenTofu vs Terraform vs Pulumi: Which IaC Tool to Choose

The short answer

All three tools describe infrastructure as code, compare it with the real state and apply the difference. The main differences are license, language and ecosystem:

• Terraform — the original HCL-based tool from HashiCorp, now under the Business Source License (BSL).
• OpenTofu — a community fork of Terraform under the Linux Foundation, open source (MPL 2.0), largely compatible with Terraform configurations.
• Pulumi — infrastructure in general-purpose languages: TypeScript, Python, Go, C#, Java, plus YAML. The engine is open source (Apache 2.0).

If your team already knows HCL, the choice is mostly between Terraform and OpenTofu. If your developers want loops, types and tests in a familiar language, look at Pulumi.

Licensing after the Terraform change

In 2023 HashiCorp moved Terraform from the open-source MPL license to the BSL. For most companies that use Terraform to manage their own infrastructure, nothing changed in practice. The restriction concerns products that compete with HashiCorp's commercial offerings, for example a hosted Terraform automation service.

What this means for you:

• Using Terraform internally is generally allowed, but read the license with your legal team if you build a platform or service on top of it.
• OpenTofu was created as a response: open source, governed by a foundation, with the same workflow.
• Pulumi's core is open source; the managed Pulumi Cloud is a commercial service, but you can use self-managed state backends instead.

HCL vs general-purpose languages

HCL (Terraform, OpenTofu)

• Declarative and readable, even for people who do not write code daily.
• Limits creativity, which keeps configurations predictable.
• Loops and conditions exist (for_each, count, expressions), but complex logic gets awkward.

General-purpose languages (Pulumi)

• Real functions, classes, types, package managers and unit tests.
• Easy to build reusable components for many teams.
• The risk: infrastructure code can become as complex as application code. You need the same discipline as for a regular codebase.

Comparison table

State handling

All three keep a state file that maps code to real resources. Basic rules apply everywhere:

• Store state remotely (object storage or a managed service), never only on a laptop.
• Enable locking so two people cannot apply changes at the same time.
• Treat state as sensitive: it can contain passwords and keys. Restrict access and encrypt it.
• Split state by environment and by component, so one mistake does not touch everything.

Migration effort

• Terraform to OpenTofu: usually the smallest step. For compatible versions you install the tofu binary, run tofu init and verify that tofu plan shows no changes. Check features that were added in only one of the tools after the fork.
• Terraform to Pulumi: more work. Pulumi offers a converter from HCL and can import existing resources, but you still review generated code, rebuild modules as components and retrain the team.
• Any tool switch: start with a non-critical environment, compare plans carefully, and keep a backup of the state.

# Check that OpenTofu sees the same infrastructure
tofu init
tofu plan

How to choose by team profile

• Ops-focused team, existing Terraform code, uses HCP Terraform — stay on Terraform.
• Ops-focused team that values open source or builds a platform for others — OpenTofu.
• Product developers who own their infrastructure, strong TypeScript or Python skills — Pulumi.
• Small team starting from scratch — pick the language your people already know; the ecosystems are mature enough either way.
• Large organization — standardize on one tool and invest in shared modules or components.