OpenTofu vs Terraform (2026): The Fork Decision Explained

OpenTofu vs Terraform is the infrastructure-as-code decision almost every platform team has reckoned with since 2023, and in 2026 it is no longer about which tool writes better config. They write the same config. Both use HCL, the same state format, and the same providers, so the real choice is about licensing, governance, and roadmap direction. This guide walks through the BUSL relicensing that triggered the fork, what OpenTofu actually is, how compatible the two really are, and when each one wins. If you are weighing your wider IaC stack, this pairs naturally with our Terraform vs Pulumi comparison, which covers the HCL-versus-general-purpose-language axis.

The short answer

• Use OpenTofu if you want a fully open-source IaC tool with no licensing strings attached, governed by a neutral foundation. It is MPL 2.0, lives under the Linux Foundation, has been accepted into the CNCF, and is a drop-in replacement for Terraform.
• Use Terraform if you are committed to the HashiCorp ecosystem - HCP Terraform / Terraform Cloud, official enterprise support, and the IBM-backed roadmap - and the BUSL terms do not constrain your use case.
• Run both during a transition when you are migrating gradually: pilot OpenTofu on new or lower-risk workspaces while legacy stacks stay on Terraform until validated, then converge.
• The pragmatic 2026 default for teams that just provision infrastructure is OpenTofu - open license, neutral governance, drop-in migration - unless you are already deep in HCP Terraform, in which case staying put is reasonable.

Deciding factor to pick

The rule: if license and governance are the constraint, pick OpenTofu; if platform and vendor backing are the constraint, pick Terraform - the HCL itself is not the deciding factor.

What each tool is

• Terraform is the original infrastructure-as-code tool from HashiCorp, now IBM-backed after IBM closed its acquisition of HashiCorp in early 2025. It uses HCL, a huge provider ecosystem, and is the foundation of the HCP Terraform / Terraform Cloud platform. Since August 2023 the CLI is source-available under the Business Source License (BUSL 1.1), not a recognized open-source license.
• OpenTofu is the community fork of Terraform, created in direct response to the BUSL relicensing. It was forked from the last MPL 2.0 Terraform commit, donated to the Linux Foundation, and has since been accepted into the CNCF. It is a drop-in replacement (same HCL, state, and providers), governed openly by a multi-company Technical Steering Committee, and has begun shipping features ahead of or different from Terraform.

OpenTofu vs Terraform: head-to-head

Licensing and governance. This is the decisive axis. In August 2023 HashiCorp relicensed Terraform from the open-source MPL 2.0 to the BUSL, which keeps the source visible but restricts using Terraform to build a competing product. OpenTofu took the last MPL-licensed code, forked it, and handed it to the Linux Foundation, where it is steered by a committee rather than one company and has since joined the CNCF. If your organization needs a recognized open-source license or wants to avoid any competing-use ambiguity, OpenTofu is the clear answer.

Compatibility. They are deliberately close. OpenTofu reads and writes the same state format, speaks the same HCL, and pulls from a registry that mirrors the provider and module ecosystem you already use. For most teams, migration is installing the binary, pointing it at existing code and state, and running init. The honest caveat is that the codebases have started to diverge, so very new tool-specific language features may exist on one side and not the other.

Roadmap divergence. OpenTofu is not a frozen snapshot. It has shipped its own capabilities, most notably client-side state encryption (protecting sensitive state at rest with passphrases and KMS integrations) and early variable evaluation. Terraform, meanwhile, concentrates a lot of its differentiated value in the HCP Terraform / Terraform Cloud platform rather than the bare CLI. The two are no longer identical, even if day-to-day config still ports cleanly.

Ecosystem and platform. Terraform’s biggest pull is the HashiCorp platform - HCP Terraform / Terraform Cloud for remote state, runs, policy, and collaboration, plus official enterprise support now backed by IBM. OpenTofu has no first-party paid platform, so teams pair it with third-party platforms (Spacelift, Scalr, env0) or self-hosted remote state. If you are buying a managed platform anyway, that choice often drives which CLI you standardize on.

When to choose OpenTofu

Choose OpenTofu when:

