OpenTofu vs Terraform in 2026: Which Should You Use for IaC?

TL;DR

• OpenTofu and Terraform diverged for real in 2026: different licenses, different governance, and a growing list of features that exist in one but not the other.
• OpenTofu carries an OSI-approved MPL 2.0 license under Linux Foundation governance, while Terraform has shipped under HashiCorp's Business Source License 1.1 since version 1.6.
• OpenTofu has shipped native state encryption, for_each support on provider blocks specifically, early variable evaluation, and the -exclude flag, none of which exist in Terraform's open-source CLI. Terraform's main exclusive, Stacks, lives in HCP Terraform rather than the open binary.
• Provider and module compatibility is close to complete on both sides, and independent benchmarking shows performance is nearly identical, since both tools are bottlenecked by cloud API latency, not local processing.
• StackGuardian treats the choice as a non-issue: both tools run as native Workflow types under the same state backend and policy engine, so switching or running both doesn't require a new platform.

For nine years, "Terraform" and "the open-source infrastructure as code standard" meant the same thing. That stopped being true in August 2023, when HashiCorp relicensed Terraform under the Business Source License, and a community fork called OpenTofu emerged in response. What started as a defensive move by a handful of vendors has turned into a genuinely separate tool, with its own governance, its own release cadence, and features that never made it into Terraform's open-source binary.

By 2026, picking between the two is a real decision, not a formality anyone can skip past with "they're basically the same." This post covers what OpenTofu actually is and why it exists; what's genuinely different between it and Terraform today; licensing, features, compatibility, and performance; the code-level differences worth knowing before you migrate either way; and how StackGuardian runs both natively so the choice doesn't lock you into one platform.

What Is OpenTofu and Why Does It Exist?

OpenTofu is a community-driven, MPL-licensed fork of Terraform, created after HashiCorp relicensed Terraform under the Business Source License in 2023. It's governed by the Linux Foundation rather than a single vendor, developed by a coalition of companies and independent engineers who wanted the tool to stay under an open license.

The timeline that produced today's split:

Both events, the relicense and the IBM acquisition, are why this comparison is worth doing seriously in 2026 rather than treating OpenTofu as a niche alternative.

OpenTofu vs Terraform: The 2026 Feature and Governance Comparison

The two tools were nearly identical at the moment of the fork. By mid-2026, OpenTofu was at version 1.12.2 with the OpenTofu registry hosting more than 3,900 providers and 23,600 modules, while Terraform sat at 1.14.x. Both are actively developed, but the gap between them has widened every quarter since the fork.

Independent benchmarking on a mid-size AWS codebase (roughly 400 resources) found performance is not a real differentiator between the two, since both tools spend most of their runtime waiting on cloud provider APIs rather than doing local processing. Don't pick a side based on speed.

What Can OpenTofu Do That Terraform's CLI Still Can't?

OpenTofu has shipped state encryption, for_each on provider blocks, early variable evaluation including backend configuration, the -exclude flag, loopable import blocks, and OCI registry support for both providers and modules. None of these exist in Terraform's open-source CLI as of 2026, and the gap has kept widening well past the initial 1.9 release.

State encryption is the headline feature. Terraform relies on backend-level encryption, an S3 bucket with server-side encryption enabled, for example, which protects the file at rest in storage but not before it gets there. OpenTofu encrypts state and plan files client-side, before they leave your machine, using pluggable key providers:

terraform {
  encryption {
    method "aes_gcm" "default" {
      keys = key_provider.pbkdf2.default
    }
    state {
      method   = method.aes_gcm.default
      enforced = true
    }
  }
}

Supported key providers include AWS KMS, GCP KMS, Azure Key Vault, OpenBao, or a PBKDF2 passphrase. If a state file leaks, either from a misconfigured bucket policy or a compromised CI runner, the contents are ciphertext rather than plaintext secrets and access keys.

