OpenTofu in 2026: The Greenfield IaC Decision You Need to Get Right

In August 2023, HashiCorp relicensed Terraform under the Business Source License, quietly rewriting the terms that millions of infrastructure teams had built their toolchains on. For organisations already running Terraform in production, the immediate impact was ambiguous enough to justify inaction. For teams starting fresh today, that ambiguity has resolved into something cleaner: the IaC decision matrix has genuinely changed, and picking the wrong foundation now means carrying the wrong constraints forward for years.

OpenTofu is the direct answer to that shift. A Linux Foundation project forked from the last Mozilla Public License version of Terraform, it has moved from emergency community response to serious production contender in just over two years. As of December 2025, version 1.11 is stable, the project has crossed 10 million GitHub downloads, and the Cloud Native Computing Foundation accepted it as a sandbox project in April 2025. For a greenfield architecture team choosing an IaC foundation today, OpenTofu belongs at the top of the evaluation list, not as a political statement about open source, but because the technical case is now independently compelling.

This post gives you the complete picture: what OpenTofu actually is, where it has diverged from Terraform in ways that matter, how it compares to the other serious contenders, and how to assess whether it belongs at the centre of your new infrastructure stack.

Why the IaC Landscape Shifted in 2023

The HashiCorp Business Source License change was not a minor terms adjustment. The BSL restricts commercial use in specific ways: organisations offering services that compete with HashiCorp products face licensing restrictions, and the definition of “competitive” is controlled unilaterally by HashiCorp. HashiCorp was subsequently acquired by IBM in June 2024, adding a further layer of corporate governance uncertainty to a tool that enterprise teams had treated as neutral infrastructure bedrock.

The community response was unusually well-organised. Gruntwork, Spacelift, Harness, env0, and Scalr coordinated a formal fork within weeks, creating the OpenTofu project under Linux Foundation governance with a public Technical Steering Committee and an RFC-based decision process. The fork was not technically complex, because it started from Terraform 1.5.7, the last MPL-licensed release. What made it credible was the speed of institutional backing and the commitment from the organisations who had built products on top of Terraform.

For greenfield teams, the practical implication is straightforward. Terraform’s BSL introduces legal considerations that your legal and procurement teams will need to evaluate, particularly if your organisation builds or sells cloud services. OpenTofu carries no such ambiguity. It operates under MPL 2.0, the same permissive licence that Terraform itself used until 2023, and its governance is defined by a public charter rather than a private company’s commercial interests.

What OpenTofu Actually Is

OpenTofu is not a spiritual successor to Terraform or a reimagined approach to infrastructure as code. It is a fork, which means it is Terraform, specifically Terraform at the point where the community still owned it. That framing matters for greenfield evaluation: you are not choosing an alternative to Terraform’s approach, you are choosing a version of that approach under different governance and with a different feature trajectory.

At the foundation, OpenTofu uses HashiCorp Configuration Language, the same declarative syntax familiar to any engineer who has worked with Terraform. The core workflow is identical: write configuration that describes desired infrastructure state, run tofu plan to see what will change, run tofu apply to provision it. The state file format is compatible. The 3,900+ providers that work with Terraform work with OpenTofu without modification, because both tools share the same provider protocol. The 23,600+ public modules in the OpenTofu registry are available immediately.

Where OpenTofu has genuinely diverged is in two specific technical capabilities Terraform has not shipped, alongside the licensing and governance gap that started the fork. It is worth being precise here, because some comparisons overstate the technical difference. S3 native state locking without DynamoDB arrived in both tools on effectively the same timeline, reaching GA in the 1.10 and 1.11 cycles of each. Ephemeral resources and write-only attributes follow the same pattern. Both are meaningful improvements that both tools now share. They are not reasons to choose one over the other.

The genuine technical differentiators are as follows.

