OpenTofu vs Terraform: The 2026 Comparison for IaC Teams

Reviewed for accuracy by Ryan Fee on May 12, 2026.

For most teams in 2026, OpenTofu is the lower-risk default, and the rest of this guide walks through why. The question that decides it has shifted. In 2024 it was "is OpenTofu safe to try?" Now it's "which roadmap do we want to depend on?" The answer has less to do with language syntax and more to do with governance, state handling, orchestration patterns, and how much HCP Terraform a team already runs.

Disclosure. Scalr supports both Terraform and OpenTofu and was a founding contributor to OpenTofu. We have a commercial interest in customers using platforms that support both engines. The goal of this article is to separate what is actually different from what is just branding.

Snapshot

How we got here

For roughly nine years, Terraform was open source in the way most engineers mean it. From its first release in 2014 through July 2023, every line shipped under the Mozilla Public License v2.0. You could read it, run it, modify it, and build a product on top of it without asking permission.

That ended on August 10, 2023. In one announcement, HashiCorp re-licensed Terraform, Vault, Consul, Nomad, Boundary, Packer, and Waypoint under the Business Source License 1.1, which is not an OSI-approved open source license. The code stayed publicly visible, but the new license added a catch: you could no longer use it to build a product that HashiCorp considered competitive with its own offerings.

Within weeks, a coalition that included Gruntwork, Spacelift, Harness, env0, and Scalr published the OpenTF manifesto and announced a fork from the last MPL release. In mid-September, the project moved to the Linux Foundation, renamed itself OpenTofu, and gave the CLI a new binary name (tofu). We covered that move in Finding a home for OpenTofu.

OpenTofu v1.6 followed in January 2024 with full compatibility back to Terraform 1.5. Since then:

• April 2024. OpenTofu v1.7 ships state encryption, the first major feature divergence.
• Mid-2024 (v1.8, July 29, 2024). Early variable evaluation lands.
• January 2025 (v1.9, January 9, 2025). Provider for_each and the -exclude flag ship.
• February 2025. IBM closes its acquisition of HashiCorp; Terraform is now an IBM product.
• April 2025. The Cloud Native Computing Foundation accepts OpenTofu.
• 2025. OpenTofu 1.10 adds OCI registry support, native S3 state locking, experimental OpenTelemetry tracing, target and exclude file inputs, and a set of workflow improvements (global provider cache lock, deprecation support, enhanced moved and removed blocks, external key providers).
• Late 2025 / 2026. OpenTofu 1.11 adds ephemerality, ephemeral resources, write-only attributes, and the enabled meta-argument, while continuing to evolve independently from Terraform's roadmap.

At this point, treating OpenTofu as just a renamed Terraform 1.5 fork is out of date. It's a separately governed project with three years of independent decisions behind it.

The license question

For an engineer typing tofu apply against their AWS account, the difference between MPL 2.0 and BSL 1.1 is invisible. Both binaries call the same APIs. The license question only surfaces when somebody asks who else is allowed to do that.

MPL 2.0 is what most engineers mean when they say "open source." Use it for anything. Sell products built on it. Modify it, as long as the modifications to MPL files go back under MPL. There is no clause that asks what business you're in.

BSL 1.1 reads differently. You can run it, you can read it, and you can extend it for your own use. What the additional use grant restricts is using Terraform to provide a service that HashiCorp considers competitive with its own offerings. Each released version eventually flips to MPL, but only four years after that version's release date. So any vendor offering a managed Terraform service has to take a position on whether their service falls inside or outside the grant. Some have continued, some have switched their managed offering to OpenTofu, and a few have asked HashiCorp directly.

Most internal platform teams will not feel this difference in daily usage. If you are running Terraform on your own pipelines against your own cloud accounts, the BSL usually has no effect on what you do day to day. It starts to matter when legal or procurement asks whether the IaC tooling is open source, particularly in public sector environments where that question is answered against the OSI list. It matters more if your product or service involves running Terraform on behalf of other customers.

