⚖️ Terraform vs OpenTofu: Which Should You Choose in 2026?

For most of the last decade “infrastructure as code” and “Terraform” were nearly synonymous. Then in 2023 HashiCorp relicensed Terraform under the Business Source License (BSL), the community forked the last MPL-licensed release, and OpenTofu was born under the Linux Foundation. Two years on, both tools are mature, production-grade, and largely interchangeable at the HCL level — so the decision comes down to licensing posture, the specific features each project has shipped, and which ecosystem you want to bet on. This guide walks the trade-offs dimension by dimension.

Licensing and governance

This is the reason the fork exists, so it belongs first. Terraform is developed by HashiCorp (now part of IBM) under the BSL 1.1. The BSL is source-available, not open source: you can read, modify, and run the code freely, but you may not offer a product that “competes” with HashiCorp’s commercial offerings. For the overwhelming majority of teams that just use Terraform to manage their own infrastructure, the BSL imposes no practical restriction. But it does introduce legal ambiguity for consultancies, SaaS platforms, and anyone embedding the binary in a product.

OpenTofu is licensed under the Mozilla Public License 2.0 (MPL), a genuine OSI-approved open source license, and is governed by the Linux Foundation rather than a single vendor. That means no single company can unilaterally change the license again, and the roadmap is steered by a technical steering committee with multiple corporate backers. If reproducible, vendor-neutral licensing is a hard requirement — for example in regulated environments or public-sector procurement — OpenTofu is the unambiguous answer.

Winner: OpenTofu

CLI and workflow compatibility

Because OpenTofu forked from Terraform 1.5.x, the two share a near-identical command-line interface. tofu init, tofu plan, and tofu apply behave exactly like their terraform counterparts, honor the same environment variables, and read the same .tf files. Most teams migrate by aliasing the binary or swapping it in CI, and existing runbooks keep working. Provider and module blocks are unchanged; the HCL you already wrote is portable.

Divergence has crept in as both projects add features independently (more on that below), so a configuration that leans on newer Terraform-only or OpenTofu-only syntax will not be perfectly cross-compatible. But for baseline day-to-day operations the workflows are effectively the same, which is exactly what you want in a fork designed as a drop-in replacement.

Tie

State handling and backends

Both tools use the same state file format and support the same core set of remote backends: S3, Azure Blob, Google Cloud Storage, Consul, HTTP, and others. A state file written by one can generally be read by the other, which is what makes migration low-risk — you point the new binary at your existing backend and continue. Both support workspaces, state locking via DynamoDB or equivalent, and import/state mv operations identically.

Where they diverge is at the edges. Terraform’s premier state backend is HCP Terraform (formerly Terraform Cloud), a polished managed service with remote runs, policy enforcement, and a private module registry. OpenTofu relies on the same third-party backends but pairs naturally with open source orchestration layers. The raw state mechanics are a wash; the managed experience around state is where the ecosystems differ.

Tie

OpenTofu-exclusive features

OpenTofu has shipped several capabilities that Terraform (as of 2026 — check current docs) does not offer in the same form. The headline is client-side state encryption: OpenTofu can encrypt the state file and plan files at rest using a configured key provider (PBKDF2 passphrase, AWS KMS, GCP KMS, or OpenBao/Vault), closing a long-standing gap where secrets in state sat in plaintext in your backend.

Two more stand out. Early variable evaluation lets you use variables and locals in places that were previously static-only — most usefully in backend and module source blocks — so you can parameterize where state lives or which module version loads. And OpenTofu’s provider-defined functions and the -exclude flag on plan/apply give finer control over targeted operations. These features reflect the fork’s willingness to change behavior the upstream project kept conservative.

Winner: OpenTofu

Terraform and HCP ecosystem

Terraform’s advantage is the breadth and polish of the surrounding commercial ecosystem. HCP Terraform provides hosted remote runs, Sentinel and OPA policy-as-code, cost estimation, drift detection, no-code provisioning, and a well-integrated private registry — all as a managed product with enterprise support. The public Terraform Registry remains the canonical home for providers and modules, and HashiCorp’s tooling (Vault, Packer, Consul, Nomad) is designed to interoperate tightly.