State and plan encryption (1.7) introduced client-side encryption of state files before they leave your environment. This addresses one of the most persistent concerns in enterprise Terraform deployments, where state files contain plaintext secrets, database passwords, and access keys stored in S3 buckets or Terraform Cloud. OpenTofu encrypts state and plan files using AES-GCM before they reach any backend, with support for PBKDF2-derived keys, AWS KMS, and GCP KMS. Terraform continues to rely on backend-level encryption: you enable server-side encryption on your storage layer and trust it is correctly configured. The practical difference is that with OpenTofu, a misconfigured or compromised backend exposes encrypted data. With Terraform, it exposes plaintext. For regulated workloads, this is an architectural distinction rather than a marginal one, and it is a capability Terraform has no public roadmap to match.

OCI registry support (1.10) allows providers and modules to be distributed through any OCI-compatible container registry, including Harbor, Artifactory, GitHub Container Registry, and AWS ECR. Terraform has no equivalent. For organisations operating air-gapped environments, this eliminates the dependency on public registry access entirely and brings provider distribution into the same supply chain tooling already used for container images. Teams that have invested in registry infrastructure for container security get to reuse it for IaC dependencies without standing up a separate mirror. This is the feature that matters most for organisations with strict network egress controls.

Provider iteration with for_each (1.9) and early variable evaluation (1.8) both address long-standing HCL limitations that Terraform users have worked around for years. The ability to use variables in module sources and backend configuration removes one of the more awkward constraints in complex multi-account deployments. These are quality-of-life improvements rather than strategic differentiators, but they are OpenTofu-only and they reduce boilerplate meaningfully in large estate deployments.

The honest summary of the feature comparison is that the technical case for OpenTofu is narrower than some advocates suggest, but more durable. State encryption and OCI registry support address real enterprise problems that Terraform does not solve at the IaC layer. If neither applies to your situation, the decision comes down primarily to licensing posture and governance preference – which is still a legitimate reason to choose OpenTofu, but a different argument to make.

Production Readiness: The Signals That Matter

For an architect evaluating a greenfield IaC foundation, production readiness is not a binary question. It is a set of signals about maturity, stability, ecosystem support, and sustainability.

Governance is where OpenTofu is genuinely differentiated. Linux Foundation hosting provides a neutral organisational home with defined IP policies and contributor agreements. The Technical Steering Committee operates publicly, with meeting notes and decision rationale archived on GitHub. The RFC process means feature decisions are documented, debated publicly, and traceable. This governance model is modelled on successful open source projects like Kubernetes and Node.js, and it provides an institutional continuity guarantee that no single vendor can offer.

CNCF sandbox acceptance in April 2025 is a meaningful signal. The CNCF’s sandbox tier is explicitly for projects that have demonstrated viability and community traction but are still in active development. It represents endorsement from the organisation that stewards Kubernetes, Prometheus, and the broader cloud-native ecosystem. For enterprise procurement and security reviews, CNCF affiliation provides a recognised framework for assessing project health.

Ecosystem support has matured considerably. The managed platforms that enterprise teams typically use to operate Terraform at scale have all committed to OpenTofu. Spacelift, env0, Harness IaCM, Atlantis, and Terragrunt all support OpenTofu natively. The GitHub Actions official action (opentofu/setup-opentofu@v1) provides CI/CD integration. The VS Code extension with IntelliSense and real-time validation shipped alongside 1.10. An MCP server for AI-assisted infrastructure coding shipped in the same release.

Release cadence is consistent and predictable. The project ships on a regular cycle, patches the three most recent major versions, and has maintained this discipline since 1.6 GA in January 2024. The 1.11 series is supported until August 2026. Security patches have been shipped promptly. The OpenTofu registry status page shows 99.8%+ uptime over the last 90 days.

Download numbers provide a rough adoption signal. The project crossed 10 million GitHub release downloads by mid-2025. Total actual installations, accounting for Homebrew, package managers, and corporate mirrors, is materially higher. Fidelity is a publicly documented enterprise adopter. Allianz contributed to the GA announcement with a public statement committing to OpenTofu.

