OpenTofu vs Terraform in 2026: Differences, Licensing, and How to Choose

OpenTofu and Terraform are two infrastructure as code (IaC) engines that read the same HCL configuration language, use the same providers, and keep track of what they built in a state file. The big difference is the license. Terraform has shipped under the Business Source License 1.1 (BSL) since version 1.6, and HashiCorp is now owned by IBM. OpenTofu is the open source fork of Terraform 1.5, released under the Mozilla Public License 2.0 (MPL 2.0) and run by the Linux Foundation as a CNCF project.

For most teams the choice comes down to three questions. Do you depend on HCP Terraform or Terraform Enterprise features such as Stacks? Does your legal team, or your business model, need an open source license? Do you want OpenTofu-only features such as client-side state encryption? If you answered yes to the first, Terraform is the easier fit. If you answered yes to the second or third, OpenTofu is. Many teams have answers on both sides, which is why the decision works best one project at a time.

OpenTofu vs Terraform at a Glance

Licensing: What BSL 1.1 Allows and What It Restricts

On August 10, 2023, HashiCorp announced that all future releases of its products would move from MPL 2.0 to the Business Source License. The Terraform repository shows the change exactly: the v1.5.7 tag is MPL 2.0, and v1.6.0 onward carries the BSL text.

The BSL is a source-available license. You can read, copy, modify, and run the code, including in production. The restriction lives in the license's Additional Use Grant: your use may not include offering Terraform to third parties "on a hosted or embedded basis in order to compete with IBM Corp.'s paid version(s)". The license defines a competitive offering as a paid product that significantly overlaps with those paid versions, and it states that free products are not competitive. Each release converts to MPL 2.0 four years after it is published.

In practice, an engineering team running Terraform against its own cloud accounts is inside the grant. The license matters most to companies that sell a platform, managed service, or product that runs Terraform for their customers, and to organizations whose policy only allows licenses approved by the Open Source Initiative (OSI), which MPL 2.0 is and BSL is not.

Governance: IBM and HashiCorp vs the Linux Foundation

IBM announced on February 27, 2025 that it had completed its acquisition of HashiCorp. The current Terraform license names International Business Machines Corporation as the licensor. Terraform, its docs, and HCP Terraform still carry the HashiCorp name, and one company decides both the roadmap and the license terms.

OpenTofu was started in 2023 by a group of IaC companies including Gruntwork and Spacelift, then handed to the Linux Foundation so no single vendor could change its license. A core team and technical lead pick features and fixes, a steering committee handles larger decisions, and major changes go through public RFCs (requests for comments). The Cloud Native Computing Foundation (CNCF), the Linux Foundation body behind Kubernetes, accepted OpenTofu at Sandbox level, its entry stage for new projects, on April 23, 2025.

Feature Differences Since the Fork

The two projects have shipped features on separate schedules since the fork. Some exist in only one engine; others exist in both.

OpenTofu-only features, with the release that added them:

• State encryption (1.7): encrypts state and plan files with AES-GCM before they are written, with keys from a passphrase, AWS KMS, GCP KMS, OpenBao, or an external program. A state file often contains database passwords and access keys, so anyone who reads the backend bucket can read them. With encryption on, they cannot.

• Early variable and locals evaluation (1.8): variables and locals can be used in backend blocks, module source and version, and encryption settings, as long as they do not depend on resources or module outputs. Terraform caught up partly: it accepts variables in module source and version from 1.15, but backend blocks still take literal values only.

• Provider for_each (1.9): one provider block can create a configuration per region or account, instead of a copied block for each. The same release added -exclude, which plans or applies everything except the resources you name.

• Later additions: OCI registry support for distributing providers and modules (1.10), an enabled lifecycle argument for zero-or-one resources (1.11), and a dynamic prevent_destroy that can read variables (1.12).

Provider for_each, from the OpenTofu 1.9 release notes:

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

Terraform-only features:

• Stacks: a configuration layer in HCP Terraform that splits infrastructure into components and deploys them across many environments. Stacks run through HCP Terraform.

