Terraform vs OpenTofu in 2026: the license fork, the feature gap, and which to run.

IWhat happened: the BSL relicense and the fork

The split is a licensing event first. The technical differences followed from it.

On 10 August 2023 HashiCorp announced that its products, Terraform included, would move from the Mozilla Public License 2.0 to the Business Source License 1.1 for future releases (HashiCorp). Terraform 1.5.x and earlier stayed MPL; later versions ship under BSL.

The BSL is source-available, not open source. You can read, use and modify the code, but not to build a product that competes with HashiCorp's commercial offerings, such as hosted Terraform as a service. Each BSL release converts to MPL 2.0 four years after it ships. For a startup running terraform apply against its own AWS account, nothing practical changed. The community objection was about precedent: a tool open for nearly a decade was relicensed by one vendor.

The community asked HashiCorp to revert, then forked the last MPL release. The fork, renamed OpenTofu, became a Linux Foundation project on 20 September 2023 (Linux Foundation). OpenTofu 1.6.0, the first stable release, shipped on 10 January 2024 (OpenTofu).

IIHow compatible are they?

OpenTofu forked from Terraform 1.5 and kept compatibility on purpose. Knowing exactly what is shared is the core of the practical decision.

OpenTofu reads the same HCL, so your .tf files do not change. It speaks the same provider plugin protocol, so the AWS, Kubernetes and thousands of other providers work unchanged. It reads and writes the same state format, so an existing terraform.tfstate needs no conversion. The CLI mirrors Terraform: tofu init, plan, apply, destroy and state commands.

Compatibility is not guaranteed at the edge of the language. The projects now develop independently, so a brand-new function or syntax feature may land in one tool a release before the other. If your configuration depends on a just-released feature, check it exists in the target tool before you switch.

IIIState encryption: OpenTofu's clearest lead

The most cited technical difference is client-side state and plan encryption, which OpenTofu added in 1.7 and Terraform has no native equivalent for.

State files are a known liability: they hold the full resource graph and can hold secrets in plaintext (database passwords, generated credentials, keys). Backend encryption at rest, such as S3 with SSE-KMS, protects the stored bytes, but the state is plaintext again the moment it is read into a laptop or a CI job.

OpenTofu encrypts state and plan files on the client before they leave the machine and decrypts them only in memory (OpenTofu 1.7 release notes). You configure a key provider (AWS KMS, GCP KMS, OpenBao or a passphrase, among others) and an encryption method (OpenTofu docs); from then on the artifacts are ciphertext everywhere.

Terraform relies on backend encryption, access control, and keeping secrets out of state with ephemeral values, write-only arguments and external secret managers. Those are good practices and narrow the gap, but they are not transparent encryption of the whole artifact. For regulated teams that treat state as a secret store, this is a common reason to move.

IVThe registry and the ecosystem

Providers and modules are where Terraform's network effect lives, and the registry is where the projects split most visibly.

Alongside the relicense, HashiCorp changed the terms of its registry, so OpenTofu runs its own community registry. Most providers, the AWS provider included, are independent open-source projects published to both, so declaring hashicorp/aws resolves the same provider either way. You feel the split in registry features and in the long tail of older community modules.

Terraform's deeper integration story is HCP Terraform: private registry, no-code modules, run tasks, drift detection and Sentinel policy. OpenTofu leans on third-party platforms (Spacelift, env0, Scalr, Terrateam, Atlantis and others), most of which support both tools. For many teams that platform is where they work day to day, which narrows the practical difference.

• Providers (including AWS): Effectively shared; the AWS provider is the same on either tool.
• Public modules: Mostly on both; niche or old modules depend on community mirroring.
• Private registry: First-party in HCP Terraform; for OpenTofu, provided by the platform layer or an OCI registry (OpenTofu 1.10+).
• Policy as code: Sentinel and HCP policy on Terraform; OPA, Conftest, Checkov or platform policy on OpenTofu.

VMomentum and governance in 2026

A fork lives or dies on momentum and governance. OpenTofu has cleared the bar that kills most forks.

OpenTofu has shipped steadily under the Linux Foundation: 1.7 (state encryption, provider-defined functions, removed blocks), 1.8 (early evaluation of variables in backend and module sources), 1.9 (provider for_each and the -exclude flag, release notes), 1.10 (OCI registry support, native S3 state locking and OpenTelemetry tracing, release notes), and later releases. No single company controls it and the roadmap is public.

Terraform keeps moving too, with test framework work, stacks, and ephemeral and write-only handling for secrets. IBM completed its acquisition of HashiCorp on 27 February 2025 (IBM). That reassures buyers who want one enterprise vendor and worries those who distrust single-vendor control.

The 2026 picture is coexistence. Terraform has the larger installed base and the enterprise relationships. OpenTofu has the teams that need OSI-approved licensing, cost-sensitive teams, and much of the open-source platform community. Many organizations run both.

VIMigrating from Terraform to OpenTofu

Because OpenTofu reads the same configuration, state and providers, the base case is a binary swap. The work is in the tooling around it.

The standard path for one state, per the OpenTofu migration guide: install tofu, run tofu init against the existing backend, run tofu plan, and confirm a no-op plan. Then use tofu apply from then on. There is no state conversion. For a small, isolated configuration this is often done in an hour or two.

OpenTofu understands the terraform block and the .terraform.lock.hcl file, and it can read .tofu files, which let a configuration use OpenTofu-only syntax without breaking Terraform.

The real effort is wherever your delivery system names the binary: CI pipelines, pre-commit hooks, tflint or Checkov wiring, Atlantis or Terrateam configuration, wrapper scripts. It is find-and-replace plus a test run, multiplied by the number of pipelines.

The hard migrations are tied to HCP Terraform features (Sentinel, no-code modules, run tasks, the private registry, hosted runs). Those have no one-to-one OpenTofu equivalent, so you also move to a third-party or self-hosted platform. And going back from OpenTofu to Terraform after you adopt OpenTofu-only features (state encryption, .tofu syntax) is not guaranteed clean, so pick a direction on purpose.

VIIWhich to choose, by situation

There is no universal winner. Two questions decide it for most organizations: does an OSI-approved license matter to you, and how much do you use HCP Terraform?

Many teams choose per project: new services on OpenTofu, existing estates on Terraform until there is a reason to move. Because the configuration is shared and most platforms support both, running both is low friction.

VIIIThe AWS angle: both work, and the provider is shared

Picking OpenTofu costs you nothing on AWS. The AWS provider is the same open-source provider on both tools.

The hashicorp/aws provider is published to both registries and is identical either way, so every AWS resource and data source behaves the same. Authentication, assume-role, IAM Identity Center and the S3 backend work the same. Both tools now support native S3 state locking alongside the older DynamoDB lock table, and both work with SSE-KMS on the bucket. OpenTofu can add client-side encryption keyed to AWS KMS in your own account.

AWS does not care which binary runs your HCL. If the IaC work is part of moving workloads onto AWS (MAP) or launching new work on AWS (IW), a vetted AWS partner can file funding for that work when it qualifies and AWS approves: typically $50K to $150K for startups. Depends on the workload; AWS approves. Switching tools on its own is ordinary engineering work.