Provider for_each, meaning for_each support on provider configuration blocks specifically, lets a single provider block iterate across a map, something Terraform's for_each meta-argument still doesn't support on providers:

provider "aws" {
  for_each = var.regions
  alias    = each.key
  region   = each.value
}

This removes the repetitive provider block or module duplication that multi-region and multi-account Terraform setups have needed for years.

The -exclude flag is the inverse of -target, letting a plan or apply explicitly skip named resources:

tofu plan -exclude=aws_instance.legacy_bastion

Early variable evaluation lets variables resolve early enough to configure the backend itself, something Terraform's CLI still doesn't support, which matters for teams that want dynamic backend configuration without a wrapper script.

OpenTofu 1.8 also added loopable import blocks, letting a single import block iterate over a for_each map to bulk-import many resources of the same type once their identifiers are known, rather than writing one import block per resource. OpenTofu 1.10 followed with OCI registry support, letting providers and modules be distributed through any OCI-compliant registry rather than only the OpenTofu or Terraform registries. Note that native S3 state locking without DynamoDB isn't one of the differentiators here; Terraform picked up the same use_lockfile capability on its S3 backend around the same window, reaching GA in Terraform 1.11, so both tools now support it.

Terraform has two notable exclusives running the other direction. Stacks stays inside HCP Terraform rather than the open binary, alongside Sentinel policies, remote runs, cost estimation, and the private registry, all tied to HashiCorp's commercial platform. More recently, Terraform 1.14 shipped native resource discovery through a terraform query command and list blocks, letting the CLI ask a provider what resources exist outside state directly. OpenTofu doesn't have an equivalent yet; a matching tofu query feature request remains open on its repository.

How Compatible Are OpenTofu and Terraform in Practice?

Migration between the two is close to a non-event for most configurations. The same required_providers block works unchanged in either tool:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

Module compatibility sits near 100% as well, with two real exceptions worth knowing before migrating:

• Modules built around Terraform Stacks or Sentinel policy attachments need refactoring, since neither concept exists in OpenTofu
• A handful of providers have published OpenTofu-specific or Terraform-specific releases, though the majority run unchanged on both, and subtle version mismatches can surface in long-tail or internal custom providers built against Terraform's plugin SDK

Practically, migration usually means swapping the terraform binary for tofu, with only the terraform_version marker in state changing on the first apply. State stored in S3, GCS, Azure Blob, or any other supported backend works for both tools without modification. The friction that does show up tends to live outside the Terraform configuration itself: CI scripts and Dockerfiles that hardcode the terraform binary name, or module source addresses explicitly pinned to registry.terraform.io, need a manual pass before the swap is complete, since neither one breaks loudly, they just quietly keep resolving against the wrong tool or registry.

Does the License Actually Matter for Your Team?

The BSL doesn't affect most end-user teams who simply run terraform apply against their own infrastructure. The license restricts building "a competitive offering," defined as a product sold to third parties that significantly overlaps HashiCorp's commercial products. Internal use, including running Terraform inside your own CI/CD pipelines, is explicitly permitted. Each BSL-licensed release also converts to MPL 2.0 automatically, but only four years after that version's release date, so the restriction isn't permanent per release, just delayed well past the point where most teams have already moved on to newer versions.

Where it actually creates friction:

• Vendors building on top of Terraform: managed CI/CD platforms, drift-detection tools, and policy-as-code systems that wrap or extend Terraform face real legal review under the BSL
• Procurement and compliance review: the license difference surfaces in legal and vendor review more than in daily engineering work, which matters for regulated industries or enterprises with strict vendor policies
• Cost: HCP Terraform ended its free tier in March 2026, which reframes the cost conversation for any team relying on it for remote state or execution

For a platform team running infrastructure internally, the license is mostly a procurement conversation, not an engineering blocker. For anyone building a product on top of IaC, it's the first question to answer before writing code.