Where the engines actually differ

OpenTofu and Terraform overlap on most of their feature surface. Resources, data sources, providers, modules, variables, locals, outputs, tfvars files, workspaces, and backends behave the same way in both tools, which is the main reason migration is cheap. Most teams will not notice the fork during a normal plan or apply. They notice it in these areas.

State encryption, in the CLI

State files are the most sensitive thing a Terraform user produces. Database credentials, API tokens, private endpoints, the entire shape of your infrastructure: all of it ends up serialized as plaintext JSON. Remote backends like S3 will encrypt the file at rest, but that protects the bucket, not the workflow. Anyone who can pull state can still read it.

OpenTofu v1.7 closed that gap by adding encryption to the CLI itself. The block looks like this:

terraform {
  encryption {
    key_provider "aws_kms" "ops" {
      kms_key_id = "alias/opentofu-state"
      region     = "us-east-1"
    }
    method "aes_gcm" "default" {
      keys = key_provider.aws_kms.ops
    }
    state {
      method = method.aes_gcm.default
    }
    plan {
      method = method.aes_gcm.default
    }
  }
}

Key providers include PBKDF2 passphrases for solo work, AWS KMS or GCP KMS for cloud-native setups, and OpenBao for self-hosted environments. Terraform's open CLI does not provide an equivalent configuration-level state encryption feature. HCP Terraform offers platform-level state storage protections, but those are managed by HashiCorp's service and are not equivalent to portable, CLI-managed encryption that travels with your own backend.

One ordering detail catches teams enabling this for the first time: the encryption block resolves earlier in the run lifecycle than normal variable loading. A Scalr customer in a regulated industry hit this with runs that failed intermittently at the state-encryption stage. Their KMS key ID was defined in a linked .tfvars file, which loads too late for the encryption configuration to see it reliably. Moving the key ID into platform-level variables (anything resolved before variable-file processing) fixed it. If your key reference lives in a tfvars file and runs fail before plan output appears, this ordering is the likely cause.

Iterating providers with for_each

Deploying the same module across multiple AWS regions used to require a copy-pasted provider block per region. OpenTofu 1.9 made provider configurations iterable. The alias is static, and each.value selects the region from the iteration:

variable "regions" {
  type    = set(string)
  default = ["us-east-1", "eu-west-1", "ap-southeast-2"]
}
 
provider "aws" {
  alias    = "by_region"
  for_each = var.regions
  region   = each.value
}
 
module "regional" {
  source   = "./regional"
  for_each = var.regions
 
  providers = {
    aws = aws.by_region[each.key]
  }
}

The iterated provider is consumed by passing aws.by_region[each.key] through the module's providers block. In Terraform, this still requires a hand-written provider block per region.

Variables in places Terraform restricted them

For most of Terraform's history, the top-level terraform { backend { … } } block did not evaluate variables, locals, or data sources. This restriction is part of why teams reach for Terragrunt, which uses a templating layer above Terraform to inject backend configuration per environment. OpenTofu 1.8 lifted the restriction directly:

locals {
  env = var.environment
}
 
terraform {
  backend "s3" {
    bucket = "tfstate-${local.env}"
    key    = "${local.env}/terraform.tfstate"
  }
}

This removes a common reason for wrapper scripts and templating in multi-environment setups. The full pattern is covered in dynamic backend blocks with OpenTofu. Terragrunt still has reasons to exist on top of OpenTofu (dependency graphs, run-all, output sharing across stacks), but per-environment backend variation is no longer one of them.

Terraform has added some flexibility in newer releases (for example, variables and locals in module source and version attributes), but OpenTofu's early-evaluation support remains broader in workflow areas such as backend configuration.

The inverse of -target

terraform apply -target=foo has existed since the early Terraform releases. It is useful when you want to apply a single resource, but it is the wrong tool when you want to apply everything except one or two resources. OpenTofu 1.9 added the matching flag:

# Apply everything except the production database
tofu apply -exclude 'aws_db_instance.prod'
 
# Two resources at once
tofu apply \
  -exclude 'aws_db_instance.prod' \
  -exclude 'aws_rds_cluster.analytics'

Phased rollouts, blast-radius control, "leave that resource alone while it's being manually fixed" workflows all get simpler with this flag.

Terraform Stacks

Stacks is the one item on this list that Terraform has and OpenTofu does not. HashiCorp's Stacks lets you orchestrate many configurations under a shared lifecycle. Stacks are defined in configuration files and have CLI integration, but the managed lifecycle that makes Stacks useful is an HCP Terraform feature rather than a standalone open-CLI workflow. If you need that orchestration pattern on the OpenTofu side today, the options are Terragrunt's run-all, a TACoS platform that orchestrates multiple workspaces (Scalr, Spacelift, env0), or waiting on the OpenTofu community's in-progress Stacks RFC. None of these is a feature-for-feature replacement for Stacks as HashiCorp implements it.

Providers and registries

In most practical cases, both engines use the same provider artifacts. The default registry host differs between the two, and explicit source addresses or lock files may need review during a migration. The widely used providers (AWS, Azure, GCP, Kubernetes, and the other major ones) are distributed through both registries. For less common or newly published providers, teams should verify availability and source addresses during migration.

A standard required_providers block:

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

works in both engines. OpenTofu resolves hashicorp/aws to its own registry; Terraform resolves it to HashiCorp's. If your existing configuration explicitly pins source = "registry.terraform.io/hashicorp/aws", OpenTofu honors that and pulls from HashiCorp's registry instead of its own. During a migration, review the required_providers blocks and the lock file (.terraform.lock.hcl) to confirm the source addresses and checksums match what your team intends.

The two engines also validate registry metadata differently, and that difference can surface with no code change on your side. A team that came back to a parked migration found tofu plan suddenly emitting [WARN] Provider scalr/scalr (registry.scalr.io) gpg key expired, this will fail in future versions of OpenTofu. Nothing in their configuration had changed; OpenTofu had added forward-looking GPG key-expiry validation for third-party registries, a check Terraform does not surface the same way. The warning is doing its job, since a stale signing key would eventually break provider installation, but if you park a migration for a few months, expect the toolchain to have developed opinions by the time you return.

The commands you actually type

For routine init, plan, and apply workflows, the commands are nearly identical:

Most Terraform 1.5-era configurations run on OpenTofu without modification. The compatibility direction that doesn't hold is forward: configurations that use a Terraform 1.6+ exclusive feature (mostly HCP-only blocks) won't run on OpenTofu, and configurations that use OpenTofu-specific features (state encryption blocks, provider for_each, the -exclude flag) won't run on Terraform. For a more granular language-level diff, the OpenTofu Language Guide has the full surface.

Who decides what ships next

Governance sounds abstract until a roadmap decision affects you. Over a multi-year horizon it tends to drive more of the practical differences than any single feature.

OpenTofu's roadmap is set by a Technical Steering Committee under the Linux Foundation, with the project also sitting inside the CNCF. The committee is multi-vendor by design: no single company has the votes to override the others, and feature direction is decided through public RFCs that anybody can read. There are weekly community calls. The minutes are on GitHub. When a contentious change gets argued about, the argument is in the open.

Terraform's roadmap is set inside HashiCorp, which is now an IBM subsidiary. The release notes are public, the issue tracker is public, but the strategic calls (the BSL relicense, the decision to make Stacks HCP-only, anything about the future of the Terraform Registry itself) are made internally. Community input flows through GitHub issues and HashiCorp's product management, and what gets prioritized is what aligns with HashiCorp's (now IBM's) commercial strategy.