Tooling and developer experience has caught up considerably with what enterprise Terraform teams expect. The OpenTelemetry tracing support in 1.10 gives platform teams observability into OpenTofu operations within existing monitoring infrastructure. The Language Server Protocol implementation (tofu-ls) provides full IDE integration across VS Code, Neovim, Emacs, and Sublime Text. The MCP server integration means AI-assisted coding tools can generate accurate, idiomatic OpenTofu configurations using live provider documentation rather than stale training data. These are not decorative features – they are signals of a project investing seriously in developer experience parity.

The honest production readiness caveat is that OpenTofu is younger than Terraform. The operational knowledge base accumulated around Terraform, the Stack Overflow answers, the blog posts, the internal runbooks, is larger. Edge cases that surface in complex deployments may have less documented community resolution. That gap is narrowing and will continue to narrow, but greenfield teams should plan for some increase in self-sufficiency compared to adopting a tool with a decade of community troubleshooting behind it.

The IaC Decision Matrix: OpenTofu vs Terraform vs Pulumi vs AWS CDK

Greenfield architecture decisions benefit from honest comparison rather than advocacy. Here is how the four primary contenders compare across the dimensions that matter most for enterprise teams.

Terraform remains the reference standard for HCL-based IaC and carries the largest installed base. The BSL licensing concern is real but manageable for organisations that are not building competitive cloud services. The principal question is whether IBM’s ownership creates a roadmap alignment risk for your organisation’s long-term infrastructure direction. Teams that have existing Terraform expertise and no licensing concerns may find the path of least resistance is to stay with Terraform, particularly if they are not operating in air-gapped environments or requiring state encryption.

Pulumi occupies a genuinely different position. Rather than declarative HCL, Pulumi lets infrastructure engineers write real code in languages they already use. This unlocks loops, functions, classes, and unit testing within the IaC layer itself. For development-led organisations where the infrastructure team is primarily software engineers, this can meaningfully reduce cognitive context switching. The trade-off is a smaller provider ecosystem (though growing), a different state management story anchored on Pulumi Cloud or self-hosted backends, and less available operational knowledge compared to the HCL ecosystem. Worth noting: HashiCorp sunset CDKTF in December 2025, eliminating the hybrid option that tried to bring programming languages to Terraform’s ecosystem.

AWS CDK wins in a specific, narrow scenario: AWS-only greenfield projects where the team is composed of software engineers who want maximum abstraction and native AWS construct integration. It generates CloudFormation under the hood, which means you inherit CloudFormation’s operational characteristics including its sometimes frustrating stack management behaviour. If there is any likelihood of multi-cloud expansion in your roadmap, CDK is the wrong foundation.

OpenTofu is the strongest choice for greenfield multi-cloud or cloud-agnostic architectures where HCL’s declarative model fits the team’s operating model, licensing clarity is a priority, and access to state encryption or air-gapped provider distribution is a real operational requirement. It is also the right choice if your organisation has an existing Terraform investment you want to build on without inheriting BSL obligations.

When OpenTofu Wins the Greenfield Decision

Five conditions favour OpenTofu as the greenfield foundation over alternatives:

First, regulated or government workloads where legal certainty about open source licensing matters. The BSL’s ambiguity around competitive use is not a risk most organisations need to carry when a clean-licensed alternative is available. CNCF governance aligns well with the compliance postures required in financial services, public sector, and healthcare environments.

Second, air-gapped or high-security environments where dependency on public registries conflicts with network security controls. OCI registry support for provider and module distribution was built explicitly for this use case. Teams running in AWS GovCloud, isolated financial services environments, or Ministry of Defence supply chains will find this capability absent from the alternatives at comparable maturity.

Third, multi-account or multi-cloud architectures where state management complexity is high. The elimination of the DynamoDB dependency for S3 locking, combined with native state encryption and external key provider support, reduces the operational overhead of managing state securely across large organisations.

