OpenTofu is a community-driven, MPL-licensed fork of Terraform created in 2023 after HashiCorp relicensed Terraform under the Business Source License. In 2026, the two tools share most of their core functionality and configuration language, but diverge on licensing, governance, and a growing list of features. Picking between them in 2026 is mostly a question of license posture, vendor relationships, and which features each side has shipped that you actually need.

This guide covers how the two tools compare today, the reasoning teams use to pick one or the other, the migration path from Terraform to OpenTofu (and back, in principle), and a broader question worth asking: whether the right answer for new backends in 2026 is either tool, or something further up the stack.

How We Got Here

In August 2023, HashiCorp changed Terraform's license from the Mozilla Public License (MPL) 2.0 to the Business Source License (BSL) v1.1. The new license restricts use of Terraform "in a competitive way" against HashiCorp's own products, with BSL converting to MPL only after four years per release.

The change was controversial. A coalition of vendors and community members forked Terraform 1.5 (the last MPL version) and announced what became OpenTofu, hosted under the Linux Foundation. Endorsing companies at fork time included Spacelift, env0, Gruntwork, Harness, Scalr, and Cloud Posse, among others.

In 2025, IBM acquired HashiCorp. The acquisition didn't change the BSL license but did raise fresh questions about long-term stewardship, roadmap independence, and the relationship between Terraform and the rest of the IBM cloud portfolio. For more context on that, see Terraform in 2026: IBM, OpenTofu, and the Future of IaC.

OpenTofu has been shipping steady releases since the fork, and in 2026 is a credible drop-in replacement for most Terraform workflows, with several feature additions that haven't landed in upstream Terraform.

Licensing: MPL vs BSL

This is the core difference and the one most teams care about first.

	OpenTofu	Terraform
License	Mozilla Public License (MPL) 2.0	Business Source License (BSL) v1.1
Stewardship	Linux Foundation	HashiCorp (now IBM)
Use restrictions	None beyond MPL terms	Cannot be used in products that compete with HashiCorp
Commercial offerings can build on it	Yes	Restricted by BSL

The BSL doesn't affect most end-user teams who simply run terraform apply against their own infrastructure. Where it matters is for vendors building products that wrap or extend Terraform: managed CI/CD platforms, drift-detection tools, policy-as-code systems, and similar. Several of these vendors switched their default to OpenTofu after the relicense.

For an end user, the practical question is whether your organization has a policy preference for permissive licenses (MPL is permissive; BSL is source-available but not open-source by OSI definition), and whether any of the tools in your IaC pipeline have switched to OpenTofu. If your CI vendor only supports OpenTofu, the decision is made.

Feature Parity

In 2026, OpenTofu and Terraform share:

• The same configuration language (HCL)
• The same core resource graph and apply lifecycle
• The same state file format
• A near-identical CLI surface
• A largely overlapping provider ecosystem

The CLI commands match (init, plan, apply, destroy, state, etc.), and most existing modules work in both without changes. A team that's been on Terraform 1.5 and switches to OpenTofu typically notices little day-to-day difference.

Where they diverge is in features each side has shipped since the fork.

OpenTofu-specific features that have landed since the fork:

• State encryption. Native, configurable encryption of state files, including remote state. Solves a long-standing security ask without requiring an external KMS workflow.
• Early evaluation of variables and locals. Allows backend configuration to be parameterized in ways that vanilla Terraform has historically not.
• removed blocks. Declarative way to remove resources from state without using terraform state rm.
• Init enhancements. Including provider mirroring and configurable retries.
• A faster release cadence with feature requests landing on the order of months rather than quarters.

Terraform-specific features and direction:

• Stacks. A higher-level abstraction for managing groups of related Terraform configurations across environments. Not present in OpenTofu.
• Tighter integration with HCP Terraform (formerly Terraform Cloud), the HashiCorp/IBM-managed runner and state backend.
• Sentinel policy-as-code as the first-class governance integration. (OpenTofu users typically pair with OPA/Conftest or third-party policy engines.)
• Partnerships and certifications through HashiCorp's vendor relationships, particularly relevant in regulated industries.

Provider Ecosystem

The provider ecosystem largely works for both. Most providers are MPL-licensed and run unchanged on either tool. A handful of providers have published OpenTofu-specific or Terraform-specific releases, but the majority don't.

OpenTofu maintains its own provider registry as well as supporting the existing Terraform Registry. In practice, teams pick one registry as the source for init and don't think about it after that.

If you're building or maintaining a custom provider, both tools support the same protocol, and one binary typically serves both.

State Management and Backends

State file format is shared. State stored in S3, GCS, Azure Blob, or any of the other supported backends works for both tools.

The remote state operations differ slightly:

• OpenTofu added native state encryption that can be applied to local and remote state with simple configuration.
• Terraform state encryption is typically handled via the backend (e.g., S3 server-side encryption) rather than at the state file level.

For teams using HCP Terraform as the state and run backend, OpenTofu does not have a fully equivalent first-party offering. The closest equivalents are Spacelift, env0, Scalr, and similar third-party platforms that support both tools.

Migration: Terraform to OpenTofu

The migration is straightforward for most setups. The general path:

1. Confirm provider compatibility. Most providers work identically. Check the few you depend on most.
2. Install OpenTofu alongside Terraform on developer machines and CI runners.
3. Run tofu init against the existing state. No state migration is needed; the file formats match.
4. Run tofu plan. Confirm the plan is clean (no unexpected diffs).
5. Replace terraform with tofu in CI/CD, runbooks, and documentation.
6. Remove Terraform from CI runners once you've validated the switch.

For teams using HashiCorp-specific features (Stacks, Sentinel, HCP Terraform's run pipelines), the migration is more involved. Stacks-using teams generally stay on Terraform; teams using Sentinel typically replace it with OPA when migrating.

The reverse direction (OpenTofu to Terraform) is also possible but less common and may require unwinding any OpenTofu-specific features (state encryption configuration, removed blocks, etc.) before the switch.

Decision Guide

Pick OpenTofu if:

• You want a permissively licensed (MPL) IaC tool with an OSI-approved license
• Your CI/CD vendor or policy platform has standardized on OpenTofu
• The OpenTofu-specific features (state encryption, faster release cadence) matter to you
• You're cautious about long-term stewardship under IBM and prefer Linux Foundation governance

Stay on Terraform if:

• You depend on Stacks, Sentinel, or other HashiCorp/IBM-specific features
• Your team is deeply integrated with HCP Terraform and the migration cost is high
• You have vendor or compliance reasons to stay on the IBM-supported path
• You're not bothered by the BSL license terms in your context

Reconsider the whole approach if:

• You're starting a new backend project rather than maintaining an existing one
• Your team is feeling the friction between application code and infrastructure config
• AI tooling is generating most of your code, and the IaC layer is the bottleneck

The third case is worth its own section.

What This Debate Misses

OpenTofu vs Terraform is a real debate, and the answer is meaningful for teams maintaining existing IaC. But for new backends in 2026, the more interesting question is whether the IaC model itself is the right primitive.

Both OpenTofu and Terraform share the same fundamental shape: infrastructure is described in a separate language (HCL), in a separate codebase, against a separate state file, and applied by a separate tool. The application code that depends on that infrastructure has no awareness of it. The infrastructure description has no awareness of how the application uses it.

This split made sense when "infrastructure" meant networks and VMs configured by ops teams, and "application code" meant a binary deployed onto them. In 2026, when most "infrastructure" is application-level concerns (databases, queues, secrets, scheduled jobs, object storage, auth) that the application code reaches for directly, the split feels increasingly arbitrary. It also creates a friction point that AI coding tools struggle with: they can generate application code easily but can't reliably generate matching IaC because the two contexts are isolated.

The alternative emerging in 2026 is Infrastructure from Code (IFC): declare what your application needs (database, Pub/Sub topic, secret, cron) directly in the application's source code, and let tooling provision the right cloud services from those declarations. The configuration sprawl moves from a separate IaC repository into the application's own code, and the application becomes the single source of truth.

Encore is the open-source IFC framework for TypeScript and Go, with over 11,000 GitHub stars and production users including Groupon.

import { api } from "encore.dev/api";
import { SQLDatabase } from "encore.dev/storage/sqldb";
import { Topic, Subscription } from "encore.dev/pubsub";

// Provisions managed Postgres (RDS on AWS, Cloud SQL on GCP, Docker locally).
const db = new SQLDatabase("orders", { migrations: "./migrations" });

// Provisions Pub/Sub (SNS+SQS on AWS, Pub/Sub on GCP, NSQ locally).
export const orderPlaced = new Topic<{ orderID: string }>("order-placed", {
  deliveryGuarantee: "at-least-once",
});

export const create = api(
  { method: "POST", path: "/orders", expose: true },
  async (req: { customerID: string }) => {
    const row = await db.queryRow`
      INSERT INTO orders (customer_id) VALUES (${req.customerID})
      RETURNING id
    `;
    await orderPlaced.publish({ orderID: row.id });
    return row;
  },
);

The same code runs locally with encore run, in preview environments per pull request, and in production AWS or GCP. There is no separate Terraform or OpenTofu module. There is no separate state file. The provisioning is derived from the code, and the code is the source of truth for both behavior and infrastructure.

Encore Cloud provisions the underlying AWS or GCP services in your own cloud account; there are no runtime dependencies on Encore in production, and the framework is open-source with an encore eject path for teams that want to leave.

This isn't a wholesale replacement for Terraform or OpenTofu. Teams running large fleets of VMs, configuring networking and IAM at scale, or operating regulated infrastructure that doesn't fit the application-layer model will continue to use IaC. What IFC replaces is the configuration sprawl that grows around any non-trivial backend, and it's especially compelling for new projects where the choice isn't constrained by an existing IaC investment.

Conclusion

For teams maintaining existing Terraform setups, OpenTofu is the credible MPL-licensed alternative in 2026, and migrating to it is straightforward unless you depend on HashiCorp-specific features. The choice between them is a judgment call about license posture, vendor ecosystem, and which side has shipped features you actually use.

For new backends, the more useful question is whether you need an IaC tool at all, or whether an IFC framework that treats application code as the source of truth would deliver the result faster, with less configuration sprawl, and with better fit for AI-assisted workflows. Both options are real, and the answer depends on the shape of what you're building.

Related Resources

• Terraform in 2026: IBM, OpenTofu, and the Future of IaC
• Terraform alternatives
• Encore vs Terraform, CDK, Pulumi, and SST
• How to deploy to AWS without Terraform
• Terraform Cloud explained
• Pulumi vs Terraform