OpenTofu vs Terraform in 2026: The Fork Matures

Three years ago, HashiCorp changed the Terraform license from MPL 2.0 to BSL 1.1, and the open source community forked it into OpenTofu. What started as a protest move has become one of the most significant forks in infrastructure tooling history. OpenTofu now lives under the Linux Foundation, has crossed 10 million GitHub downloads, and ships features Terraform still does not have.

The question in 2026 is no longer whether the fork is credible. The question is which tool fits your team, your compliance requirements, and your vendor strategy.

The Backstory in Three Dates

The entire fork timeline distils to three moments:

August 2023 — HashiCorp relicenses Terraform from MPL 2.0 to BSL 1.1, a source-available license that restricts commercial use by competitors. The community response was immediate. Thirty-three thousand GitHub stars and over one hundred company pledges later, the OpenTofu manifesto was published.

September 2023 — The Linux Foundation accepts the renamed OpenTofu project under its governance. What could have been a fragmented fork with competing stewardship became a single, vendor-neutral project backed by a foundation with a track record of running open source infrastructure.

February 2025 — IBM closes its $6.4 billion acquisition of HashiCorp. Terraform, Vault, and Consul are now IBM products. For teams that were already uneasy about the BSL license, the IBM acquisition added a second layer of strategic uncertainty.

License and Governance: The Constitutional Divide

The practical difference between MPL 2.0 and BSL 1.1 matters most for vendors and managed service providers. For an end user writing HCL and running tofu apply or terraform apply, the license does not directly affect day-to-day work. The real impact is downstream.

OpenTofu (MPL 2.0, Linux Foundation) can be forked, redistributed, embedded in commercial products, and modified without restriction. This is why every major IaC platform — Spacelift, env0, Scalr, Harness, GitLab — now supports OpenTofu natively. Some have made it their default engine.

Terraform (BSL 1.1, IBM/HashiCorp) restricts who can offer Terraform as a service. The license is not a problem for most internal teams, but it matters when a vendor wants to build a competing managed Terraform offering. It also matters if your organisation has a strict policy against non-OSI-approved licenses.

The governance difference has become visible in practice. OpenTofu ships new features through an RFC process with community review. Terraform features are driven by IBM’s product roadmap. The HCP Terraform free tier ended in March 2026, with the replacement capped at five hundred managed resources, and pricing has increased roughly eighteen percent year over year according to multiple sources.

Feature Face-Off: Where Each Side Leads

OpenTofu 1.12.2 (current stable) and Terraform 1.15 (April 2026) share the same HCL language and the same provider protocol, but the feature sets have diverged significantly.

OpenTofu-Only Features

State and plan encryption (v1.7) is the single most-cited OpenTofu advantage. State files routinely contain database passwords, API keys, and private keys in plaintext. Backend-level encryption — S3 SSE, GCS encryption — protects data at rest in the remote backend, but not during transit or in local copies. OpenTofu encrypts before the file ever leaves the machine, using AES-GCM with pluggable key providers.

terraform {
  encryption {
    key_provider "gcp_kms" "prod" {
      kms_encryption_key = "projects/acme/locations/global/keyRings/tofu/cryptoKeys/state"
      key_length         = 32
    }
    method "aes_gcm" "prod" {
      keys = key_provider.gcp_kms.prod
    }
    state { method = method.aes_gcm.prod }
    plan  { method = method.aes_gcm.prod }
  }
}

Terraform has no equivalent. You bolt on backend-level encryption and accept the gap.

Ephemeral values (v1.11) keep secrets in memory during the run and never write them to the state file. For teams under compliance regimes like SOC 2 or PCI DSS, this alone can justify a migration.

Provider for_each (v1.9) eliminates one of the most repetitive patterns in Terraform: writing the same provider block N times for multi-region setups. In Terraform, a multi-region AWS configuration requires either duplicated blocks or a module wrapper with aliases. OpenTofu collapses it into a single loop:

variable "regions" {
  type = list(string)
  default = ["us-east-1", "eu-west-1", "ap-southeast-1"]
}

provider "aws" {
  region = each.value
  for_each = toset(var.regions)
}

resource "aws_vpc" "this" {
  provider = aws[each.key]
  cidr_block = "10.0.0.0/16"
  for_each = toset(var.regions)
  tags = { Region = each.key }
}