Fourth, platform engineering teams building internal developer platforms where the IaC tool becomes a dependency of internal tooling. Linux Foundation governance reduces the risk that a commercial vendor’s priorities change the behaviour of a tool your platform is built on. CNCF membership signals the kind of long-term project sustainability that platform teams need before baking a tool into their abstractions.

Fifth, greenfield teams with existing Terraform or HCL expertise who want to leverage that investment without exposure to BSL implications. The migration cost is effectively zero since OpenTofu is syntax-compatible and state-compatible. All existing provider knowledge, module patterns, and operational practices transfer directly.

Getting Started: Structural Patterns for a Greenfield Stack

For architects designing the IaC foundation rather than just installing the tool, the decisions that matter happen before you write your first .tf file.

State backend selection should account for OpenTofu’s native capabilities. If you are on AWS, the native S3 locking feature eliminates the DynamoDB requirement entirely. A basic remote state configuration looks like this:

terraform {
  backend "s3" {
    bucket     = "org-tofu-state"
    key        = "platform/terraform.tfstate"
    region     = "eu-west-2"
    use_lockfile = true  # Native S3 locking, no DynamoDB needed
    encrypt    = true
  }
}

terraform {
  backend "s3" {
    bucket     = "org-tofu-state"
    key        = "platform/terraform.tfstate"
    region     = "eu-west-2"
    use_lockfile = true  # Native S3 locking, no DynamoDB needed
    encrypt    = true
  }
}

For Azure or GCP backends, standard azurerm and gcs backends work as they do in Terraform. The meaningful addition is state encryption configuration, which you can layer on top of any backend:

terraform {
  encryption {
    key_provider "pbkdf2" "main" {
      passphrase = var.state_encryption_passphrase
    }
    method "aes_gcm" "main" {
      keys = key_provider.pbkdf2.main
    }
    state {
      method = method.aes_gcm.main
    }
    plan {
      method = method.aes_gcm.main
    }
  }
}

terraform {
  encryption {
    key_provider "pbkdf2" "main" {
      passphrase = var.state_encryption_passphrase
    }
    method "aes_gcm" "main" {
      keys = key_provider.pbkdf2.main
    }
    state {
      method = method.aes_gcm.main
    }
    plan {
      method = method.aes_gcm.main
    }
  }
}

In production, replace the PBKDF2 passphrase approach with an AWS KMS or GCP KMS key provider for proper key management.

Workspace and module structure follows the same conventions that work well in Terraform: separate state per environment, a modules directory for reusable components, and environment-specific variable files. The IaC Mastery Series on this blog covers the workspace and module patterns in detail, particularly Part 3: Multi-Environment Mastery and Part 4: Module Magic, both of which apply directly to OpenTofu with no modification.

CI/CD integration uses the official opentofu/setup-opentofu@v1 GitHub Actions action, or provider-specific equivalents for GitLab, Azure DevOps, and Bitbucket. The CI/CD patterns from Part 5: CI/CD Integration in the IaC series map directly. One OpenTofu-specific addition worth implementing in CI/CD pipelines is the global provider cache lock, which became safe for concurrent operations in 1.10:

# GitHub Actions example
- name: Setup OpenTofu
  uses: opentofu/setup-opentofu@v1
  with:
    tofu_version: 1.11.0

- name: Initialise
  run: tofu init
  env:
    TF_PLUGIN_CACHE_DIR: ${{ github.workspace }}/.terraform/providers

# GitHub Actions example
- name: Setup OpenTofu
  uses: opentofu/setup-opentofu@v1
  with:
    tofu_version: 1.11.0

- name: Initialise
  run: tofu init
  env:
    TF_PLUGIN_CACHE_DIR: ${{ github.workspace }}/.terraform/providers

Registry configuration for air-gapped environments uses the new OCI registry support. Providers can be mirrored to your organisation’s container registry and referenced without public internet access:

# .terraformrc equivalent for OpenTofu
provider_installation {
  oci_mirror {
    repository_template = "ghcr.io/your-org/opentofu-providers/${namespace}/${type}"
    include = ["registry.opentofu.org/*/*"]
  }
  direct {
    exclude = ["registry.opentofu.org/*/*"]
  }
}

