OpenTofu vs Terraform: Which to Use? (2026)
OpenTofu vs Terraform — the open-source fork born from HashiCorp's license change, how they differ now, and which a founder should bet on.
Table of contents8 sections
The Relicense That Started a Civil War
August 2023. I wasn’t even doing infrastructure that week — I was heads-down on something else entirely — when my feeds lit up. HashiCorp had quietly relicensed Terraform. Not a version bump. Not a pricing tweak. They took the single most popular infrastructure-as-code tool on earth, one that thousands of companies had built businesses on top of, and moved it from the open-source MPL to the Business Source License overnight.
The internet did what the internet does. Except this time the anger had teeth, because a huge chunk of the tooling economy — the companies selling Terraform automation, the consultants, the open-source contributors — had just been told the ground under them was now “source-available,” a polite phrase that means you can look but you can’t compete.
Within days, not months, there was a manifesto, a signature drive, and then a fork. It was first called OpenTF, then renamed OpenTofu. And that fork is why, in 2026, “OpenTofu vs Terraform” is a real question instead of a typo.
I didn’t fully feel the weight of it until late 2024, when I finally sat down to Terraform my way out of the usual mess — a URL shortener with zero users that I’d hand-clicked into a pile of cloud resources. I opened the terminal to install the thing, and stopped. Wait. Do I install terraform, or tofu? The fork had forced a decision before I’d written a single line. So let me save you that stall.
What Actually Happened: The Timeline
The whole saga is three moves, and it helps to see them in order because people mash them together.
| When | What happened |
|---|---|
| Aug 2023 | HashiCorp relicenses Terraform from MPL (open source) to the BSL (source-available). The OpenTF manifesto and fork appear within days. |
| Sep 2023 | The fork joins the Linux Foundation, backed by a coalition of vendors, and is renamed OpenTofu. |
| Jan 2024 | OpenTofu reaches general availability — a stable, production-ready release. |
| Feb 2025 | IBM closes its $6.4 billion acquisition of HashiCorp. Terraform is now an IBM product. |
| Apr 2025 | OpenTofu is accepted into the CNCF (at the sandbox level), the same foundation that stewards Kubernetes. |
That last-but-one row is the plot twist nobody saw coming. The community forked Terraform to escape a single vendor’s control — and then that vendor got swallowed by IBM. So the tool a lot of people fled because of corporate ownership is now owned by one of the most corporate companies alive. Meanwhile the “rebel” fork ended up in a neutral foundation. History has a sense of humor.
(I’ve told slices of this story before — in the Terraform import guide and the Terraform Registry post — but this is the one where the fork itself is the whole point.)
BSL vs MPL: The License Difference That Actually Matters
Nobody bootstrapping wants a law lecture, so here’s the part that changes anything for you.
Terraform is now under the Business Source License. In plain terms: you can still download it, use it, run it in production, all for free. What you can’t do is build a competing product with it. It’s “source-available” — the code is visible, but it is not open source by the official OSI definition. For 99% of users running terraform apply, day to day, nothing broke. The fear was never today. It was the precedent: a tool you depend on can change the rules whenever its owner needs a new revenue line, and now that owner is IBM.
OpenTofu is under the MPL — the Mozilla Public License, a genuine OSI-approved open-source license, the exact one Terraform used to carry. No “you can’t compete” clause. No single company that can flip it tomorrow.
The governance gap is the real story. Terraform’s future is decided in a boardroom — IBM’s. OpenTofu’s is decided by a foundation with a public steering committee and a paper trail. Neither is automatically “better.” A well-funded corporate owner can pour engineers at a problem faster than a foundation can. But if the thing that keeps you up at night is who controls the tool my whole infrastructure is described in, those are two very different answers.
How They’ve Diverged Since the Fork
Here’s what surprised me, and what most “they’re basically the same” takes miss: they are not staying identical. For the first year a fork is just the same code with the serial numbers filed off. By 2026, OpenTofu has genuinely pulled ahead in a few places — shipping features Terraform’s open CLI still doesn’t have.
The headline one is state encryption. OpenTofu added native, built-in encryption of your state file at rest back in version 1.7 — you point it at AWS KMS, Google Cloud KMS, or a passphrase, and your state is encrypted before it ever touches the backend. That matters because the state file is the single most dangerous object in this whole workflow — it holds a plaintext map of everything you own, secrets included (I went deep on why that file will ruin your week in the import guide). Terraform’s open binary still doesn’t ship this. The fork shipped it first.
It didn’t stop there. OpenTofu also added:
- The
-excludeflag — the inverse of-target. Instead of “only touch this one resource,” you say “touch everything except this.” Sounds tiny; saves you at 2 AM when one resource is wedged and you need to run everything around it. - Provider
for_each— iterate over provider configurations, so you can spin up the same setup across ten regions without copy-pasting ten provider blocks. - Early variable evaluation — use variables in places (like backend config) where Terraform makes you hard-code.
- OCI registry support — distribute providers and modules through standard container registries, no proprietary hub required.
The point isn’t that any single feature is life-changing. It’s the direction. A community-run fork is now setting the pace on real capabilities, not just keeping the lights on. That’s the strongest signal that OpenTofu is a living project and not a protest that fizzled — it’s got roughly ten million downloads and has been growing fast, which is the kind of momentum that makes a fork permanent.
Switching Is Almost Just a Rename
The thing that makes this whole comparison low-stakes for most people: OpenTofu is a near drop-in replacement. You install it, and instead of typing terraform plan you type tofu plan. Your .tf files are the same HCL. Your providers, your modules, your state — same shapes. For a straightforward setup, migrating is closer to a rename than a rewrite.
It’s not literally zero-friction — once you lean on OpenTofu-only features like state encryption, you’ve walked through a one-way door. But for a founder deciding which to start with, the cost of picking “wrong” is low. You’re not marrying a language. You’re picking which binary types the same commands.
The Ecosystem Gap (and Why It’s Closing)
The one honest advantage Terraform still holds is gravity. It was the default for a decade, so the tutorials, the StackOverflow answers, the pre-built modules, the “how do I do X on AWS” blog posts — overwhelmingly written against Terraform. Hit a weird edge case at midnight and the odds someone already solved it in a Terraform context are just higher.
But this gap is smaller than the fear implies. Because OpenTofu speaks the same HCL and reads the same providers, most of that decade of knowledge applies directly. OpenTofu even stood up its own registry (mirroring the providers and modules, architected as boring static files behind a CDN so it can’t really fall over) — I broke that down in the Terraform Registry post. A tutorial written for Terraform almost always works verbatim on OpenTofu with terraform swapped for tofu. The “bigger ecosystem” argument is real, but shrinking every quarter.
If HCL itself is what makes you want to quit — you want loops and real abstractions and unit tests — that’s a different fork in the road entirely, and it’s called Pulumi. I put it head-to-head against this same family in Pulumi vs Terraform. (And remember Terraform provisions infrastructure — if you’re wondering where a tool like Ansible fits, that’s a separate layer I untangled in Ansible vs Terraform.)
The Broken Engineer Verdict
Here’s the part the vendor blogs bury, because IBM wants you on Terraform and the foundation wants you on OpenTofu.
If you’re a solo founder in 2026, you almost certainly need neither. Not yet.
Ask the honest question before “which one”: how much cloud infrastructure do I actually run? If your stack is Vercel for the frontend, Railway or Fly.io for the backend, and Neon for Postgres — the answer is basically zero. No VPC to stand up, no fleet of instances, no tangle of IAM policies to describe in HCL of any dialect. Those platforms are your infrastructure layer, hidden behind a git push. Choosing between terraform and tofu for infrastructure you don’t have is arguing over which wrench to buy for a car you don’t own.
Both earn their keep at the same moment: when you have sprawl — dozens of resources on AWS or Google Cloud, multiple environments that must stay identical, a team reviewing infra changes in pull requests. That’s a good problem. It usually means real revenue. It is not a $0 MRR problem. (It’s the same altitude where I once convinced myself a redirect service needed a whole Kubernetes cluster. Don’t be me.)
But if you’re genuinely there — real infra, and you have to pick one — here’s the clean call:
- Care about genuinely-open tooling, and want to be safe from the next boardroom decision? OpenTofu. It’s MPL, foundation-governed, shipping features first, and switching costs almost nothing. For a new project in 2026, it’s my default.
- Want the single biggest ecosystem and don’t lose sleep over the BSL? Terraform is still completely fine. The IBM backing means it’s not going anywhere, and every module and tutorial targets it first.
Neither is a mistake. The fork didn’t create a “good one” and a “bad one.” It created a choice — and, refreshingly, one where the low-friction pick and the ideologically-clean pick are the same tool.
The Bottom Line
OpenTofu and Terraform are the same tool that split over a license. HashiCorp went BSL in 2023, the community forked the open version into OpenTofu, IBM bought HashiCorp, and OpenTofu landed in the CNCF — so the “rebel” is now the neutral one and the “original” is the corporate one. Since then OpenTofu has quietly pulled ahead on features like state encryption, while Terraform keeps the ecosystem crown. Switching between them is nearly a rename.
But notice how far down this whole fight lives. Licenses, forks, boardrooms, state encryption — all of it sits below your product, on infrastructure you own and operate. Managed platforms exist so you don’t have to go down there until you’ve earned the right to. The best infrastructure code is the code Vercel already ran for you.
Pick tofu the day you’re actually drowning in cloud consoles and want the open, foundation-backed option — or Terraform if you want the herd. Not before, to feel like a real engineer. I did the whole dance for a product with zero users. (Still assembling the cheap stack that makes all of this unnecessary? Start with the broke solopreneur’s survival guide and where I actually deploy.)
This is the Broken Engineer Guide. I over-engineer everything, fail at business, and share the scars so you can skip a few. Go build something that doesn’t need a state file — in either dialect — yet.
