GitOps with OpenTofu: Why We Chose It Over Terraform
When HashiCorp changed Terraform's license to BSL in 2023, we started evaluating OpenTofu. Here's what we learned after running both in production, and why OpenTofu is now our default for new projects.
In August 2023, HashiCorp changed Terraform’s license from MPL 2.0 to the Business Source License (BSL). For most users, this changed nothing immediately. For us, it raised a question we needed to answer before it became urgent: what’s our IaC foundation?
We evaluated OpenTofu — the CNCF-hosted, OpenTF fork — over about three months, running it alongside Terraform on non-critical stacks. This is what we found.
Why the license change mattered
The BSL isn’t GPL or AGPL hostile, but it creates uncertainty for:
- Tools that wrap Terraform — if you build automation on top of Terraform (we do, with Neptune), the definition of “competitive” is ambiguous enough to warrant legal review
- Commercial SaaS incorporating Terraform — the “competitive use” restriction could apply depending on how the product is structured
- Long-term supply chain risk — open source tools that can become closed are a different risk class than tools that can’t
The first concern was the deciding factor for us. Neptune wraps tofu/terraform as a subprocess; we didn’t want a license ambiguity about whether the tool we’re building is competitive with HashiCorp Cloud Platform.
What OpenTofu actually is
OpenTofu is a fork of Terraform 1.5.x, maintained by the Linux Foundation under the CNCF. It’s licensed under MPL 2.0 — the original Terraform license.
The fork was organized quickly. The OpenTF manifesto went up in August 2023; the CNCF sandbox acceptance and first release (1.6.0) happened by January 2024. The project now has maintainers from Spacelift, Gruntwork, Harness, and others with significant IaC investment.
Compatibility: OpenTofu is a drop-in replacement for Terraform up to the fork point. terraform init → tofu init. terraform plan → tofu plan. Existing .tf files, providers, and state files work without modification.
Three months running both
We ran OpenTofu against Terraform on development stacks first, then promoted it to production. Here’s what we observed:
Syntax compatibility
Zero breaking changes moving existing Terraform code to OpenTofu. We had ~40 modules across 3 environments; not a single .tf file required modification.
Providers were the only question mark. All major providers (AWS, GCP, Kubernetes, Helm) publish to both the HashiCorp registry and the OpenTofu registry. required_providers blocks pointing at registry.terraform.io still resolve correctly because OpenTofu’s default registry aliases it. For new modules, we now point at registry.opentofu.org explicitly.
State compatibility
Terraform and OpenTofu state files are interchangeable. We migrated stacks mid-flight (Terraform had created resources, OpenTofu continued managing them) without ceremony. The state format hasn’t diverged.
This is the key practical fact: migration is not a migration. It’s changing which binary runs plan and apply.
Feature delta
OpenTofu has added features Terraform hasn’t shipped (provider-defined functions, early evaluation of variables, tofu test improvements). None of these were why we switched, but they’re a sign the project is moving independently.
CI integration
Our Neptune-based CI runs tofu as a subprocess. The integration was a one-line change: binary: tofu in the Neptune config. Neptune supports both; binary: terraform remains the default for backwards compatibility.
The actual decision
The license analysis mattered. But the operational conclusion is simpler: OpenTofu is Terraform with a different binary name and a more open governance model.
If you’re already on Terraform:
- No urgent migration needed — BSL concerns apply mainly to competitive tooling and commercial SaaS
- New projects → start with OpenTofu; it’s the safer long-term bet
- Migration → when you’re ready, change the binary and update provider source blocks; plan for 2–4 hours on a mid-size estate
If you’re evaluating IaC tooling from scratch in 2026, OpenTofu is the obvious choice: compatible, CNCF-backed, MPL 2.0.
What we use now
- All new infrastructure at devopsfactory.io: OpenTofu
- Neptune: supports both; default examples in docs use OpenTofu
Neptune’s binary selection is documented in the configuration reference. OpenTofu’s migration guide is at opentofu.org/docs/intro/migration.