OpenTofu crosses the tipping point as the default engine for new IaC workspaces
On Scalr’s platform, OpenTofu now runs 63% of Terraform-compatible runs and powers 72% of newly created workspaces — not a snapshot of the global market, but of where new work is heading. Version 1.12 adds dynamic prevent_destroy and full provider checksums. For teams provisioning infrastructure, new projects should default to OpenTofu.
August 2023. HashiCorp moves Terraform from the MPL 2.0 to the Business Source License 1.1, and the community fork becomes OpenTofu under the Linux Foundation. May 14, 2026. Version 1.12 ships with dynamic prevent_destroy and full provider checksums. Mid-2026. On the Scalr platform, OpenTofu runs 63% of runs and 72% of new workspaces. The tipping point is no longer a prediction, it is a measurement — provided you read the numbers for what they actually say.
Numbers you have to read carefully
Caution is warranted, and the numbers reward it. The 63% of runs and 72% of new workspaces come from Scalr’s telemetry, published in its 2026 guide: they describe the Scalr platform, not the global infrastructure-as-code market.
At the global scale, the picture is more nuanced. CodeOxi estimated OpenTofu adoption at 12% in April 2026, with another 27% of teams evaluating; Terraform still holds between a third and three-fifths of the market depending on measurement. And Firefly, in September 2025, found only 5% of organizations had fully migrated their existing Terraform workloads.
All three numbers can be true at once: the installed base is overwhelmingly Terraform, the direction of new work is OpenTofu, and completed migrations lag behind both. The 72% of new workspaces is the more important of the two figures, because it measures choices made this quarter, not the legacy of scheduled applies from the past.
What 1.12 actually changes
Version 1.12, released on May 14, 2026, is not flashy, and that is its strength. It delivers:
- Dynamic prevent_destroy: the
prevent_destroyargument in alifecycleblock can now reference a module variable, making production-database protection conditional on the environment; - Full provider checksums:
tofu initnow recordszh:andh1:hashes for all platforms automatically, removing the need to runtofu providers lockby hand; - The -json-into=FILENAME flag: machine output can go to a file while the human UI stays on standard output;
- The destroy = false lifecycle option: remove an object from state without destroying the remote object;
- Concurrent provider installation to speed up
tofu init.
An example of the first point, which captures the project’s spirit:
variable "prevent_destroy_database" {
type = bool
default = true
}
resource "example_database" "example" {
# ...
lifecycle {
prevent_destroy = var.prevent_destroy_database
}
}The same module protects the database in production and leaves it deletable in development. OpenTofu also announced the deprecation of WinRM for provisioners and the phase-out of 32-bit builds starting with the 1.13 series.
Why the flip is not a bet
OpenTofu’s tipping point rests on a detail feature comparisons often miss: providers. OpenTofu consumes the same provider binaries as Terraform — one format, no maintainer action required. Switching engines therefore costs nothing in module availability. Moving to Pulumi, by contrast, means rebuilding or wrapping your module library.
That asymmetry explains the shape of the migration curve: flat for years, then steep. There is no ecosystem tax waiting on the other side.
The smaller changes point the same direction. -json-into=FILENAME lets a CI tool consume machine-readable output while a human watches the normal UI, and concurrent provider installation speeds up cold tofu init runs on large configurations. Individually modest, together they signal a project optimizing for the platform and CI use cases where the fork is winning — not just for the lone operator on a laptop.
The enterprise proof is Fidelity Investments: more than 2,000 applications, 50,000 state files, over 4 million cloud resources, and 70% of projects migrated to OpenTofu within two quarters — with no state conversion, because the state format is shared. A regulated financial institution moving four million resources without rewriting state is the end of the “migration risk” objection.
The timeline that turned a grievance into strategy
The story fits in five dates. In August 2023, HashiCorp moved Terraform to the BSL 1.1 — source-available, not open source — and the fork emerged within weeks. In February 2025, IBM closed its $6.4 billion acquisition of HashiCorp; the license stood, and Terraform joined IBM’s automation portfolio alongside Ansible. In April 2025, the CNCF accepted OpenTofu as a Sandbox project, granting it the neutral governance that matters to regulated buyers.
The point that changed everything was GitLab 18.0: the host removed its built-in Terraform templates and the gitlab-terraform helper, because it could no longer ship updated Terraform binaries under the BSL. The 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 coverage bet.
The feature lead that makes the flip credible
The flip also rests on a real lead. End-to-end state encryption landed in v1.7, after five years of requests; Terraform answered only with ephemeral resources, which keep individual secrets out of state without ever encrypting the whole file. Early variable evaluation (v1.8), provider for_each (v1.9), the -exclude flag (v1.9), the OCI registry (v1.10), and native S3 locking without DynamoDB (v1.10+) all shipped in OpenTofu first. State encryption, in particular, is a compliance requirement in regulated industries — exactly where enterprise adoption is concentrating.
The term “drop-in replacement” has quietly inverted. After three years of divergence, the phrase undersells the fork — in OpenTofu’s favor as often as not — because the features teams actually asked for landed there first. The honest caveat is the mirror image: a workspace should live on a single engine during any transition, since post-fork features and OpenTofu-only features do not share a common middle ground.
What it changes for your choices
The decision now collapses to a simple rule: new infrastructure-as-code work should default to OpenTofu, and Terraform should stay exactly where something pins you to it — HCP Terraform / Terraform Enterprise, Stacks, or a support contract.
The migration path is itself trivial, which is a compliment:
# 1. Verify a clean state
terraform plan
# 2. Back up the state file and remote-state config
# 3. Install the binary and point CI at it
tofu init -upgradeProviders resolve from registry.opentofu.org instead of registry.terraform.io — the same binaries underneath. One real precaution: avoid single-camp features (OpenTofu state encryption on one side, Terraform’s post-fork features on the other) in any configuration that must run under both engines during the transition. Pick one engine per workspace, migrate the workspace, and the constraint disappears.
None of this makes the switch free of trade-offs. Terraform still holds the high ground on HCP Terraform and Terraform Enterprise, the Stacks orchestration model, and first-party vendor support. Teams building on those are not wrong to stay; they are pinned, and that is a different thing from choosing.
Verdict
OpenTofu is no longer a “panic fork”: it is the engine new work defaults to, wherever teams are free to choose. The 72% of new workspaces on Scalr does not say Terraform is dead — it says the burden of proof has switched sides.
If you provision infrastructure with Terraform-compatible tooling, default new projects to OpenTofu, and migrate existing workspaces as you touch them. Keep Terraform only where a contract, Stacks, or HCP pins you to it.
If you are still on Terraform with no support constraint, you lose nothing by switching — same state format, same providers — and you gain native state encryption and open governance under the Linux Foundation.