OpenTofu vs Terraform: The 2026 Comparison for IaC Teams

For most teams in 2026, OpenTofu is the lower-risk default. The question has shifted from "is OpenTofu safe to try?" to "which roadmap do we want to depend on?", and that turns on license (MPL 2.0 vs BSL 1.1), governance (Linux Foundation vs IBM) and a handful of CLI features only OpenTofu has, not on syntax. Stay on Terraform if you run HCP Stacks in production or procurement requires HashiCorp as a vendor. Disclosure: Scalr supports both engines, helped found OpenTofu, and has a commercial interest in platforms that run both; the goal here is to separate what's different from what's branding.

What's the difference between OpenTofu and Terraform?

OpenTofu is the open-source fork of Terraform, created after HashiCorp relicensed Terraform under the Business Source License in August 2023. As of July 2026 the practical differences are the license (MPL 2.0 vs BSL 1.1), who sets the roadmap (a Linux Foundation committee vs HashiCorp/IBM), and a set of CLI features OpenTofu shipped that Terraform's open binary lacks: state encryption, provider for_each, early variable evaluation, and -exclude. Configurations, providers, and day-to-day commands are near-identical.

OpenTofu vs Terraform at a glance

Why did OpenTofu fork from Terraform?

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.
• July 2024 (v1.8). Early variable evaluation lands.
• January 2025 (v1.9). 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.

Is Terraform still open source?

Not by the standard definition. Terraform releases since 1.6 ship under the Business Source License 1.1, which the Open Source Initiative doesn't recognize as open source. You can still download Terraform for free, read the source, and run it in production inside your own organization; what BSL forbids is offering Terraform to third parties in a way that competes with IBM's (formerly HashiCorp's) paid products. Teams that need an OSI-approved license use OpenTofu, which stayed on MPL 2.0.

The version cutoff matters more than the label. As of July 2026 the LICENSE file scopes BUSL 1.1 to Terraform 1.6.0 and later, and 1.5.7 was the last MPL 2.0 release. Is Terraform still open source? walks through the file clause by clause.

BSL 1.1 lets you run, read, and extend Terraform for your own use. What it restricts is using Terraform to provide a service that HashiCorp considers competitive with its own, and each release only flips to MPL four years after it ships. So any vendor offering a managed Terraform service has to take a position on whether it falls inside the grant; some continued, some moved their managed offering to OpenTofu, a few asked HashiCorp directly. For an internal platform team running Terraform against its own accounts, none of this changes the day-to-day. It matters when legal or procurement asks whether the tooling is open source (public-sector reviews answer that against the OSI list), and it matters a lot if your product runs 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.

The cost of foundation governance is speed: decisions wait on RFCs and the contributors who show up to argue them. We think that's the right trade, since the alternative is a roadmap set by one company whose commercial interests may not match yours.

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 not deeply committed to HCP Terraform-specific workflows, the reasons stack up:

• 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. On a per-run platform like Scalr, an OpenTofu run bills exactly like a Terraform run under usage-based pricing, free up to 50 runs a month.

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). If you are coming off Terraform Cloud specifically, the order of operations matters more than the engine switch does, and migrating from Terraform Cloud to OpenTofu works through why.

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. What an OpenTofu management platform is expected to cover sets out what to compare them on.
• 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

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.

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.

Governing a mixed fleet

The safer pattern for most teams is to support both engines, migrate workspace by workspace, and keep the execution platform from becoming the bottleneck. That creates a governance question that didn't 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, free up to 50 runs a month.

You can see the mix in Scalr's own numbers. Scalr runs the open-source line: Terraform up to 1.5.7, its last MPL release, and OpenTofu for anything newer. As of mid-2026 OpenTofu carries about 63% of runs and 72% of new workspaces. Its share of new workspaces went from roughly 56% to 76% in the first half of the year. But the number of accounts running each engine is still about even, which is the whole argument for supporting both instead of forcing a 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 is the lower-risk default. Migration is mechanical for most workspaces, the CLI features that matter shipped there first, and no single company can relicense it. 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.

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