Worth noting precisely: OpenTofu isn't a workaround to the BSL; it's outside the BSL's scope entirely. It forked from Terraform's last MPL 2.0 release, published before the relicense took effect, so nothing in OpenTofu's codebase was ever covered by HashiCorp's license in the first place. Building a competitive product on OpenTofu doesn't require interpreting HashiCorp's additional use grant at all.

How Do You Decide Between OpenTofu and Terraform?

The deciding factor tends to be existing platform commitment more than the license alone.

Stay on or choose Terraform if:

• You're invested in HCP Terraform, need Stacks, or need enterprise support with an SLA
• Your workflow depends specifically on Sentinel policies
• You rely heavily on community resources, since the Terraform community remains significantly larger, meaning documentation, Stack Overflow answers, and tutorials are more abundant

Choose OpenTofu if:

• You're setting up a greenfield, self-managed environment and want open governance with no license ambiguity
• You need state encryption, for_each support on provider blocks, or the -exclude flag now, without waiting on Terraform's roadmap
• You're building internal tooling or a product on top of IaC and want zero licensing ambiguity

What If You Don't Have to Choose?

The framework above assumes a team has to commit to one binary. That assumption holds if your execution platform, state backend, and policy engine are all tied to a single tool. It stops holding if the platform underneath is tool-agnostic to begin with.

The real operational question isn't "which binary do we standardize on?" It's whether your governance layer, state management, and policy evaluation depend on that choice at all. If they do, switching tools later means rebuilding policy coverage from scratch. If they don't, the choice between OpenTofu and Terraform becomes a per-workflow decision instead of an organization-wide bet.

How Does StackGuardian Handle Both Terraform and OpenTofu?

StackGuardian runs Terraform and OpenTofu as separate native Workflow types inside the same platform, not as two disconnected toolchains bolted together. Creating a Workflow through the wizard offers both as first-class options, each configured through the same four steps: Source and Parameters, Terraform Configuration, Deployment Environment, and version pinning.

State management doesn't fork by tool, even though the toggle carries the engine's name. A Terraform Workflow has "Use Managed Terraform State" under Terraform Customizations; an OpenTofu Workflow has the equivalent "Use Managed OpenTofu State" under OpenTofu Customizations. Enabling either gives that Workflow the same centralized backend, with locking, versioning, and encryption handled identically regardless of which binary runs. A Terraform Workflow and an OpenTofu Workflow in the same Workflow Group both authenticate to that backend the same way, through the platform-managed connection rather than a separately configured backend block per engine.

Version pinning happens per Workflow, not per platform. Each Workflow's Terraform or OpenTofu Customizations panel includes a version selector, along with an optional Custom Tool Path for teams running a non-standard binary on a private runner. A team running OpenTofu 1.12 for new workflows and Terraform 1.10 for legacy ones pins each version at the Workflow level, no separate platforms or duplicated infrastructure required to keep both versions correct simultaneously.

Policy evaluation is where the tool-agnostic design matters most. A Tirith or OPA policy scoped to a Workflow Group evaluates every Workflow inside that group, whether the underlying plan came from terraform plan or tofu plan. Since both tools produce a comparable plan structure, the same evaluator applies to both without a separate ruleset:

{
  "meta": {
    "required_provider": "stackguardian/terraform_plan",
    "version": "v1"
  },
  "evaluators": [
    {
      "id": "require-encryption",
      "description": "Require encryption on every S3 bucket regardless of engine",
      "provider_args": {
        "operation_type": "attribute",
        "terraform_resource_type": "aws_s3_bucket",
        "terraform_resource_attribute": "server_side_encryption_configuration"
      },
      "condition": {
        "type": "IsNotEmpty",
        "error_tolerance": 1
      }
    }
  ],
  "eval_expression": "require-encryption"
}