Both models have trade-offs. Foundation governance can be slower to reach decisions, and it depends on the contributors who actively participate in meetings and RFCs. Vendor governance is faster, but concentrates decision-making inside one company whose commercial interests may not match yours. Which trade-off matters more to your team usually depends on whether you trust the vendor's long-term direction.

When Terraform is still the right call

There are still cases where staying on Terraform makes sense:

• Heavy HCP Terraform users with Stacks in production. Stacks has no open-source equivalent today; teams that already build their orchestration around it should stay on Terraform until the OpenTofu Stacks RFC ships.
• Teams inside an IBM Cloud Pak environment. IBM's support contracts cover Terraform as an IBM product, which simplifies escalation paths for shops that are already standardized on IBM tooling.
• Organizations whose procurement explicitly approves HashiCorp as a vendor and where a single-vendor roadmap is a stated requirement rather than a risk to manage.
• Workloads that depend on a Terraform CLI feature OpenTofu has not adopted yet. This is uncommon, but it happens during periods when HashiCorp ships something new in the CLI and the OpenTofu maintainers have not yet decided whether to follow.

When OpenTofu is the right call

For teams that are not deeply committed to HCP Terraform-specific workflows, OpenTofu is increasingly the default recommendation. Terraform did not stop working; OpenTofu now has enough independent feature momentum that the license and governance advantages no longer come with much operational penalty:

• OSI-approved license. MPL 2.0 is an unambiguous open source license, which removes legal-review friction in regulated and public-sector environments.
• State encryption in the CLI. No managed-platform dependency required to encrypt state and plan data before it lands in your backend.
• Multi-vendor governance. No single company can unilaterally change licensing or roadmap direction.
• Recent feature additions. Provider iteration with for_each, early variable evaluation, and the -exclude flag have been frequently requested by Terraform users and shipped in OpenTofu first.
• First-class support in the TACoS ecosystem. Scalr, Spacelift, env0, and Harness all support both engines; all four were among the founding contributors to OpenTofu.
• Run cost. OpenTofu runs in Scalr bill the same as Terraform runs under usage-based pricing (the first 50 runs each month are free), which can materially affect total cost compared with HCP Terraform's per-run billing. The pricing model differences also matter: some alternatives use concurrency-based pricing (fixed parallel run slots that you pay for whether or not engineers are running plans), while Scalr's usage-based pricing charges only for runs that actually executed, with no slot to mis-provision against your release cadence.

Where OpenTofu can still cost you time

OpenTofu is not a zero-risk switch. The biggest costs are not in the common Terraform language features; they are in the edge cases:

• CI scripts and Dockerfiles that assume the terraform binary name, hardcoded paths, or specific environment variables.
• Lock-file churn when the lock file is regenerated against the OpenTofu registry.
• Source-address assumptions in modules that explicitly target registry.terraform.io.
• Terraform Cloud or HCP-specific workflows (remote runs, Stacks, no-code modules) that have no direct OpenTofu equivalent; teams leaving those behind usually pair the engine switch with choosing a TFC replacement that runs OpenTofu natively.
• New Terraform CLI features that OpenTofu has not adopted, where a small number of workspaces become version-locked until OpenTofu follows.
• Internal stakeholders, particularly in procurement or security review, that treat the word "fork" as a red flag and need context before signing off.

There is also a class of breakage that did not exist when one vendor shipped the whole stack: the ecosystem now moves on its own cadence, and your runtime environment has to keep up. One team's runs began failing with /lib/x86_64-linux-gnu/libc.so.6: version 'GLIBC_2.32' not found (and the equivalent for GLIBC_2.34). Their execution image was still Debian 11 while newer provider binaries had been compiled against a newer glibc. Updating the base image fixed it, but nothing in a Terraform-era runbook predicts that failure mode.

