Terraform vs OpenTofu in 2026: License, Features and Whether to Switch

A few years ago, this comparison could not have existed. Terraform was the default infrastructure as code tool. It was open source, and the only real question was which cloud you pointed it at.

Then, in August 2023, HashiCorp changed Terraform’s license. The fork that followed, OpenTofu, turned a licensing story into a genuine tooling decision that teams still face today.

This article compares the two tools on the things that actually separate them. That means the license story, the features each side has shipped since the split, and the real cost of moving from one to the other.

If you are comparing more than these two, start with our roundup of the best infrastructure as code tools and then come back here for the head-to-head.

The Platform Around the Tool Decides This More Than the CLI Does

For plain plan and apply work against your own cloud accounts, choose either tool with confidence. The same configuration usually runs on both. The commands feel identical, and your daily workflow barely changes.

The decision gets clearer once you look at what sits around the command line. Teams invested in HCP Terraform, Stacks or Sentinel should stay on Terraform, because OpenTofu offers no equivalent for any of them.

Teams that want an MPL license, open governance or client-side state encryption should choose OpenTofu. Those are real advantages, and Terraform does not match the encryption feature at any price.

Everything below explains how I reach that verdict. It starts with the license change that split one project into two tools with different owners, different rules and increasingly different features.

How One License Change Created Two Tools

Terraform shipped under the Mozilla Public License 2.0 for most of its life. On 10 August 2023, HashiCorp moved it to the Business Source License 1.1, and Terraform 1.5.7 became the last MPL release.

The BSL is source-available, not open source in the OSI sense. Anyone can read the code and use it, but the license restricts one specific thing that it calls Competing Use.

Competing Use means offering a commercial product or service that lets third parties manage their infrastructure with Terraform. In plain terms, you cannot build a rival hosted platform on top of Terraform’s code.

Ordinary use is not restricted at all. A team running its own infrastructure in production breaks no rule, and HashiCorp’s own licensing FAQ states plainly that nothing changes for such teams.

That distinction is why the panic of 2023 settled down. Most users were never the target of the change, even though the license itself genuinely stopped being open source.

Each BSL release also carries an expiry date. Four years after a release is published, that release converts automatically to MPL 2.0 under the license terms.

OpenTofu began as a fork of the last MPL code. The project was announced in September 2023, shipped its first stable release, version 1.6.0, on 10 January 2024, and has stayed on MPL 2.0 ever since.

Governance is the other half of the split. OpenTofu is stewarded by the Linux Foundation, and it has sat in the CNCF Sandbox since 23 April 2025, so no single vendor controls its roadmap.

Terraform’s ownership changed in the opposite direction. IBM completed its acquisition of HashiCorp on 27 February 2025, and the LICENSE file in the Terraform repository now names IBM as the licensor.

The Feature Gap, Side by Side

Both tools still share the same configuration language and the same provider ecosystem. What has changed since 2023 is a short list of features that now exist on only one side of the fork.

Read the version row with care. Terraform’s latest stable release is 1.17.2, published on 11 November 2026, while OpenTofu’s latest is 1.13.9, published on 5 November 2026.

OpenTofu’s 1.13 series remains security-supported until 1 August 2027. That kind of published support window is worth checking before you standardise on any release line.

Matching numbers do not mean matching code. OpenTofu 1.11 and Terraform 1.11 are different programs with different features, so compare capabilities and changelogs rather than version strings.

What Has Not Changed Since the Fork

It is easy to overstate the split. Both tools read the same configuration language, and both share the same core commands of init, plan and apply that Terraform users have run for a decade.

State works the same way in both tools as well. Each one tracks your real infrastructure in a state file, compares it against your configuration, and proposes the difference as a plan before changing anything.

That sameness is deliberate, not accidental. OpenTofu forked Terraform’s code and kept the workflow intact, and it competes on license, governance and selected features rather than on a new way of working.

A Terraform engineer can read an OpenTofu configuration without retraining. The skills transfer completely, which is why this decision stays a platform and licensing call instead of a staffing problem.

Where They Have Drifted Apart

OpenTofu moved first on state security. Since version 1.7 it can encrypt state and plan files on the client side using AES-GCM, before anything leaves your machine.

Terraform has no equivalent feature. Its state protection happens at the backend instead, for example inside an S3 bucket encrypted with KMS, which means the state still exists in readable form wherever the backend decrypts it.

OpenTofu 1.9 added provider for_each, which instantiates one provider block for each item in a collection. Multi-region setups that once needed copied provider blocks and long alias lists now come from a single block.

Two smaller OpenTofu additions matter in daily work. The -exclude flag lets you plan and apply everything except named resources, and .tofu files let OpenTofu-specific syntax live alongside ordinary configuration files.

Terraform’s recent additions lean toward orchestration instead. Stacks, a way to manage groups of configurations across environments, is an HCP Terraform feature with CLI support that arrived in Terraform 1.13.

Terraform 1.14, released in November 2025, added terraform query and the actions block. Both aim at day-two operations, the work that happens after the first apply rather than during it.

One widely repeated difference is not a difference at all. Provider-defined functions exist in both tools, arriving in OpenTofu 1.7 and Terraform 1.8, so they should never sway your decision either way.

Policies split along platform lines. Terraform users get Sentinel inside HCP Terraform, while OpenTofu users typically reach for Open Policy Agent to build the same kind of guardrails.

The pattern underneath all of this is worth naming. OpenTofu is investing in the standalone CLI and in keeping state safer, while Terraform’s headline features increasingly attach to HashiCorp’s hosted platform.