# .terraformrc equivalent for OpenTofu
provider_installation {
  oci_mirror {
    repository_template = "ghcr.io/your-org/opentofu-providers/${namespace}/${type}"
    include = ["registry.opentofu.org/*/*"]
  }
  direct {
    exclude = ["registry.opentofu.org/*/*"]
  }
}

Roadmap and Trajectory

OpenTofu’s public roadmap reflects community-driven prioritisation, which means the feature set is shaped by what enterprise teams are actually asking for rather than what aligns with a vendor’s commercial product strategy.

Several capabilities in active development are worth monitoring. External key provider stabilisation is expected in 1.12, which will formally stabilise AWS KMS, GCP KMS, and custom key provider integration for state encryption. This matters because state encryption has been a landmark feature since 1.7, but the external key management integration remains experimental in 1.11. Stabilisation removes the last barrier to using encryption in environments where managing a passphrase in a variable is not operationally acceptable.

The dual output format capability (human readable and machine readable simultaneously) is available in nightly builds as of January 2026 and is likely to appear in 1.12. This improves CI/CD pipeline integration significantly, removing the need to choose between outputs optimised for logs and outputs optimised for downstream tooling.

Provider iteration and module loop features that shipped in 1.9 continue to be extended. The for_each capability on provider blocks was one of the most upvoted community requests and its availability in OpenTofu ahead of Terraform is a concrete example of the project’s faster responsiveness to community needs.

The MCP server shipped in 1.10 provides OpenTofu documentation directly to AI coding assistants. As the tooling around AI-assisted infrastructure development matures, first-class integration here gives OpenTofu a positioning advantage for teams incorporating AI into their development workflows, which connects to the broader career shift we mapped in our AI-Augmented Cloud Engineer guide

The project’s support lifecycle guarantees patches for the three most recent releases. The 1.11 series is supported until August 2026. Given the regular release cadence, this provides comfortable runway for enterprise teams who need to operate on supported versions.

Strategic Recommendation

For architects evaluating a greenfield IaC foundation in 2026, the conclusion is not complex once you separate the technical assessment from the historical inertia.

If your organisation runs regulated workloads, needs air-gapped provider distribution, requires state encryption at the IaC layer, or simply values the governance stability of Linux Foundation over IBM-owned commercial software, OpenTofu is the right greenfield choice. The feature set is now genuinely differentiated from Terraform in ways that matter for enterprise operations, and it is on an accelerating trajectory.

If your team is composed primarily of software developers who want to write Python or TypeScript rather than HCL, and the IaC layer needs to behave like application code with unit tests, loops, and abstractions, Pulumi is the right choice regardless of which cloud you are targeting. OpenTofu is the wrong choice for this team profile not because of its technical limitations but because HCL’s declarative model is a poor fit for developer-first teams who already think in general-purpose languages.

If you have existing Terraform expertise, no licensing concerns, and no immediate need for state encryption or OCI registry support, Terraform is defensible. The BSL risk is real but manageable for most organisations. However, if you are starting from scratch, choosing the BSL-licensed option over an otherwise equivalent MPL 2.0 option with superior state security features is difficult to justify architecturally.

The migration post will follow, covering the mechanics of moving an existing Terraform estate to OpenTofu for teams that have made this evaluation and concluded the switch is warranted. For greenfield teams, the evaluation ends here: install tofu, point it at your existing module library if you have one, and proceed.

Useful Links

• OpenTofu Official Documentation
• OpenTofu 1.11.0 Release Notes
• OpenTofu 1.10.0 Release Notes – OCI Registry and S3 Locking
• State Encryption Documentation
• OpenTofu GitHub Repository and RFC Process
• Linux Foundation OpenTofu GA Announcement
• CNCF Sandbox Project Listing
• opentofu/setup-opentofu GitHub Action
• HashiCorp BSL Licence Change Announcement
• OpenTofu Registry