OpenTofu vs Terraform in 2026: The Fork Has Matured

New to infrastructure as code? Start with the fork story to understand why two competing tools now share the same language. If you already know the history, skip to the feature comparison or dual-engine strategy.

Topic	When to Read	Key Takeaway
Fork History	Need context on the split	BSL licence change triggered the fork
Feature Comparison	Evaluating which tool fits	State encryption and provider for_each are OpenTofu exclusives
CNCF Acceptance	Care about governance	CNCF backing signals long-term sustainability
Dual-Engine Strategy	Running both tools	Shared HCL means modules work across both
Migration Guide	Switching from Terraform	Drop-in binary swap for most configurations

The Fork Story: Why Two Tools Exist

For nearly a decade, Terraform was the undisputed king of infrastructure as code. It was open source under the Mozilla Public Licence (MPL 2.0), and that openness was central to its adoption. Thousands of community-built providers, hundreds of shared modules, and an entire ecosystem of third-party tooling grew around it.

Then, in August 2023, HashiCorp changed the licence to the Business Source Licence (BSL 1.1). The BSL is not an open-source licence. It restricts competitive use — meaning companies building products that compete with HashiCorp’s commercial offerings can no longer freely use Terraform.

The community response was swift. Within weeks, a coalition of infrastructure companies — including Gruntwork, Spacelift, env0, and Scalr — announced the OpenTofu fork. They took the last MPL-licenced version of Terraform (v1.5.x) and began building independently.

At the time, sceptics questioned whether a fork could survive. Terraform had years of momentum, a massive provider registry, and the backing of a well-funded company. OpenTofu had a manifesto and a lot of goodwill.

Two and a half years later, the sceptics were wrong.

What OpenTofu Has Added

OpenTofu has not just kept pace with Terraform — it has shipped features that Terraform does not have. Here are the headline additions:

Native State Encryption

Terraform state files contain sensitive data: database passwords, API keys, resource identifiers. By default, this state is stored in plaintext. Teams have worked around this for years using encrypted backends or wrapper scripts, but Terraform itself offers no native encryption.

OpenTofu added client-side state encryption as a first-class feature. You configure an encryption key (or integrate with a KMS provider), and state is encrypted before it leaves the machine. No wrapper scripts. No third-party tooling. It just works.

For regulated industries — finance, healthcare, government — this is a significant advantage. State encryption has been one of the most requested Terraform features for years, and OpenTofu delivered it first.

Provider for_each

Terraform requires you to declare each provider instance individually. If you manage infrastructure across 15 AWS regions, you need 15 provider blocks. OpenTofu introduced for_each on provider blocks, allowing you to iterate dynamically:

This reduces boilerplate significantly in multi-region or multi-account deployments — exactly the kind of configuration that enterprise teams manage daily.

The Provider Registry

One of the biggest concerns when OpenTofu launched was provider availability. Terraform’s registry has over 2,000 providers — would OpenTofu have access to them?

The answer is yes. OpenTofu established its own registry that mirrors the vast majority of Terraform providers. Most providers are written in Go and compiled against the same plugin protocol, so they work with both tools without modification. The OpenTofu registry now lists over 2,000 providers, and the most popular ones (AWS, Azure, GCP, Kubernetes) are fully supported.

CNCF Acceptance: Why It Matters

In 2024, OpenTofu was accepted into the Cloud Native Computing Foundation (CNCF). This is the same organisation that governs Kubernetes, Prometheus, Envoy, and Argo. CNCF membership is not a rubber stamp — it requires demonstrated community governance, a neutral trademark, and a commitment to open development.

For OpenTofu, CNCF acceptance does several important things:

• Governance legitimacy — No single company controls the project. Decisions are made through open RFC processes and community voting.
• Long-term sustainability — CNCF projects have institutional support. They do not disappear when a sponsoring company pivots or gets acquired.
• Enterprise confidence — Procurement teams at large organisations recognise the CNCF brand. It reduces the perceived risk of adopting OpenTofu.
• Ecosystem alignment — OpenTofu now sits alongside the rest of the cloud-native stack. Integration with tools like Argo CD, Crossplane, and Flux becomes more natural.

