OpenTofu Is the Majority Terraform Engine on One Major Platform: What the 63% Tipping Point Means for Your Fleet's IaC Layer

On one major infrastructure-as-code platform, OpenTofu now runs roughly 63% of all Terraform-compatible runs and powers 72% of newly created workspaces as of mid-2026. Three years ago the fork was a protest vote against a license change; today it is the engine new work defaults to, at least where teams get to choose freely. That is the tipping point this post is about — not a declaration that Terraform is dead, but the moment the burden of proof flipped.

Here is the bottom line up front, because a post about defaults should state its own default in paragraph two: if you run a self-hosted platform and you are provisioning machines, networks, or Cluster API fleets with Terraform-shaped tooling, new IaC work should default to OpenTofu. Keep Terraform exactly where something pins you to it — HCP Terraform / Terraform Enterprise workflows, Stacks, a vendor support contract — and nowhere else. The rest of this post is the receipt: what the numbers actually say and where they come from, how the fork pulled ahead on features, the enterprise-scale migration that proves the switch is safe, and the honest gaps that remain before "just use OpenTofu" has no tradeoff at all.

One scoping correction first, because the headline number needs it. The 63%-of-runs and 72%-of-new-workspaces figures come from Scalr's platform telemetry, published in their 2026 guide — they describe runs on Scalr's platform, not the global IaC market.

Globally, CodeOxi's April 2026 tracking puts OpenTofu at about 12% adoption with another 27% of teams evaluating or planning to expand use, while Terraform holds somewhere between a third and three-fifths of the market depending on how you measure it. And Firefly's September 2025 analysis found only around 5% of organizations had fully migrated existing Terraform workloads.

All of those numbers can be true at once: the installed base is overwhelmingly Terraform, the direction of new work is OpenTofu, and completed migrations lag both. A post about a tipping point should be precise about which curve already tipped.

How a license change forked an ecosystem​

The whole story fits in five dates. In August 2023, HashiCorp moved Terraform from the Mozilla Public License 2.0 to the Business Source License 1.1. The BSL is source-available, not open source: the code stays visible on GitHub and free for internal use, each version converts to MPL four years after release, but building a competing hosted or embedded offering on it requires a commercial license. The community forked Terraform ~1.5 within weeks, and that fork became OpenTofu under Linux Foundation governance.

In February 2025, IBM closed its $6.4B acquisition of HashiCorp. Anyone hoping new ownership would revert the BSL was disappointed: the license stands, Terraform is being folded into IBM's automation portfolio alongside Red Hat Ansible, and the fork's reason to exist hardened from grievance into strategy. In April 2025 the CNCF accepted OpenTofu as a Sandbox project, giving it neutral governance credibility that matters enormously to regulated buyers. By mid-2026 the current stable line is v1.12.x, and the two codebases have been diverging long enough that "drop-in replacement" now needs an asterisk — in OpenTofu's favor as often as not.

The BSL's blast radius kept widening after the acquisition, which is what turned a licensing debate into an operational one. GitLab removed its built-in Terraform CI/CD templates and the gitlab-terraform helper in GitLab 18.0 because it could no longer ship updated Terraform binaries under the BSL — its officially recommended path is now the OpenTofu CI/CD component. When the second-largest Git host tells you to switch binaries, the fork stops being a hedge.

The numbers, honestly scoped​

Here is every figure in this post in one table, each labeled by what it actually measures:

Read the table the way a platform engineer should: platform-measured runs (Scalr) show where greenfield choice lands when both engines are offered side by side; surveys (CodeOxi) show the global installed base where Terraform's incumbency still dominates; and completed-migration share (Firefly) shows that most teams haven't touched their existing state yet. The tipping-point claim rests on the first row — the flow of new work — not on pretending the stock already flipped. Notably, the 72% figure for newly created workspaces is the more important of the two: runs include legacy scheduled applies, while new workspaces are choices made this quarter.

Where the fork pulled ahead — and where it still lags​

OpenTofu did not just replicate Terraform; in the areas the community had requested for years, it leapfrogged it. Native end-to-end state encryption landed in v1.7 after roughly five years of upstream requests — Terraform answered with ephemeral resources in 1.10, which keep individual secrets out of state but never addressed encrypting the whole state file. Early variable and locals evaluation (v1.8), provider iteration with for_each (v1.9), the -exclude flag for selective applies (v1.9), OCI registry support for modules and providers (v1.10), and native S3 state locking without DynamoDB (v1.10+) all shipped in OpenTofu first. These are not cosmetic gaps; state encryption alone is a compliance requirement in regulated industries, which is exactly where enterprise adoption is concentrating.

