HashiCorp’s managed Terraform platform ended its free tier, and the new pricing model that took effect March 31, 2026 ties cost to managed resources, run concurrency, and workspace usage rather than a flat seat or workspace count. That change is the reason many platform teams are running an infrastructure as code tool comparison right now instead of renewing on autopilot.
Quick take
Stay on HCP Terraform only when your estate is Terraform-only and you can model the new usage-based bill against actual managed-resource and run-concurrency counts before renewal.
Move to a multi-IaC governance layer when your stack already mixes Terraform, OpenTofu, Pulumi, or CloudFormation and you need drift detection and cost visibility without bolting on separate tools.
Pick a cloud-native control plane such as Google Cloud’s Infrastructure Manager when you want the provider’s own lock and permission model wrapped around a standard Terraform state file.
The workload question comes before the vendor question. A team running one cloud, one IaC language, and a small number of workspaces faces a very different cost curve than one running several business units across multiple clouds with parallel pipelines.
What Changed in Terraform Cloud Pricing and Governance
Before the change, teams could adopt Terraform Cloud at low or no cost and scale usage gradually, which made workspace sprawl relatively cheap to absorb. Under the pricing that took effect March 31, 2026, the same sprawl now shows up directly on the invoice because both managed resources and run concurrency count toward cost.
Governance has not moved at the same pace as pricing. Terraform Cloud enforces policy through Sentinel, but it does not ship native drift analysis or integrated cost forecasting, so teams that want those capabilities are adding configuration or separate tooling on top.
Multi-IaC support is becoming a stated buying criterion rather than a nice-to-have. Organizations increasingly run Terraform, OpenTofu, Pulumi, CloudFormation, and Kubernetes tooling side by side, and platforms that unify operations across all of them from a single control plane are gaining preference over single-engine tools.
The market context explains why this matters at budget-planning time and not just at renewal time. The infrastructure as code market was valued at USD 1.06 billion in 2024 and is forecast to reach USD 9.40 billion by 2034, a 24.39% CAGR, and more than 70% of organizations already wire IaC into CI/CD pipelines. Tool choice is no longer a side decision for a platform team; it sits on the critical path of most delivery pipelines.
Infrastructure as Code Tool Comparison: State, Policy, and Portability
An infrastructure as code tool comparison for 2026 has to separate four operating dimensions: how state is stored and mutated, how policy is enforced, how teams collaborate on changes, and how portable the workload is if you switch control planes later.
State handling is the dimension vendors describe as solved and operators still touch by hand. Google Cloud’s Infrastructure Manager wraps Terraform state in its own lock and permission model, but importing or removing a resource still means locking the deployment, downloading the state file through a signed Cloud Storage URL, running terraform init locally, mutating the file, and uploading it back before unlocking.
That workflow depends on holding the config.admin role or the six underlying permissions it bundles, and on keeping a local copy of the exact .tf configuration that matches the downloaded state file. Skip the local-copy step and a terraform plan against the mutated state can diverge from what the provider believes is deployed.
Collaboration is where general-purpose-language tooling makes its case. Pulumi’s own framing is that teams with programming backgrounds get more out of testing, abstraction, and code review when infrastructure is expressed in a real language rather than a template DSL, though this is Pulumi’s own comparative framing rather than an independent benchmark.
| Platform | Cost driver | Policy enforcement | State handling |
|---|---|---|---|
| HCP Terraform (Terraform Cloud) | Managed resources, run concurrency, workspace usage since March 31, 2026 | Sentinel policy as code; no native drift or cost analysis built in | Managed, Terraform-only workspace state |
| Google Cloud Infrastructure Manager | Underlying Google Cloud deployment usage | Deployment lock/unlock gated by config.admin permissions |
Standard Terraform state file, manually downloaded and re-uploaded per change |
| Multi-IaC governance layer | Platform-tier pricing, evaluated per vendor | Cited as a buying criterion: native policy libraries and drift detection | Coordinates Terraform, OpenTofu, Pulumi, and CloudFormation from one control plane |
Portability is the criterion the table understates, because it shows up only when something goes wrong with the primary vendor. Teams evaluating alternatives are doing so specifically because a single-engine, single-vendor model concentrates both cost risk and governance gaps in one place.
Decision Criteria for Standardizing on One Stack
Standardizing makes sense only when the workload stays close to one IaC engine and one or two clouds, because that is the case where a managed platform’s pricing and policy model can be modeled cleanly against actual usage. Once the estate spans multiple IaC languages, the calculus shifts toward a control plane built to unify them rather than toward the strongest single-engine tool.
Governance frameworks add a layer above the tool choice itself. Microsoft’s Cloud Adoption Framework treats the platform landing zone as a decision-maker input rather than an implementation detail, and it separates the architecture guidance from whichever IaC deployment option — accelerator or custom build — actually implements it.
That separation matters operationally. In June 2026, ownership of the platform landing zone accelerator assets moved to the Azure Migrate product team, but Microsoft was explicit that the change affects only asset ownership and does not touch the guidance, functionality, or the decisions teams make from the Cloud Adoption Framework itself.
The same framework also shows how fast reference IaC assets can be deprecated underneath a stable governance model. Application landing zone accelerators for Azure Integration Services, Kubernetes Services, API Management, App Service, and Container Apps were deprecated in April 2026, and their articles were removed in May 2026, even though the underlying GitHub repositories with the deployable code stayed available.
For a decision-maker, that gap between “the article is gone” and “the code is still there” is a portability signal worth checking before adopting any vendor-authored accelerator: confirm which artifacts a deprecation actually removes before building a pipeline against them.
Switching Costs and What to Verify Before Committing
Before renewing or migrating off a Terraform Cloud-style platform, the workspace and run-concurrency counts that drive the new bill need to be modeled against real usage, not list pricing, because that is exactly the mechanism the March 31, 2026 change introduced.
Before adopting a cloud-native control plane for state, verify who actually holds the config.admin role or its equivalent permission set in your organization, and confirm that the team responsible for terraform plan runs also holds the local configuration copy the lock-and-mutate workflow depends on.
Before treating any vendor governance framework as a stable foundation, check which of its components are guidance and which are deployable reference code, since the two can move on different deprecation timelines even under one umbrella program.
The migration case is not ready until the actual bill under your workspace count, the permission model behind your state backend, and the deprecation status of any reference accelerator you depend on are all confirmed rather than assumed.