The CNCF factor is particularly important for organisations that have already standardised on CNCF tooling. If your Kubernetes clusters are managed by CNCF projects, having your IaC tool in the same governance structure simplifies compliance and risk assessment.

Real-World Adoption

OpenTofu is not a theoretical alternative — it is running in production at serious scale. Publicly disclosed adopters include:

• Boeing — using OpenTofu for cloud infrastructure provisioning across multiple environments.
• Capital One — one of the early supporters of the open-source IaC movement, running OpenTofu alongside existing Terraform configurations.
• AMD — adopted OpenTofu for new infrastructure projects where open-source licensing was a procurement requirement.
• Spacelift, env0, Scalr — IaC platform vendors that offer first-class OpenTofu support alongside Terraform.

The adoption pattern is telling. It is not just startups experimenting — large enterprises with strict licensing and compliance requirements are choosing OpenTofu precisely because of its open-source credentials and CNCF governance.

Terraform’s Strengths in 2026

Being balanced about this: Terraform is not going away, and it has genuine advantages that matter for certain teams.

• HCP Terraform (formerly Terraform Cloud) — a mature, managed platform for state management, policy enforcement, and team collaboration. Nothing in the OpenTofu ecosystem matches it for turnkey enterprise workflows.
• HashiCorp support — backed by IBM since the 2024 acquisition, Terraform has dedicated engineering, enterprise support contracts, and a clear commercial roadmap.
• Ecosystem maturity — Terraform has been around since 2014. The documentation, community knowledge, Stack Overflow answers, and training materials are deeper.
• Sentinel and OPA integration — policy-as-code tooling that is tightly integrated with the HCP Terraform workflow.

If your organisation is already paying for HCP Terraform Enterprise and your teams are productive with it, switching to OpenTofu may not deliver enough value to justify the migration effort. The BSL licence change primarily affects companies building competing products, not end users.

The Dual-Engine Strategy

The most pragmatic approach for many organisations is to run both. This is not as chaotic as it sounds, because Terraform and OpenTofu share the same foundation:

• Same HCL language — configuration files written for Terraform work in OpenTofu and vice versa (with minor exceptions for newer features).
• Same state format — state files are compatible. You can migrate state between the two tools.
• Same provider protocol — providers compiled for Terraform work with OpenTofu.
• Same module format — shared modules work across both tools.

The dual-engine approach works like this: keep existing Terraform stacks on Terraform (especially if they are managed through HCP Terraform). Use OpenTofu for new projects where open-source licensing, state encryption, or CNCF alignment matters. Share modules between the two.

Practical Migration: From Terraform to OpenTofu

If you decide to migrate, the process is more straightforward than you might expect:

Step 1: Install OpenTofu

Step 2: Test with Your Existing Configuration

Step 3: Update CI/CD Pipelines

Replace terraform with tofu in your pipeline scripts. The CLI arguments are identical. If you use GitHub Actions, the official opentofu/setup-opentofu action is a drop-in replacement for hashicorp/setup-terraform.

Step 4: Enable New Features

Once migrated, you can progressively adopt OpenTofu-specific features like state encryption and provider for_each. These are additive — your existing configuration continues to work without changes.

The Bottom Line

In 2026, the OpenTofu fork has proven the sceptics wrong. It has shipped meaningful features that Terraform lacks, earned CNCF backing, and attracted real enterprise adoption. The infrastructure-as-code landscape is now genuinely a two-tool ecosystem.

Neither tool is categorically better. Terraform has the mature commercial platform and deeper ecosystem history. OpenTofu has the open-source licence, innovative features, and the governance structure that large organisations increasingly require.

The smart play for most teams is not to pick a side — it is to understand both, use each where it fits best, and take advantage of the fact that HCL, providers, and modules work across both. The fork matured. The ecosystem is richer for it.

Have you migrated from Terraform to OpenTofu? I would love to hear about your experience — what worked, what didn’t, and whether you are running both. Drop a comment below or find me on LinkedIn.