There is also a long tail of vendor documentation, tutorials, certification paths, and third-party integrations that still default to “Terraform.” OpenTofu can consume the same public registry providers and modules, so the raw building blocks are shared, but the turnkey managed platform and the enterprise support relationship are Terraform’s to lose. If you want one vendor to call when something breaks, that vendor exists for Terraform.

Winner: Terraform

Comparison at a glance

Dimension	Terraform	OpenTofu
License	BSL 1.1 (source-available)	MPL 2.0 (open source)
Governance	HashiCorp / IBM	Linux Foundation
CLI & HCL	Reference implementation	Near-identical, drop-in
State format	Shared	Shared
State encryption	Not built-in	Client-side, multiple key providers
Early variable eval	Limited	Yes (backend/module source)
Managed platform	HCP Terraform	Third-party / OSS orchestration
Enterprise support	HashiCorp/IBM	Community + vendors
Registry	Terraform Registry	Consumes same registry

Which should you choose?

Choose OpenTofu if open source licensing is a genuine constraint, you want vendor-neutral governance, or you specifically need state encryption and early variable evaluation. It is the safer long-term bet for consultancies, product companies embedding IaC, and public-sector teams. Because it is a drop-in replacement, adopting it costs little even if you are undecided.

Choose Terraform if you rely on HCP Terraform’s managed runs, Sentinel policies, and enterprise support, or you are deep in the HashiCorp stack and value first-party integration. Large enterprises that want a single supported vendor and a mature commercial platform will find Terraform the path of least resistance.

Choose either if you are a mid-size team managing your own cloud infrastructure with a third-party backend and open source CI — you genuinely cannot go wrong, and you can defer the decision. Whichever way you lean, structuring your modules well matters more than the binary; our DevOps AI prompt library has prompts for generating and reviewing HCL, and you can weigh other stacks on the comparison hub. If you are also evaluating a full programming-language approach to IaC, see our companion piece, Pulumi vs Terraform.

Frequently Asked Questions

Is OpenTofu a true drop-in replacement for Terraform?

For most existing configurations, yes. OpenTofu forked from Terraform 1.5.x and preserves the CLI, HCL syntax, state format, and backend support, so teams typically migrate by swapping the binary. The caveat is that both projects have added independent features since the fork, so configurations using the newest Terraform-only or OpenTofu-only syntax will not be perfectly portable. Test in a non-production workspace before committing.

Does the BSL license actually affect my team?

Probably not, if you simply use Terraform to manage your own infrastructure. The BSL restriction targets building a competing commercial product on top of Terraform, not internal use. The teams that need to care are SaaS vendors, consultancies embedding the binary in a product, and organizations with procurement rules requiring OSI-approved open source. If you are unsure, treat it as a legal question, not just a technical one.

Can I migrate back from OpenTofu to Terraform later?

Because the state format is shared, migrating in either direction is usually low-risk for baseline configurations. The friction appears if you have adopted OpenTofu-exclusive features like state encryption or early variable evaluation, which have no direct Terraform equivalent and would need to be unwound first. Keeping your configuration to the common subset preserves maximum optionality in both directions.

Which tool gets new providers and modules first?

Both consume the same public registry, so the vast majority of providers and modules work identically on either tool. Provider releases are published by their maintainers to a shared registry rather than being gated to one CLI. Where you may see a lag is in tooling that only officially “supports” one binary, though in practice the same providers run on both.

Conclusion

Terraform and OpenTofu are more alike than different: same language, same state, same mental model. The real choice is about values and ecosystem. If open licensing and vendor-neutral governance matter, OpenTofu is the clear pick and costs little to adopt. If you want HashiCorp’s managed platform and enterprise support, Terraform remains a strong, well-supported choice. Either way, the fork has been healthy for the ecosystem — competition has accelerated features on both sides, and users are the beneficiaries.