A large enterprise we work with at Scalr hit a fleet-scale version of the same lesson. Their agents were pinned at 0.55.1 while their workspaces were set to "latest" OpenTofu; when latest became OpenTofu 1.12, every run failed until the agents were upgraded, and rebuilding their hardened custom agent image broke a second time because the new base image had moved to Debian trixie. OpenTofu's faster release train demands a matching upgrade cadence on your side. "Pin to latest" turned a routine release into a fleet-wide outage.

None of these is usually a blocker on its own. Together they are why a migration that looked like a five-minute binary swap can take an afternoon, and why a phased rollout per workspace is the standard recommendation rather than a single-day org-wide cutover.

What migration actually looks like

For most workspaces, migrating from Terraform to OpenTofu is mechanical:

1. Run terraform plan and confirm there are no pending changes.
2. Back up the state file and any remote state copies.
3. Install the tofu binary alongside terraform. The two binaries do not conflict on PATH.
4. From the same working directory, run tofu init -upgrade to rewrite the lock file against the OpenTofu registry.
5. Run tofu plan. This is where you find out whether anything in the configuration depends on a Terraform feature that OpenTofu does not support.
6. If the plan reports no changes, run tofu apply. The next state write replaces the terraform_version marker with OpenTofu's version. The resource entries in state are unchanged.

Automated migration tooling can stumble where the manual sequence would not, usually on attributes that only exist on the Terraform Cloud side. A customer's very first workspace migration off TFC failed with Error migrating workspace <name>: none is not an allowed value. A TFC workspace attribute was set to the literal value none, which the OpenTofu-targeted path rejected. The fix was in the tooling, and the lesson generalizes: migration scripts have to translate TFC-isms into valid values for the target platform, not copy them across verbatim.

If you are on Terraform 1.5.x, migration is essentially a no-op. If you are on Terraform 1.6 or later, audit your configuration for HCP-exclusive features (Stacks, no-code modules, certain remote backend extensions) before switching; for most workspaces this audit takes minutes. The What is OpenTofu? guide covers the playbook in more detail, and debugging OpenTofu apply failures covers the issues that occasionally arise after migration (most commonly authentication or stale state locks).

Performance, stability, and tooling

In practice, performance is comparable. Both engines build the same resource graph, parallelize at the same depth, and bottleneck on the same external provider APIs. For typical workloads, variance in plan and apply times is dominated by cloud API latency rather than by anything the engine itself does.

Stability is also comparable. OpenTofu's first releases after the fork had the rough edges that any new project has, but the release cadence from v1.7 onward has been steady. Regressions are caught in CI, and OpenTofu inherits the existing Terraform test suite as a baseline.

Most third-party tooling works with both engines:

• CI runners. GitHub Actions, GitLab CI, Jenkins, and Buildkite have actions or plugins for both terraform and tofu.
• TACoS platforms. Scalr, Spacelift, env0, and Harness all support both engines in the same account.
• Linters and security scanners. tflint, tfsec, checkov, tfupdate, and tflocal all run against both.
• IDE extensions. The terraform-ls Language Server treats .tf and .tofu files interchangeably, and the VS Code Terraform extension works against either engine.
• Module sources. Modules published to the Terraform Registry, the OpenTofu Registry, or Git remain usable from both engines.

Older scripts and CI configurations that hardcode the terraform binary name or registry.terraform.io URLs do need to be updated. Most actively maintained tooling has added OpenTofu support since 2024, so this tends to be a one-time audit rather than ongoing friction.

Frequently asked questions

Is OpenTofu a fork or a rewrite?

A fork. It started from Terraform 1.5.x's codebase and inherits the full pre-fork git history. From v1.6 onward, the two projects develop independently.

Can I run both side by side?

Yes, and many teams do during migration. The binaries don't conflict on PATH, so install both and pick per project. Scalr (and most other TACoS) lets you set the engine per workspace, which is how most teams roll out OpenTofu gradually.

Will my existing Terraform state work in OpenTofu?

