HCP Terraform (Terraform Cloud) Free Tier Changes

The Terraform Cloud free tier story has gotten confusing quickly: headlines say “free is discontinued,” emails mention plan changes, and the product itself now shows up as HCP Terraform. The practical outcome is simple: many teams are being pushed to re-evaluate whether they want their Terraform automation tied to a platform whose “free” experience can change shape overnight.

This article walks through what’s actually happening, the key dates to know, a few notable January 2026 updates, and what your exit options look like if you’d rather leave Terraform Cloud behind.

The “Terraform Cloud free tier” isn’t disappearing, but the version many teams have been using is. HashiCorp has been moving Terraform Cloud (now HCP Terraform) away from the older, legacy Free plan and toward the newer enhanced Free tier.

If your organization is still on Free (Legacy), that plan is set to reach end of life on March 31, 2026, and HashiCorp says remaining organizations will be transitioned to the enhanced Free tier.

Terraform Cloud Free end date and timeline

Here are the dates that actually define the transition:

• May 16, 2023 – HashiCorp introduced the updated/enhanced Free tier measured by managed resources (up to 500).
• April 22, 2024 – Terraform Cloud renamed to HCP Terraform (same service, new name).
• Dec 17, 2025 – HashiCorp reiterated legacy Free plan EOL (March 31, 2026), described the in-product migration flow, and noted the change isn’t reversible back to legacy plan.
• January 6, 2026 – HashiCorp Support publishes an official EOL notice restating the March 31, 2026 end date and that remaining orgs will be automatically transitioned to the enhanced Free tier.
• March 31, 2026 – End of life for HCP Terraform Free (Legacy).

What’s materially changing is the shape of “free.” The legacy model was largely user-based (and historically limited free organizations to five active members), while the enhanced Free tier is usage-based: it covers up to 500 managed resources and includes unlimited users, but it also comes with operational constraints like one concurrent Terraform run.

In other words, free now scales by “how much infrastructure you manage,” not “how many teammates you invite” — which is why some teams experience this as a practical end to “free.”

One more detail that matters if you’re planning around this: HashiCorp’s guidance around the migration emphasizes that you’re moving onto a new plan model (not just re-checking a box), and that migration can’t be reversed back to Free (Legacy).

What you gain (and what you lose) on the enhanced Free tier

HashiCorp positions the enhanced Free tier as more than “just free.” It can include capabilities like SSO, policy as code, run tasks, and agents, but with tighter operational limits tied to usage.

A key gotcha: the Free tier’s policy support is constrained. For example, HCP Terraform Free includes one policy set of up to five policies, so “policy as code exists” doesn’t necessarily mean “policy as code scales” on the Free tier.

It’s also worth treating “free” as governed by fair-use/anti-abuse rules rather than a hard “unlimited” promise, meaning the practical experience can shift even without a formal pricing change.

If you’re unsure whether you’re affected, check your organization’s Plan & Billing area: orgs on the legacy plan are labeled “Free (Legacy).”

When the migration flow appears in-product, HashiCorp’s prompt typically shows your current managed-resource count, a feature comparison, and a reminder that migrating away from legacy plan types isn’t reversible back to Free (Legacy).

January wasn’t only about the Free (Legacy) sunset. HashiCorp also shipped a couple of changes that matter operationally — especially if you’re running agents or you’re trying to bring existing infrastructure under management without the usual Terraform Cloud/HCP Terraform “greenfield” workflow.

• Jan 6, 2026 – HCP Terraform Agent 1.27.0: the agent added support for Terraform Stacks component source addresses in the Terraform Registry client, which is relevant if you’re adopting Stacks and rely on agent execution.
• Jan 6, 2026 – HashiCorp↔IBM naming changes: HashiCorp published an update explaining that business operations transitioned to IBM (effective September 1, 2025) and customers will see updated product names on billing statements (with “no impact to existing features or functionality”). It also includes Terraform-related name mappings (e.g., HCP Terraform Plus → IBM Terraform Standard RUM billing statement name).
• Jan 13, 2026 — Updated “terraform import” guidance for remote state: HashiCorp refreshed its Help Center article on importing resources into a remote state managed by Terraform Cloud/HCP Terraform, emphasizing that terraform import runs locally (so it can’t use workspace variables for credentials) and walking through the cloud integration setup. 

If the Terraform Cloud / HCP Terraform free-tier changes pushed you to rethink your setup, the good news is you don’t need to “rewrite your infrastructure” to leave. 

Spacelift is a Terraform Cloud alternative that runs your existing Terraform or OpenTofu workflows as code-driven “stacks” (source + config + state), triggered from your Git repo, so the migration is mostly about moving or re-pointing your automation, not rebuilding your IaC.

The other big unlock is portability. With Spacelift, you can keep managing state in your existing backend, or (if you prefer) import it into Spacelift’s optional state backend — you’re not required to hand your state to the platform. That flexibility matters if your goal is to reduce lock-in and keep a clean exit path in the future.

A practical “move off Terraform Cloud” path looks like this:

• Pick your state approach: keep your current remote backend, or import into Spacelift during stack creation (optional).
• Create a Spacelift stack per repo/root module and connect your VCS so runs trigger on changes. 
• Port variables/secrets and credentials into stack configuration (env vars/mounted files) and validate your plan/apply flow.
• Rebuild guardrails with policy-as-code (Spacelift commonly pairs well with OPA-style policies rather than proprietary policy lock-in).
• Add drift detection once stable (available on Starter+ and requires private workers), so you catch “clickops” and unplanned changes without babysitting.

Spacelift stacks are defined as source code + state + configuration, and you can either keep your existing backend or import state into Spacelift during stack creation.

And if data residency or network access is part of the reason you’re leaving, Spacelift also supports self-hosted deployments (including guides for running on your own Kubernetes), so execution and connectivity can stay closer to your infrastructure.

If you want to learn more about what you can do with Spacelift, check out this article.

The Terraform Cloud free tier isn’t “gone,” but the legacy Free plan is ending, so many teams will feel the impact as soon as their usage no longer fits the new limits. With that uncertainty in mind, it’s a good time to treat this as a forcing function to reduce lock-in and pick an automation layer you control. 

If you’re planning an exit, don’t treat state history as “forever storage.” HashiCorp’s published limits say HCP Terraform retains at least the last 100 state versions across all workspaces (and at least the most recent state for every workspace). Additional states beyond the last 100 are retained for six months, then deleted.

If you’re ready to leave Terraform Cloud, migrating to Spacelift lets you keep your Terraform/OpenTofu code and move the workflow (plans, applies, guardrails) to a purpose-built alternative. Get started with a free trial or book a demo with our engineering team to discuss your options in more detail.