← All posts

Terraform vs. OpenTofu in 2026: Where the Fork Stands

Nearly three years after HashiCorp changed Terraform's license and the community forked it into OpenTofu, the two are no longer the same tool with different logos. They share a heritage and a language, but they've diverged on licensing, governance, and — increasingly — features. If you write infrastructure as code, here is an honest 2026 picture: what split, where each one leads, how hard it is to switch, and how to choose.

How we got two tools

In August 2023, HashiCorp relicensed Terraform (and its other products) from the open-source Mozilla Public License 2.0 to the Business Source License (BSL) 1.1 — a "source-available" license that lets you use Terraform freely in production but forbids using it to build a competing product. Days later, the community published the OpenTF manifesto; when HashiCorp didn't reverse course, the fork shipped as OpenTofu, which joined the Linux Foundation and reached a production-ready 1.6 release in January 2024.

Then the ownership changed too: IBM's acquisition of HashiCorp closed in February 2025. So far that hasn't moved the license — Terraform remains BSL — but it reframed the question. Terraform is now a commercially-backed product inside IBM; OpenTofu is a vendor-neutral, foundation-governed open-source project. That governance difference, more than any single feature, is what the choice often comes down to.

Licensing: the original fault line

TerraformOpenTofu
LicenseBSL 1.1 (source-available)MPL 2.0 (OSI open source)
Production useAllowedAllowed
Build a competing serviceNot allowedAllowed
GovernanceHashiCorp / IBMLinux Foundation

For most teams, the BSL's competitive restriction never bites — you're using Terraform to manage your own infrastructure, which the license explicitly permits. Each BSL-licensed version also automatically converts to MPL 2.0 four years after its release. The restriction matters mainly to vendors and platforms that embed or resell the tool, and to organizations whose policy simply requires a true open-source license. For them, OpenTofu's MPL 2.0 is the entire point.

Current versions

As of mid-2026, both are healthy and actively shipping — coincidentally, both cut a release on the same day in late May 2026:

  • Terraform 1.15.x (1.15.5, May 2026).
  • OpenTofu 1.12.x (1.12.1, May 2026).

Note the version numbers have drifted apart — Terraform is in the 1.14–1.15 range, OpenTofu in the 1.10–1.12 range — so don't compare them as if "1.12 < 1.15" means one is behind. They're separate products with separate roadmaps now.

The widening feature gap

For the first year the two were near-identical. They've since shipped genuinely different headline features.

What OpenTofu has (or did first)

  • Client-side state & plan encryption (1.7) — encrypt state and plan files before they ever hit a backend. This is OpenTofu-exclusive and the single most-cited reason teams move; Terraform has no equivalent.
  • Early / dynamic evaluation (1.8) — use variables and locals in places that used to require hard-coded literals, including backend configuration and module sources. (Terraform added a narrower version of this only in 1.15.)
  • The -exclude flag (1.9), plus -target-file/-exclude-file (1.10) — apply everything except a given resource, the inverse of -target.
  • OCI registry support (1.10) — distribute providers and modules through standard container registries, which is a real win for air-gapped environments — plus native S3 state locking with no separate DynamoDB table.

What Terraform has

  • A built-in test framework (terraform test, since 1.6) — HCL-native unit and integration tests for modules.
  • Ephemeral resources and values (1.10+) and write-only attributes (1.11) — secrets that flow through a run without being persisted to state.
  • Search and import (terraform query with .tfquery.hcl, plus an Actions block, in 1.14) — discover existing cloud resources and bring them under management.
  • Stacks (GA at HashiConf, September 2025) — a higher-level unit for managing many related configurations and their dependencies, tightly tied to HashiCorp's managed platform, HCP Terraform (whose free tier was discontinued around March 2026).

⚠️ The compatibility catch. The moment you adopt an OpenTofu-only feature (state encryption, early evaluation, -exclude), your configuration is no longer portable back to Terraform — and vice versa for Terraform Stacks or ephemeral resources. The two are diverging precisely because each is shipping things the other can't run. Decide deliberately, not by accident.

How hard is it to switch?

For configurations on the common ancestor (around Terraform 1.5/1.6), migrating to OpenTofu is close to a drop-in: your .tf files are valid, every provider and module from the registry works, and the state format is compatible — you largely swap the terraform binary for tofu. Two cautions, though:

  • It's effectively one-way once you run an apply. After tofu apply, your state can pick up OpenTofu metadata that the stock Terraform CLI won't accept — so going back can break. Back up your state before migrating.
  • Version pins and private registries need attention. A config pinned to a high Terraform version won't run on a lower OpenTofu version without loosening the constraint, and modules in HashiCorp's private registry must move to Git or a self-hosted/OCI registry.

Adoption and the ecosystem

OpenTofu's momentum is real: it's a top-tier Linux Foundation project with a large, growing download count, an official VS Code extension and language server, and broad tooling support. The major IaC platforms — Spacelift, Scalr, env0, Harness — support both Terraform and OpenTofu (several were OpenTofu founding contributors), and one platform vendor reports roughly half of its deployments now run on OpenTofu. (Treat single-vendor numbers as directional, not gospel.) The practical takeaway: OpenTofu is no longer a risky bet on adoption — it's a mainstream choice with a real ecosystem behind it.

How to choose

There's no universally right answer, but the decision usually clarifies quickly:

  • Choose OpenTofu if a true open-source license matters to your organization, if you want client-side state encryption or OCI-based distribution, or if you value vendor-neutral, foundation governance. It's also a clean default for new green-field projects with no HashiCorp platform ties.
  • Choose Terraform if you rely on HCP Terraform, want Stacks or ephemeral resources, are embedded in HashiCorp's commercial ecosystem (Sentinel policies, the private registry, enterprise support), or simply prefer a single commercially-backed vendor.

The encouraging part: the fundamentals — HCL, providers, modules, state, the plan/apply loop — are still shared, so the skills transfer either way. That's also why, in our hands-on certification labs, we teach the concepts of infrastructure as code first; whether your team runs terraform or tofu is then a governance decision, not a re-learning exercise.

Sources

← Back to all posts