The other half of the table is Terraform-only, and intellectual honesty requires listing it plainly:

The row that matters most for migration math is the one missing from the table: providers. OpenTofu consumes the same provider binaries as Terraform — one provider format, no maintainer action needed — so switching engines costs nothing in module availability. Moving to Pulumi, by contrast, means rebuilding or wrapping your module library. That asymmetry is why the migration curve can stay shallow for years and then go steep: there is no ecosystem tax waiting on the other side.

Proof it migrates at scale​

The enterprise reference case is Fidelity Investments, and its numbers deserve quoting exactly: over 2,000 applications using Terraform or OpenTofu, more than 50,000 state files, north of four million individual cloud resources, upwards of 4,000 state file updates on any given day. Fidelity's platform team moved 70% of those projects to OpenTofu within two quarters — with no state conversion, because the state format is shared. As their lead put it, the technical side of the migration is trivial; what matters is organizational change management. A regulated financial institution migrating four million resources without a state rewrite is the strongest possible evidence that the "migration risk" objection has expired.

The shape of a migration is correspondingly boring, which is a compliment:

1. Verify current state is clean — no pending changes in terraform plan.
2. Back up the state file and any remote-state configuration.
3. Install the tofu binary, point CI at it (or at the OpenTofu CI/CD component on GitLab), and run tofu init -upgrade — providers resolve from registry.opentofu.org instead of registry.terraform.io, same binaries underneath.

The one genuine caution: avoid Terraform-only features added after the fork (~v1.6) and OpenTofu-only features like state encryption in any configuration that must run under both engines during a transition window. Pick an engine per workspace, migrate the workspace, and the constraint disappears.

What this means for a Cluster-API fleet's IaC layer​

Translate all of the above into decisions for a self-hosted PaaS that provisions its own machines — Hetzner servers, Cluster API lifecycles, the IaC layer underneath the fleet:

• Default all new provisioning tooling to OpenTofu. Fleet bootstrap modules, node-pool definitions, network and DNS wiring — anything you write from today onward should target tofu. The MPL license means no BSL review every time you embed the binary in an operator image, a CI runner, or a managed offering, and v1.10+ features like OCI registry support and native S3 locking are things a fleet provisioner concretely benefits from.
• Accept tenant-brought Terraform modules without friction. Because HCL and provider binaries are shared, a tenant's existing modules run under either engine. You do not need a migration ultimatum to standardize your own default — the formats interoperate, so meet tenants where they are.
• Pin CI and automation images to OpenTofu. GitLab already forced this decision for its own templates; self-hosted runners and fleet-automation containers should follow. One engine in the pipeline removes the "which binary applied this state" ambiguity from every future incident.
• Keep Terraform only where something pins you to it. HCP Terraform / Terraform Enterprise workflows, Stacks-based orchestration, a support contract that names HashiCorp — these are real reasons, and the honest version of "default to OpenTofu" names its exceptions instead of pretending there are none.
• Watch the remaining gaps, but price them correctly. There is no HCP equivalent in the OpenTofu ecosystem, enterprise features lag, and CDKTF's deprecation in December 2025 removed the TypeScript escape hatch for both engines equally. None of these blocks a self-hosted fleet provisioner; all of them matter if you were renting HashiCorp's control plane rather than running your own.

The deeper point is architectural, and it is why this story belongs on a platform-engineering blog rather than a licensing-watch one. A self-hosted PaaS exists to remove single-vendor control over its tenants' infrastructure. Running the fleet's own provisioning on an engine whose license restricts embedded and managed use — owned by a vendor whose portfolio strategy it now serves — recreates at the IaC layer the exact dependency the platform was built to eliminate. OpenTofu's Linux Foundation governance is not a philosophical preference here; it is the same control-plane-independence argument as owning the machines.

The default already moved​

Three years on, the fork has its own registry traffic in the millions of daily requests, triple-digit year-over-year growth on vendor platforms, a CNCF Sandbox home, a 50,000-state-file enterprise reference, and features the upstream still lacks. Terraform remains the installed-base incumbent and will be for years — BSL versions even convert to MPL four years after release, so old Terraform stays usable indefinitely. But incumbency is now the only argument left for choosing it in new work, and incumbency is not a technical argument.

Default new IaC to OpenTofu. Migrate existing workspaces when you touch them, not in a big bang. And keep the one honest exception list short: HCP, Stacks, a support contract. Everything else is momentum.

Running your own platform means owning every layer down to the provisioning engine. Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.