Tirith's terraform_plan provider is documented specifically for Terraform and CloudFormation configurations. In practice, a policy written against this provider generally applies to an OpenTofu-produced plan too, since OpenTofu's plan JSON output is designed to stay compatible with Terraform's, but teams running mixed environments should verify evaluator behavior against their own OpenTofu plans rather than assuming full parity by default.

One thing worth planning for in a mixed fleet: Terraform and OpenTofu versioned independently after the fork, so a terraform_version string alone doesn't reliably tell a policy which engine actually produced a given plan; "1.9" means something different depending on which binary shipped it. Teams writing policies that need to treat the two engines differently, rather than identically, should scope that distinction explicitly at the Workflow or Workflow Group level rather than inferring it from a version number inside the plan.

Drift detection, RBAC, and audit logging don't fork by tool either. Automated Drift Check runs on the same schedule regardless of engine, RBAC controls who can create or modify Workflows of either type identically, and every action lands in the same Audit Logs, exportable to JSON or CSV, whether it came from a Terraform apply or an OpenTofu apply.

Should You Run Both Terraform and OpenTofu at Once?

Running both isn't a compromise position; it's the path many teams actually land on. Existing HCP Terraform workspaces stay where they are, since migrating live production state carries its own risk regardless of which tool it moves to. New workloads default to OpenTofu, where the license question doesn't need revisiting for every new project.

Inside StackGuardian, that split doesn't require two platforms or two credential sets. A Workflow Group can contain Terraform Workflows and OpenTofu Workflows side by side, governed by the same Policy Sets, the same RBAC, and the same Audit Logs. Running both tools stops being an operational burden and becomes a configuration choice made per Workflow, not per platform.

Conclusion

The OpenTofu fork stopped being a hedge or an experiment somewhere between the 2023 relicense and IBM's 2025 acquisition of HashiCorp. By 2026, the two tools have genuinely different licenses, governance models, and feature sets, from client-side state encryption to provider iteration, and the decision between them is a real one for any team setting up new infrastructure or reevaluating an existing HCP Terraform commitment.

What matters more than the choice itself is whether the platform underneath forces that choice to be permanent. A team on a Terraform-only platform pays a real migration cost if the license or governance calculus changes later. A team on a platform that treats both tools as equally native keeps that decision reversible, workflow by workflow, without rebuilding state management or policy coverage from scratch.

Explore how StackGuardian supports both engines under one policy and execution layer, or see the StackGuardian documentation for the full Workflow configuration reference.

FAQs

1. Is OpenTofu a drop-in replacement for Terraform?

For most workflows, yes. OpenTofu shares Terraform's HCL syntax, provider protocol, and state model, so migration is usually swapping the binary rather than rewriting configuration. Teams depending on HCP Terraform-exclusive features like Stacks or Sentinel need a separate migration plan for those specific pieces.

2. Does the Terraform BSL license affect internal use?

No. The BSL doesn't affect teams that simply run terraform apply against their own infrastructure. It restricts building a competitive offering sold to third parties that significantly overlaps HashiCorp's commercial products; internal use, including CI/CD pipelines, is permitted.

3. What features does OpenTofu have that Terraform's open-source CLI lacks?

Native client-side state encryption, provider for_each for iterating provider blocks, early variable evaluation for backend configuration, and the -exclude flag. None of these are available in Terraform's open-source binary as of 2026.

4. Can I run both Terraform and OpenTofu in the same organization?

Yes. Many teams keep existing HCP Terraform workspaces in place while defaulting new projects to OpenTofu. On a platform like StackGuardian, both run as native Workflow types under the same Workflow Group, policy scope, and state management, so running both doesn't require separate credentials or a second platform.

5. Does StackGuardian support OpenTofu natively?

Yes. OpenTofu is a native Workflow type alongside Terraform, CloudFormation, Ansible, Helm, and Kubectl, using the same Managed Terraform State backend and evaluated by the same Tirith or OPA policies regardless of which tool a given Workflow runs.