Moving From Terraform to OpenTofu Without Breaking Production

The mechanics of switching are friendlier than most teams expect. OpenTofu reads Terraform-format state natively. It speaks the same provider protocol, and it pulls providers from the same public registry.

That compatibility goes a long way. Providers built for Terraform 1.5 and later work in OpenTofu without modification, so your provider pins and versions usually survive the move untouched.

Configurations running on Terraform 1.5.x usually need no code changes at all. OpenTofu publishes migration guides for Terraform release lines up to 1.9, and each guide lists a short set of known differences.

Those differences are specific rather than scary. They cover certain S3 backend options, a few removed blocks, test overrides and a handful of functions that behave differently on the other side.

Be honest about the hard edge, though. If you run a current Terraform release from the 1.15 or 1.16 era, the documented migration path runs out, because the two tools have kept drifting apart since then.

Terraform features such as the actions block and terraform query have no OpenTofu equivalent. A configuration that leans on them cannot move as it stands, and it will need rework before any switch.

Whatever your starting version, test the move in the same careful way:

1. Back up your state file first, and keep the backup somewhere outside the working directory.
2. Copy the configuration into a scratch directory or a separate test branch.
3. Run tofu init in the copy, so OpenTofu installs the providers it needs.
4. Run tofu plan, then compare the result line by line with your existing terraform plan output.
5. Only when both plans agree should you run tofu apply, and start with a low-risk environment.

OpenTofu documents the move as reversible, provided you keep backups and avoid OpenTofu-only features while you migrate. There is one exception to that promise, and it deserves emphasis.

State that OpenTofu has encrypted cannot be read by Terraform. Turning on client-side encryption is therefore a one-way step, even when everything else about the migration stays reversible.

Two habits make the trial safer. Pin the exact OpenTofu version you test with, so a mid-trial release cannot change behaviour under you, and keep the Terraform binary installed until the new setup has survived a few real change cycles.

If the plans disagree at step four, stop there. A mismatched plan is the tool telling you a difference matters for your configuration, and it is far cheaper to investigate in a copy than in production.

Who Should Switch, and Who Should Stay Put

The right answer depends on the team wrapped around the tool. Platform teams making this call for a whole organisation should also read our comparison of platform engineering vs DevOps, because the ownership model shapes the tooling choice.

Choose OpenTofu if

• You want your core tooling under an OSI-approved license, MPL 2.0, with open governance behind it.
• You need client-side encryption of state and plan files.
• Provider for_each would simplify a multi-region layout that currently repeats provider blocks.
• You run your own backend and have no dependency on HCP Terraform, Stacks or Sentinel.

Stay on Terraform if

• You run HCP Terraform for remote state, hosted plans and applies, or the private module registry.
• You rely on Sentinel policies or on Stacks for multi-environment orchestration.
• You want vendor support from IBM and HashiCorp standing behind the tool your production estate depends on.

Notice what appears on neither list: basic capability. A small team applying changes to its own AWS or Azure accounts will find that either binary does the job well today.

There is also a respectable third option, which is to wait. If your current setup works and a platform review is already on the calendar, decide then with real usage data instead of switching on a headline.

Questions Teams Ask Before Switching

Is Terraform still free to use?

Yes, for the use most teams make of it. The BSL restricts competing commercial use, not a company managing its own infrastructure, and HashiCorp’s licensing FAQ says nothing changes for those users.

You pay only when you choose paid products on top. HCP Terraform is the obvious example, and it is a platform subscription rather than a license fee for the CLI itself.

Can I move back from OpenTofu to Terraform?

Usually, yes. Keep your state backups, avoid OpenTofu-only features during the trial, and Terraform can pick the same configuration back up afterwards.

The exception is encrypted state. Once OpenTofu encrypts your state files, Terraform cannot read them, so treat switching encryption on as a commitment rather than an experiment.

Do the same providers work in both tools?

Yes. Both tools speak the same provider protocol and use the same public registry, so providers built for Terraform 1.5 and later run in OpenTofu unmodified.

That shared ecosystem is the main reason this migration is realistic at all. Without it, switching tools would mean rewriting every integration you depend on.

Which tool should a new team start with?

Start with the platform question rather than the feature list. If you know you will never buy HCP Terraform, OpenTofu removes a licensing worry at zero functional cost for standard infrastructure work.

If hosted state, managed policies and vendor support already sound attractive, Terraform is the straighter path. You will save yourself a migration by starting where you intend to finish.

Are Terraform and OpenTofu version numbers comparable?

No. The two projects release on independent schedules from a shared ancestor, so identical version numbers hide different code, different features and different bugs.

Judge each release on its own changelog instead. A higher number on one side tells you nothing about which tool is ahead in any area that matters.

The Call I Would Make in 2026

Three years after the fork, this is no longer a protest vote. OpenTofu is a mature, openly governed, MPL-licensed tool that leads on state encryption and handles ordinary infrastructure work as well as Terraform does.

Terraform remains the safer default for organisations bought into HashiCorp’s platform. HCP Terraform, Stacks and Sentinel form a combination OpenTofu simply does not offer, and pretending otherwise would help nobody.

Pick based on the platform you run and the license you can defend in a review meeting, not on habit or on version numbers. Get that decision right, and the CLI itself will feel familiar within a day.

What you provision still needs watching afterwards. Our cloud monitoring tools comparison covers the tools that take over once the apply finishes.