State produced by Terraform 1.5.x generally works in OpenTofu without conversion, and many later Terraform states also work as long as the configuration does not depend on Terraform-only features. Always run tofu plan first to confirm OpenTofu reads the state cleanly before applying. On the first tofu apply, the terraform_version marker in state is rewritten to OpenTofu's version; the resource entries are not modified.

Are the providers different?

No. Same binaries, same release pipelines. The only difference is which registry your required_providers resolves against by default, and you can pin to either explicitly if it matters.

Does HashiCorp consider OpenTofu a "competitive offering" under the BSL?

The BSL's additional use grant does not name OpenTofu specifically. More importantly, OpenTofu was forked from a pre-BSL MPL-licensed release, so the BSL does not apply to OpenTofu's codebase. The Linux Foundation and OpenTofu's legal counsel reviewed the licensing position before the fork was published.

Will IBM open-source Terraform again?

There has been no public announcement to that effect as of May 2026. IBM has historically maintained open-source licenses on its acquisitions (Red Hat being the most prominent example), but the BSL on Terraform remains in place.

If a small team is starting fresh in 2026, which one should it pick?

OpenTofu is the lower-risk choice for most new IaC adoptions. It provides an OSI-approved license, multi-vendor governance, full provider compatibility, and the recent CLI features described above. Teams that already pay for HCP Terraform and use Stacks heavily should evaluate the Stacks dependency before switching.

The operational takeaway from the comparison above is not that every team must standardize on one engine immediately. The safer pattern is to support both, migrate workspace by workspace, and keep the execution platform from becoming the bottleneck.

Running both does create a governance question that did not exist before the fork. One platform team wrote an OPA policy to flag any run still executing under Terraform, and discovered that version numbers alone no longer identify the binary. "1.6" means something different in each fork, so a version check cannot tell you which engine ran. The fork choice itself had become a governable, auditable attribute, and they needed it exposed in policy input directly (an iac_platform attribute was added to the policy input about two weeks later). If you are governing a mixed fleet, plan for the engine to be a first-class attribute in your policies, not something inferred from a version string.

How Scalr fits

Scalr was a founding contributor to OpenTofu, and supports both engines in the same account. From a Scalr account you can:

• Run Terraform and OpenTofu workspaces side by side, each pointing at the same VCS or module source.
• Switch a workspace between engines with one configuration change; no state migration is required.
• Apply the same private module registry, drift detection, OPA policy enforcement, and RBAC across both engines.
• Run OpenTofu workloads under the same usage-based pricing as Terraform, with the first 50 runs each month free.

The mix is visible in Scalr's own usage. Scalr runs the open-source line: Terraform through its last MPL release, 1.5.7, and OpenTofu for anything newer, and within that, OpenTofu is the majority engine as of mid-2026: roughly 63% of runs and 72% of newly created workspaces, with its share of new workspaces rising from about 56% to 76% over the first half of 2026, while a similar number of accounts still run each engine. That is the practical case for supporting both rather than forcing a single-engine cutover.

For teams in the middle of evaluating OpenTofu while still running existing Terraform workspaces, a runtime that supports both engines removes the need to commit to one engine across all workspaces at once.

The verdict for 2026

OpenTofu and Terraform are no longer interchangeable products with different names. They differ on licensing (MPL 2.0 vs BSL 1.1), on governance (Linux Foundation vs HashiCorp/IBM), and on a set of CLI features that have shipped in OpenTofu but not in Terraform's open-source CLI. For most teams, migration is mechanical, and OpenTofu's independent feature momentum has narrowed the operational gap between the two, so OpenTofu is the lower-risk default. Stay on Terraform if you have HCP Stacks in production, run inside an IBM Cloud Pak environment, or have a procurement structure that specifically requires HashiCorp as a vendor.

For a deeper reference on OpenTofu itself, see What is OpenTofu?. For pipeline patterns that apply to both engines, see our CI/CD guide for Terraform and OpenTofu.