If your side project or small team has been quietly running Terraform state through HCP Terraform's free tier for years, that free ride is over. As of July 2026, HashiCorp has discontinued the free tier for HCP Terraform, and re-verified pricing pages confirm the change is real — not a temporary glitch or a regional rollout quirk. For a lot of teams, this is the first time in years they've had to think seriously about whether Terraform is still the default choice for infrastructure as code, or whether OpenTofu, its open-source fork, has matured enough to be the safer long-term bet.
This isn't just a pricing story. It's a trigger event that's forcing a decision a lot of teams have been putting off since HashiCorp relicensed Terraform under the Business Source License in 2023. Below is what actually changed, how Terraform and OpenTofu really differ today, why this fits a bigger pattern across HashiCorp's product line, and what a real migration involves if you decide to move.
Why cutting the free tier matters more than it sounds
HCP Terraform's free tier was never just a marketing gimmick — it was the default remote-state backend for an enormous number of small teams, solo consultants, and side projects. It solved the annoying part of Terraform state management (locking, versioning, secure storage, a web UI for reviewing plans) without anyone having to run their own backend. For teams too small to justify a paid contract, "just use the free tier" was the standard advice, repeated in tutorials, onboarding docs, and Stack Overflow answers for years.
Discontinuing that tier removes the on-ramp that got a huge number of people into the HashiCorp ecosystem in the first place. It's a much more immediate concern than a licensing change buried in legal text — it's a bill, or a forced migration, showing up in someone's inbox. Worse, there's still lingering ambiguity in HashiCorp's own pricing pages about exactly what resource limits apply on the paid plans, which makes it hard for teams to even budget confidently for staying put. When the cost of the status quo becomes uncertain, evaluating alternatives stops being optional homework and starts being due diligence.
That's exactly the moment OpenTofu was built for.
It's also worth naming the second-order effect: a lot of the teams affected by this aren't enterprise buyers with a procurement process and a vendor-relationship owner. They're solo developers, small consultancies, and internal platform teams at startups who adopted Terraform years ago because it was the obvious, well-documented default — and who never had a reason to interrogate the licensing terms underneath the free tier they were using. Those are exactly the users least equipped to absorb a surprise infrastructure bill or a rushed migration under deadline pressure, and exactly the users most likely to start asking, for the first time, who actually controls the tool they've built their infrastructure around.
Terraform vs. OpenTofu: what actually differs today
OpenTofu emerged in 2023 as a Linux Foundation-backed fork of Terraform, created specifically because HashiCorp moved Terraform from the open-source Mozilla Public License to the more restrictive Business Source License (BSL) 1.1. Three years later, the practical differences between the two tools come down to three things.
- License: Terraform remains under BSL 1.1, a source-available license with usage restrictions that HashiCorp controls and can adjust. OpenTofu is MPL 2.0 — a genuine, permissive open-source license with no vendor-imposed usage restrictions.
- Governance: Terraform's roadmap, release cadence, and product decisions (including pricing for HCP Terraform) are controlled entirely by HashiCorp, which is now itself owned by IBM. OpenTofu is steered by a technical committee under the Linux Foundation, meaning no single vendor can unilaterally change its license or direction.
- Features and ecosystem: For a while after the fork, OpenTofu was playing catch-up on features. That gap has been closing steadily, and by mid-2026 it's arguably running in the other direction in places, with the CLI feature gap between the two tools narrowing and, in some areas, favoring OpenTofu.
On raw ecosystem size, OpenTofu is no longer a scrappy alternative you have to justify using — as of June 2026 it counts more than 3,900 providers and more than 23,600 modules, a scale that removes "the ecosystem is too thin" as a credible objection for the vast majority of real-world infrastructure use cases. And OpenTofu's release cadence has kept pace: version 1.12.0 shipped on May 14, 2026, closing feature gaps that infrastructure-as-code teams had been flagging for years, including capabilities that Terraform users had been requesting from HashiCorp without resolution.
None of this means Terraform is somehow broken or abandoned — HashiCorp still ships regular releases and HCP Terraform still works fine for teams that pay for it. But "still works" and "still the obvious default" are different claims, and the free tier's disappearance is exactly the kind of event that makes teams re-examine which one is actually true for their situation.
It's worth being precise about what "governance" means in practice here, because it's easy to wave the word around without explaining why it matters day to day. With Terraform, HashiCorp alone decides what ships, when it ships, which features stay gated behind paid tiers, and what the license permits — and that same company decided, unilaterally, to discontinue a free tier that a large chunk of its user base had built workflows around. With OpenTofu, no single company can make an equivalent decision unilaterally, because the technical committee model under the Linux Foundation distributes that authority across the community and its maintaining organizations rather than concentrating it inside one commercial vendor. That structural difference is exactly why teams that got burned by the free-tier cut are looking at OpenTofu now — not because they expect it to be free forever, but because no future pricing decision can arrive as a surprise handed down from a single vendor's roadmap.
The OpenBao parallel: this is a pattern, not an isolated incident
If OpenTofu were the only fork born from HashiCorp's BSL relicensing, you could dismiss it as a one-off community reaction to a single unpopular decision. It isn't. OpenBao — the open-source fork of HashiCorp Vault, created through the same relicensing dynamic that produced OpenTofu — has been reaching its own adoption milestones alongside OpenTofu in what's increasingly being described as the "post-HashiCorp BSL" ecosystem.
That matters for anyone making infrastructure tooling decisions right now, because it reframes the question. This isn't "should I switch this one tool because I don't like this one pricing decision." It's "HashiCorp's shift to BSL licensing, and its subsequent acquisition by IBM, is reliably producing credible, Linux Foundation-governed open-source alternatives to its core products — and those alternatives are gaining real traction, not just goodwill." If you use both Terraform and Vault, the free-tier cut is a good moment to evaluate your exposure to HashiCorp's commercial roadmap decisions across your entire tooling stack, not just the one line item that happened to show up on a pricing page this month.
IBM's ownership of HashiCorp is the backdrop worth keeping in view here. Pricing and roadmap decisions across the HashiCorp product line are increasingly shaped by that ownership structure, and teams that build their infrastructure practice around HashiCorp's commercial tools should expect more decisions like this one, not fewer, as that integration continues.
What a real migration actually involves
Before you commit to moving, it's worth being honest about what a Terraform-to-OpenTofu migration actually requires — it's not a find-and-replace exercise, but it's also not a rewrite.
State file compatibility is the good news: OpenTofu was built to be a drop-in replacement at the state level. Existing Terraform state files work with OpenTofu without conversion, because OpenTofu forked from Terraform's codebase at a point before the license change and has maintained compatibility since. For most teams, this is the single biggest risk factor in any migration, and it's largely a non-issue.
Provider compatibility is the second thing to check. The overwhelming majority of Terraform providers work unmodified with OpenTofu, since providers communicate with the core tool through a stable plugin protocol rather than depending on Terraform-specific internals. Given OpenTofu's provider registry now covers more than 3,900 providers, the practical odds that your specific providers are supported are high — but it's still worth confirming for anything niche or internally maintained before you commit.
CI/CD pipeline changes are usually the most time-consuming part in practice, even though they're conceptually simple. Every place your pipelines reference the terraform binary, install it via a package manager, or pull it from a container image needs to point at the tofu binary and its equivalent installation sources instead. Remote state backend configuration needs updating if you're moving off HCP Terraform to OpenTofu's supported state backends. And any tooling that shells out to Terraform-specific commands or parses its output in brittle ways needs a compatibility check, since OpenTofu aims for CLI parity but isn't byte-for-byte identical in every edge case.
Beyond those three areas, a few smaller items are worth putting on the checklist before you flip the switch in production. Wrapper scripts and Makefiles that call terraform directly need updating alongside your CI/CD definitions, and it's easy to miss one buried in a less-visited repository. Documentation, onboarding guides, and internal runbooks that reference Terraform commands should get updated in the same pass, so new team members aren't learning a workflow that no longer matches reality. And if you rely on any Terraform Cloud- or HCP Terraform-specific features — VCS-driven runs, Sentinel policies, cost estimation — confirm what OpenTofu's ecosystem offers as an equivalent before you assume it's a like-for-like swap, since these platform-level integrations aren't part of the core CLI compatibility story and need their own evaluation. None of this is technically hard. It's the kind of unglamorous checklist work that gets underestimated precisely because each item is individually small.
Who should migrate — and who shouldn't bother yet
Teams that were relying specifically on the HCP Terraform free tier for remote state, and have no other entanglement with HashiCorp's commercial ecosystem, are the clearest candidates for switching. You're already being forced to make a change; the incremental effort of moving to OpenTofu instead of onto a paid HCP Terraform plan is small, and it buys you out from under future licensing and pricing decisions you don't control.
Teams with deep integration into HCP Terraform's paid features — Sentinel policy enforcement, private module registries tightly wired into existing workflows, or enterprise support contracts already in place — have less urgency. The migration effort is the same regardless of team size, but the payoff is smaller if you're already paying for and using HashiCorp's commercial tooling effectively. For those teams, the free-tier cut isn't a forcing function; it was never relevant to how you were using the product.
For everyone in between, the calculus is straightforward: check whether your providers are covered, confirm your CI/CD pipeline changes are as small as they look on paper, and weigh the ongoing value of governance independence against the (typically modest) migration effort. Given state and provider compatibility are largely solved problems, the technical bar for switching is lower than most teams assume — the real decision is less about tooling risk and more about how much weight you put on avoiding future surprises from a vendor whose licensing and pricing decisions you don't control.
The free tier's disappearance won't be the last HashiCorp decision that pushes teams toward OpenTofu, OpenBao, or whatever comes next in this pattern. Teams that treat this as a one-time inconvenience to work around will likely be back here again. Teams that treat it as a signal about who controls their infrastructure tooling roadmap will make a decision that holds up regardless of what HashiCorp — or IBM — decides to do next.