• You need a tool under a recognized open-source license (MPL 2.0) with no usage restrictions and no BUSL competing-use risk.
• You value neutral, foundation-based governance so no single vendor can unilaterally change the rules again.
• You want client-side state encryption in the open-source CLI without buying a platform to get it.
• You are starting fresh or running a drop-in migration from Terraform and want minimal disruption.
• You prefer a community-driven, fast-moving roadmap accountable to a steering committee.
• You are pairing IaC with a third-party platform (Spacelift, Scalr, env0) or self-hosted state and do not need HashiCorp’s SaaS.

OpenTofu is the pragmatic default for teams whose primary concern is open licensing and avoiding single-vendor lock-in.

When to choose Terraform

Choose Terraform when:

• You are already invested in HCP Terraform / Terraform Cloud and rely on its remote state, runs, and policy workflows.
• You want official vendor support and SLAs, now backed by IBM’s enterprise organization.
• The BUSL terms do not affect you - you provision your own infrastructure and are not building a competing IaC product.
• You want the earliest access to HashiCorp-built features and the largest first-party ecosystem.
• Your organization has procurement, compliance, or audit requirements that favour a commercial vendor relationship.
• Migration effort is not worth it because your current Terraform setup is stable and unaffected by the license change.

Terraform remains the right call for teams whose value sits in the HashiCorp platform and who are unbothered by the license shift.

Can you use them together?

Within one state and codebase, standardize on a single tool - mixing OpenTofu and Terraform on the same workspace invites drift as their language features and state behavior diverge over time. Across an organization, though, running both during a migration window is normal and low-risk, because they share HCL, state format, and providers. A realistic pattern:

1. Pilot OpenTofu on new or lower-risk workspaces, validating provider and module parity against your real configurations.
2. Keep legacy stacks on Terraform until each is tested under OpenTofu on a non-production copy of its state.
3. Pin the binary per pipeline so a workspace is never planned by one tool and applied by the other.
4. Converge once you confirm feature and provider parity for the features you actually use.
5. Decide the platform layer separately - if you drop HCP Terraform, line up a replacement (self-hosted state, Spacelift, Scalr, or env0) before you cut over.

For the IaC-language tradeoff that sits underneath all of this, our Terraform vs Pulumi comparison is the companion read.

Cost comparison

Both CLIs are free to download and run, so price is not the differentiator at the tool level.

• OpenTofu is fully open source under MPL 2.0 with no usage restrictions and no paid first-party tier. Costs land at the platform and operations layer: remote state backends, plus an optional managed platform (Spacelift, Scalr, env0) or self-hosted state on object storage.
• Terraform’s CLI is free but source-available under the BUSL, which permits normal infrastructure use while restricting competing-product use. Spend appears as HCP Terraform / Terraform Cloud subscriptions and Terraform Enterprise for collaboration, state, policy, and run automation, plus official support.

The honest framing: budget for the platform and operational tooling, not the binary. OpenTofu shifts that spend toward third-party or self-hosted platforms; Terraform centralizes it in HashiCorp’s commercial offerings. There is no per-tool license fee on either side for standard infrastructure provisioning.

Common pitfalls

• Treating the choice as a syntax decision. It is not - both use HCL. The real axes are license, governance, and platform. Picking on “which language is nicer” misses the point entirely.
• Migrating without testing state. Always run OpenTofu against a non-production copy of your state first. The format is compatible, but provider versions and a few language features can differ enough to bite you.
• Forgetting the platform layer. Dropping Terraform also means dropping HCP Terraform / Terraform Cloud if you used it. Line up remote state and run automation before you cut over, not after.
• Mixing both tools on one workspace. Planning with one binary and applying with another invites state drift as the codebases diverge. Standardize per workspace and pin the binary in CI.
• Assuming BUSL never matters to you. For most teams it genuinely does not, but if you embed Terraform in a product or managed service you sell, read the license terms carefully before assuming you are in the clear.

Related reading

• Terraform vs Pulumi - HCL versus general-purpose programming languages for infrastructure as code.
• Checkov vs tfsec - policy-as-code and static analysis for your Terraform or OpenTofu configurations.

Getting help

NomadX DevSecOps runs infrastructure-as-code strategy and migration as fixed-scope engagements: we benchmark OpenTofu against Terraform on your real workspaces, quantify the migration and platform impact, and stand up standardized modules with policy-as-code, encrypted state, and least-privilege provisioning in your CI/CD. Whether you are migrating off the BUSL or hardening an existing Terraform estate, we deliver a tested cutover plan and the platform engineering foundations to run it. Book a free scope call.