Terraform vs OpenTofu in 2026: Which Should You Choose?

Terraform and OpenTofu use the same HCL syntax and largely the same provider ecosystem, but they are no longer the same tool. As of November 2026, Terraform is on v1.17.1 under HashiCorp's Business Source License, while OpenTofu is on v1.13.2 under the open-source MPL 2.0 license and has shipped features — native state encryption, provider for_each, early variable evaluation — that Terraform still doesn't have. Here's what actually differs, with the numbers pulled straight from each project's release notes, license files, and pricing pages.

Quick answer: which one should you use

If you're starting fresh and want to stay fully open source with zero licensing risk, OpenTofu is the safer long-term bet — it's a Linux Foundation project under the CNCF, licensed MPL 2.0, and ships encryption and planning features Terraform lacks. If you're already standardized on HashiCorp's ecosystem, need HCP Terraform's managed run environment, Sentinel policy-as-code, or vendor support contracts, Terraform remains the more "enterprise-safe" default, especially for regulated organizations that want a single throat to choke. For most new greenfield projects without an existing HashiCorp relationship, OpenTofu's combination of compatibility and lower licensing risk is winning converts.

What Terraform and OpenTofu actually are

Terraform is HashiCorp's infrastructure-as-code tool for provisioning cloud and on-prem resources through declarative HCL configuration. OpenTofu is a fork of Terraform created after HashiCorp moved Terraform from the open-source MPL 2.0 license to the Business Source License (BSL) in 2023. OpenTofu describes itself as a "drop-in replacement for Terraform," preserving existing HCL configurations, provider compatibility, and CLI workflows. If you're new to the underlying concept, see our explainer on what Terraform and infrastructure as code actually mean before diving into the comparison below.

Licensing: BSL vs MPL 2.0

This is the root of the fork and still the biggest practical difference. Terraform's license file on GitHub spells out the terms directly: the Business Source License's "Change Date" is "four years from the date the Licensed Work is published," and the Change License it converts to is MPL 2.0. In practice, that means every Terraform release you use today stays under BSL restrictions — which bar offering a competing managed service built on Terraform — for four years from that specific release's publish date, not from some fixed calendar date.

OpenTofu, by contrast, is MPL 2.0 licensed in full, permanently, with no change date and no competitive-use restriction. The Cloud Native Computing Foundation even granted OpenTofu a formal exception to its usual Apache 2.0 licensing requirement so the project could keep MPL 2.0 and still join the foundation — a sign of how central the licensing question is to OpenTofu's identity.

Release cadence and what's new in each

Both projects ship frequently. Terraform's October 2026 release notes show v1.17.0 (Oct 21) with v1.17.1 as a same-week patch (Oct 28) that preserves the original file if a terraform fmt write fails and fixes module policy evaluation during destroy plans. OpenTofu's equivalent release history shows v1.13.0 (Sep 30) followed by patches v1.13.1 (Oct 1) and v1.13.2 (Oct 21), plus continued 1.12.x security patches as late as Oct 29.

Terraform v1.17.0's headline items are "Terraform Policy" graduating to general availability (the -policies flag no longer needs an experimental build), a new -minimal-refresh planning option that only refreshes resources with proposed changes, and support for variables and locals inside provider requirement blocks. OpenTofu v1.13.0's headline items are official Windows-on-ARM64 builds, new assume... functions that hint the planner to reduce "unknown" values, experimental linting via a -lint flag, and Symbol Libraries — alongside dropping WinRM provisioner support and requiring macOS 13+.

Features OpenTofu has that Terraform doesn't

Because OpenTofu forked from an earlier Terraform codebase and has since developed independently, a handful of features exist only on one side. OpenTofu's own documentation lists several it shipped before Terraform did, or that Terraform still hasn't matched:

On encryption specifically, the gap is worth underlining: Terraform's own state-management documentation states plainly that "Terraform stores your state in a plaintext file," and that encryption at rest for remote backends is opt-in — the S3 backend only encrypts when you set its encrypt option, and GCS relies on customer-supplied or customer-managed keys you configure yourself. Holding your own encryption keys for HCP Terraform-managed state is listed as an HCP Terraform-only capability, not something available in plain open-source Terraform. OpenTofu's state encryption, by comparison, is a built-in language feature available to anyone running the free CLI, with AES-GCM as its primary encryption method.

Ecosystem, providers, and compatibility

Compatibility is the whole point of the fork: OpenTofu is designed to read the same .tf files, use the same providers, and interoperate with the same state format as Terraform, so most existing Terraform codebases run on OpenTofu with little or no modification. OpenTofu's own site reports its registry mirroring more than 3,900 providers and 23,600+ modules, with 180+ community contributors to the core project. Terraform's registry remains the larger, HashiCorp-run original, and most providers (AWS, Azure, Google Cloud, Kubernetes, and so on) are published once and consumed by both tools, since OpenTofu's registry can pull from the same provider sources.