• Actions and terraform query (1.14): actions run provider-defined operations outside the normal resource lifecycle, such as invoking a Lambda function or invalidating a CloudFront cache. terraform query lists existing cloud resources and can generate import configuration for them.

• Terraform Policy (1.17): generally available in 1.17.0 through a -policies flag on plan, apply, and query. The same release allows variables and locals in provider requirements.

Shared features, sometimes with different release versions:

• moved and removed blocks: both engines support moved for renaming or relocating resources without destroying them, and removed for dropping a resource from state while leaving it running. Terraform added removed in 1.7.0, and OpenTofu shipped it in its own 1.7.

• Ephemeral values: values that live only in memory during a run and never reach state or plan files, useful for secrets. Terraform added ephemeral resources in 1.10 and write-only attributes in 1.11. OpenTofu added both in 1.11.

• Testing: both have a built-in test command (terraform test and tofu test) that runs plans and applies against a configuration and checks the results.

• S3 native state locking: both can lock state in Amazon S3 without a DynamoDB table, Terraform from 1.11 and OpenTofu from 1.10.

Providers and the Registry

Providers are the plugins that talk to cloud and SaaS APIs, such as hashicorp/aws or cloudflare/cloudflare. OpenTofu does not build its own; it runs the same provider binaries Terraform does. The difference is where it downloads them from. When OpenTofu sees source = "hashicorp/aws", it treats that as shorthand for registry.opentofu.org/hashicorp/aws, while Terraform resolves it against registry.terraform.io. Your required_providers blocks usually work unchanged. If you run a private registry or a provider mirror, check that it serves both engines.

Modules are a different matter. A module that uses an OpenTofu-only block such as encryption, or a Terraform-only block such as action, will only work with that engine. If you publish modules for both, keep them to the shared language and set version constraints.

HCP Terraform and Terraform Enterprise vs OpenTofu Platforms

HCP Terraform (formerly Terraform Cloud) is HashiCorp's hosted service for remote runs and state; Terraform Enterprise is the self-hosted version. Both are built around the Terraform engine, and Stacks are tied to them. If your team relies on those workflows every day, switching engines means switching platforms too, which is a bigger project than changing a binary.

OpenTofu has no vendor-hosted service. Teams run it in their own CI pipelines or on third-party IaC platforms, including several from the companies that started the fork. The OpenTofu FAQ says it works with existing state files up to those created by Terraform 1.5.x, and it publishes version-specific migration guides for later Terraform versions.

Checking and Switching Engines Locally

OpenTofu keeps Terraform's subcommands, so the workflow looks the same with a different binary name:

terraform version            # current engine and provider versions
tofu version                 # confirm OpenTofu is installed
tofu init                    # download providers from registry.opentofu.org
tofu plan -out=tfplan        # compare with your last Terraform plan
tofu plan -exclude=aws_instance.legacy   # OpenTofu 1.9+: plan everything except one resource

Back up state before the first tofu apply, and expect the first plan to match your last Terraform plan. Any unexpected create, update, or delete is a compatibility issue to resolve before applying. The full sequence, including rollback, is in our Terraform to OpenTofu migration guide.

Which Should You Choose?

The engines are close enough that the review process around them usually matters more than the binary.

Running Terraform and OpenTofu Side by Side in ops0

Every ops0 project picks its own engine: Terraform (ops0 runs 1.5.7, the last MPL release), OpenTofu, Oxid (ops0's open source engine with PostgreSQL state you can query with SQL), or AWS CloudFormation. That lets an engineer move one low-risk project to OpenTofu while the rest of the estate stays on Terraform, compare results, and expand when the team is ready. See IaC in ops0.

The controls stay the same whatever the engine. Every deploy goes through a plan with attribute-level diffs and a blast-radius summary, policy checks for CIS, SOC 2, HIPAA, ISO 27001, ISO 27002, and GDPR, a budget check, and an approval gate that is on by default for deploy and destroy. With separation of duties turned on, the person who started a run cannot approve it. Teams replacing HCP Terraform runs can compare the two at ops0 vs Terraform Cloud.