OCI registry support (v1.10) lets teams store providers and modules in container registries, which is a decisive feature for air-gapped environments and regulated industries.

Native S3 locking (v1.10) removes the DynamoDB dependency for state locking on AWS. One less table to manage, one less IAM policy to get right.

Dynamic prevent_destroy (v1.12) makes the lifecycle guard configurable per environment through variables, instead of requiring a manual toggle before every destructive apply.

Terraform-Only Features

Terraform’s response has been focused on the managed platform. Stacks provide higher-level multi-config orchestration. Sentinel is a first-party policy-as-code engine. HCP Terraform gives teams a hosted backend with RBAC, runs, and state management integrated.

Terraform 1.15 (April 2026) introduced dynamic module sources with const = true on variables, closing a gap that OpenTofu filled in v1.9 — nearly two years earlier. It also shipped convert(), variable deprecation, type constraints on outputs, and native Windows ARM64 support. These are useful quality-of-life improvements, but they do not change the strategic picture.

Migration: The Drop-In Reality

The most common reader question is still: how hard is the migration? In practice, it is a binary swap for most teams.

# 1. Install OpenTofu alongside Terraform
curl --proto '=https' --tlsv1.2 -fsSL https://get.opentofu.org/install-opentofu.sh | sh

# 2. Back up existing state
cp terraform.tfstate terraform.tfstate.backup

# 3. Initialize with OpenTofu
tofu init

# 4. Verify — this should return clean (no changes)
tofu plan

# 5. First apply rewrites the terraform version marker
tofu apply

Post-migration, update CI pipeline scripts to use tofu instead of terraform, or add alias terraform=tofu in your runner environment.

What does not migrate easily: HCP Terraform workflows, Sentinel policies, and Terraform Stacks. Teams heavily invested in the HashiCorp managed platform face real switching costs that may outweigh the license concerns.

Three Practical Scenarios

Scenario A: Compliance-driven team. Your organisation needs to encrypt state files at rest and in transit, and keep secrets out of state entirely. OpenTofu wins decisively. The native encryption and ephemeral values features exist in no version of Terraform and have no announced roadmap equivalent. Migration cost is low; compliance value is high.

Scenario B: Multi-region platform team. You manage infrastructure across five AWS regions, each with its own provider configuration. OpenTofu’s provider for_each eliminates what would otherwise be hundreds of lines of duplicated provider blocks in Terraform. The reduction in boilerplate alone pays for the switchover hour.

Scenario C: Heavy HCP Terraform user. Your team relies on Sentinel policies, HCP runs, and the managed state backend. Migration costs — rewriting policies, reconfiguring CI, retraining the team — are real and measurable. Terraform remains the pragmatic choice unless licensing policy forces a move. Monitor OpenTofu’s managed-platform ecosystem growth, but do not rush.

Adoption Trends and the Field Reality

OpenTofu’s adoption numbers are directionally clear even with the usual caveats around survey methodology. Ten million GitHub release downloads, three hundred percent annual growth, and a CNCF sandbox acceptance in April 2025 signal real momentum. Thirty-eight percent of Terraform users report actively evaluating or migrating away from Terraform.

Yet Terraform still holds an approximately 77x advantage in Google Trends search volume. The mindshare gap is wide. Hiring pipelines, certification programmes, and enterprise support contracts all favour the incumbent. An OpenTofu migration is operationally low risk but culturally visible — it signals a strategic decision that stakeholders above the engineering team may question.

The vendor ecosystem has shifted decisively. Spacelift, env0, and Scalr all default to OpenTofu now. GitLab supports it natively. If your CI platform already runs on one of these, migration friction is nearly zero.

Conclusion: A Mature Choice

In 2026, neither option is risky. OpenTofu is production-ready, well-governed, and backed by a growing ecosystem. Terraform under IBM continues to improve, with Stacks and tighter HCP integration that matter for teams already in that ecosystem.

The decision framework comes down to three questions:

1. Does your compliance or licensing posture require OSI-approved open source? If yes, choose OpenTofu.
2. Are you heavily invested in HCP Terraform workflows, Sentinel, or Stacks? If yes, the migration cost may not justify the switch.
3. Does your CI platform already support OpenTofu natively? If yes, migration friction is near zero and the feature advantages are free.

The fork has matured. Make the choice on substance, not on which side has better marketing.