The practical caveat both projects flag: once you adopt an OpenTofu-only feature — provider for_each, the -exclude flag, or state encryption — your configuration is no longer guaranteed to run unmodified on Terraform. Teams who want to keep the option of switching back should stick to the common feature subset.

Governance: who's actually in charge

Terraform is developed and controlled by HashiCorp, now an IBM company, which sets the roadmap, licensing terms, and release schedule unilaterally. OpenTofu is stewarded by the Linux Foundation as "a Series of LF Projects, LLC," and governed through the CNCF's technical oversight process; it was formally accepted into the CNCF at the Sandbox maturity level on April 23, 2025, after the CNCF's Technical Oversight Committee approved it and the Governing Board separately approved an exception letting the project keep its MPL 2.0 license rather than switch to CNCF's default Apache 2.0 requirement. That governance distinction matters for enterprises doing vendor-risk assessments: OpenTofu's roadmap is decided by community maintainers and a foundation, not a single commercial vendor with its own product incentives.

Pricing: free CLI either way, but paid tiers differ sharply

Both CLIs are free to download and run locally — the difference is what you pay for once you want a managed collaboration layer. HashiCorp's current HCP Terraform pricing lists four tiers: Essentials starting around $0.10 per resource per month (with a one-time $500 trial credit, not an ongoing free plan), Standard from about $0.47 per resource per month, Premium from about $0.99 per resource per month, and custom-priced Enterprise. Essentials caps out at 10 test-integrated modules and lacks module deprecation, team notifications, and no-code provisioning, all of which open up at Standard and above.

OpenTofu itself has no commercial product or pricing tiers to sell — it's funded by Linux Foundation member companies and contributors, so the CLI, registry, and all documented features (including state encryption) are free regardless of scale. Third-party vendors sell hosted "OpenTofu-compatible" run environments, but that's a separate commercial layer outside the core project.

Security patch history: what shipped recently

Both tools had active security patch cycles through October 2026, which is a reasonable proxy for how seriously each project treats hardening. OpenTofu's 1.12.x and 1.13.x lines carried several distinct fixes in that window: v1.12.6 (Aug 19) patched credential forwarding on OCI redirects and a high CPU/memory issue from crafted relative URLs; v1.12.7 (Oct 1) fixed a deadlock that could be triggered when remote-exec or file provisioners connected to a malicious SSH server; and v1.12.8/v1.13.1 (Oct 14–Oct 1) both addressed excess CPU use during tofu init over HTTP/2, plus filtering of compromised intermediate certificates in v1.12.9/v1.13.2. Terraform's public release notes for the same period lean more toward crash and panic fixes — a schema-testing panic in v1.16.7, a tainted-instance crash in v1.16.5, and a nil resource-identity issue — without the same volume of named security advisories visible in the GitHub release notes themselves. That doesn't necessarily mean one project has more vulnerabilities than the other; it may simply reflect how each project writes up its release notes. If security posture is a hard requirement for your organization, pull the actual CVE and GHSA advisories from each project's GitHub Security tab rather than relying on changelog prose alone.

Decision checklist: picking by use case

Migrating between them

Because OpenTofu was forked from Terraform's codebase before the license change, the migration path is mostly mechanical: swap the binary, point it at your existing state file (the state format is compatible), and run a plan to confirm no diff. The friction shows up only if you've since adopted Terraform-only features (like the new Terraform Policy GA in v1.17.0) or OpenTofu-only features (like provider for_each), either of which breaks round-trip compatibility. Before migrating either direction, pin your provider versions and run a full plan against a non-production state copy first — neither project guarantees a silent, zero-diff switch once your configuration has drifted from the common feature set.

What's next

Watch two things over the coming months: whether HashiCorp narrows the feature gap identified above (state encryption is the most-requested missing piece in Terraform's own community forums), and whether OpenTofu's CNCF status advances beyond Sandbox toward Incubation, which would signal broader enterprise governance confidence. Also worth tracking is each project's release cadence — both are shipping monthly-or-faster point releases, so whichever tool you pick, budget time to review changelogs before every upgrade rather than batching several versions at once.

If your Terraform or OpenTofu runs are triggered from CI, the choice of pipeline engine matters just as much as the IaC tool itself — see our comparison of GitHub Actions and Jenkins for running infrastructure pipelines if you haven't settled that yet. And if you're still getting oriented on what "infrastructure as code" means before picking a tool at all, the plain-English Terraform and IaC explainer is the right starting point.

Written byFelix Moreau

Felix Moreau writes Pandromeda's software coverage and how-to guides. He covers Windows, macOS and Linux updates, the apps people rely on, emulators and developer tools, and turns official documentation into clear, numbered steps that work on the current version.

More from Felix MoreauAll Software & Guides coverage