OpenTofu and the New Rules of IaC
The Terraform fork that became a Linux Foundation project, state encryption built in, and how to decide between tofu and terraform without starting a religion war.
When HashiCorp changed Terraform's license in 2023, the infrastructure world split roughly in half overnight: fork or stay. I stayed put for a long time — migration costs are real and "principled" doesn't patch production. Two years later, with OpenTofu mature and feature-complete, I've finally run the migration properly on a mid-sized estate. Here's the non-religious version of what changed.
What OpenTofu actually is
A drop-in open-source replacement for Terraform, now stewarded by the Linux Foundation — which matters more than the politics: no single vendor can relicense it out from under you. The CLI is deliberately compatible: tofu init, tofu plan, tofu apply do what you'd expect, HCL is HCL, and most providers from the Terraform Registry work unchanged.
Compatibility is the whole pitch. If your pipelines say terraform, changing them to tofu is a find-and-replace, not a rewrite. That was true at v1.6 and it's truer now.
The differences you'll actually feel
State encryption, built in. This is the flagship difference. Terraform traditionally left state encryption to the backend (S3 has it; local and some others don't). OpenTofu encrypts state at rest natively, keys in env or a KMS-like provider:
terraform {
encryption {
key_provider "pbkdf2" "pass" {
passphrase = var.state_passphrase
}
method "aes_gcm" "default" {
keys = key_provider.pbkdf2.pass
}
}
}
One less backend-specific footgun, and finally a sane answer for small teams with local or generic state.
The registry question. OpenTofu reads the public Terraform Registry by default and has its own mirror for the post-license-change world. In practice: providers we used daily — AWS, Kubernetes, random, helm — needed zero ceremony. Verify your provider set early (tofu providers after init) rather than assuming.
Maturity cadence, not feature fireworks. Releases have been conservative and compatibility-focused. You're not buying bleeding edge; you're buying "won't surprise me during a Friday apply."
License, in plain terms. MPL 2.0 — use it, fork it, embed it. For companies whose legal team got nervous about BSL, that's often the entire decision, before engineering weighs in.
The migration, as it actually went
For our estate (~40 root modules, three AWS accounts), the honest effort was:
- Install
tofu, runtofu init -upgradein a module copy,tofu planagainst real state, diff againstterraform plan -json. Expect churn in the plan output format, not in resources. - Run both CLIs through CI in shadow mode for a week —
tofu planon every PR, output compared, nothing applied. - Flip apply pipelines. Total downtime: one maintenance window to swap the runner binary.
- Remove the Terraform binary from runners a month later, once no one paged me.
The only wrinkle was a community provider with a pinned, unmaintained version — fixed by pinning to a registry mirror source. Check your long tail of providers before committing.
When I'd still choose Terraform
Being straight about it: if you're deep in the Terraform ecosystem — Terraform Cloud/Enterprise with its state runs, Sentinel policies, private module registry workflows — staying is rational. OpenTofu's compatibility covers core workflow beautifully, but enterprise control-plane features are a different conversation. Also: huge orgs with hundreds of pipelines may simply prefer the vendor they already argued through procurement for.
When I'd choose OpenTofu
- You want copyleft licensing and no single-vendor relicense risk.
- State encryption without backend gymnastics is worth having.
- You're starting fresh and want the open governance story for the next five years.
- You're small enough that "CLI + state backend" is your entire IaC platform — which describes most teams.
The boring conclusion
Infrastructure-as-code tools should be chosen like rebar: nobody's personality is involved. OpenTofu has earned being called mainstream — compatible where it counts, differentiated where it matters (state encryption, governance), and dull in all the ways infrastructure tooling should be dull.
If you've been postponing the evaluation because it felt like joining a side: run the shadow plan on one module this week. When the diff comes back empty, the "migration" stops being ideology and becomes a checkbox. That's where most teams, ours included, finally land.
SDP Clouds Team
DevOps and cloud engineers writing practical, battle-tested guides on CI/CD, Kubernetes, infrastructure as code, and production operations — every article is based on real incidents and real pipelines, not docs-page rewrites.
More about us →