HCP Terraform's Free Tier Now Caps at 500 Resources. Move to Kevra Infra, Managed Terrakube.

On March 31, 2026, HashiCorp retired the legacy HCP Terraform free plan. Organizations still on it were moved automatically to what HashiCorp calls the enhanced Free tier, and that move cannot be undone (HashiCorp, December 17, 2025). The new tier is generous in some ways: unlimited users and SSO are included, plus a small policy as code allowance. The constraint is the number that matters most as your infrastructure grows: 500 managed resources (HashiCorp docs).

Five hundred sounds like a lot until you count. Every security group rule, IAM policy attachment, DNS record and S3 bucket setting is its own resource. A small team with a few environments and a handful of services can cross that line without shipping a single new product. Past it, HCP Terraform bills per managed resource, every hour.

This post covers three things. First, exactly what changed and how HashiCorp counts a managed resource. Second, how to estimate where you stand today. Third, your options if you are close to the cap, including hosted Terrakube: the open-source Terraform and OpenTofu automation platform, without the job of running it yourself.

What changed in HCP Terraform's free tier

HashiCorp announced the enhanced Free tier on December 17, 2025, and set the end of the legacy Free plan for March 31, 2026. A support notice published on February 27, 2026 confirmed the date and that "remaining organizations will be automatically transitioned to the enhanced Free tier" (HashiCorp support).

Here is what the Free tier gives you today, according to HashiCorp's own pages:

Sources: HashiCorp blog, HCP Terraform plans overview, checked October 9, 2026.

Two details are worth reading twice.

What counts as a managed resource. HashiCorp defines it as a resource in an HCP Terraform managed state file where mode = "managed", counted from the first plan or apply. Data sources do not count, and null resources are excluded. Everything else does, including resources created inside modules.

One run at a time. With one concurrent remote run, a plan in one workspace waits for an apply in another. For a single project that is fine. For a team pushing to several workspaces in parallel, it becomes a queue.

If you go over 500 resources, the paid plans bill per managed resource per hour, from the moment a resource is provisioned until it is destroyed, and partial hours count as full hours (HashiCorp docs). Current prices are on HashiCorp's pricing page.

How to estimate how close you are to 500

You can get an estimate from each workspace's state with Terraform (or OpenTofu) and jq. Run this in a working directory that is already initialized against the workspace:

terraform show -json \
  | jq '[.values.root_module | .. | .resources? // empty | .[]
         | select(.mode == "managed" and .type != "null_resource")]
        | length'

What it does: it walks the root module and every child module in the current state, keeps resources whose mode is managed, drops null_resource, and counts what is left. Each instance created with count or for_each counts separately. With OpenTofu, replace terraform with tofu.

Repeat it per workspace and add the numbers up, because the 500 limit applies to the whole organization, not to one workspace. If you keep one directory per workspace, loop over them:

for dir in envs/*/; do
  printf '%s ' "$dir"
  (cd "$dir" && terraform show -json \
    | jq '[.values.root_module | .. | .resources? // empty | .[]
           | select(.mode == "managed" and .type != "null_resource")]
          | length')
done

Treat the result as an estimate. HashiCorp's billing count is the one that matters, so check the usage view in HCP Terraform. The point of running it yourself is to see which workspaces carry most of the weight, which tells you where you have room to act.

Your three options

1. Stay on Free and stay under 500

This is a reasonable choice for small projects. Ways to make room:

• Destroy resources nobody uses anymore. Old preview environments are the usual suspects.
• Move rarely changing, low-risk resources out of HCP Terraform managed state.
• Collapse many small resources into fewer where the provider allows it, for example one security group with inline rules instead of one resource per rule, if that fits your style.

The trade-off: you are now designing your infrastructure code around a billing limit, and the limit does not grow with you. One concurrent run also stays one concurrent run.

2. Upgrade to a paid HCP Terraform plan

You keep everything you have, and you pay per managed resource per hour above the free allowance. For teams that rely on Sentinel or other HashiCorp-specific features, this is the least disruptive path. Model the cost with your own count from the section above and the current prices on HashiCorp's pricing page, and remember that every hour a resource exists is billed, so short-lived environments still count while they exist.

3. Move to Terrakube

Terrakube is open-source (Apache-2.0) infrastructure as code automation and collaboration software for Terraform and OpenTofu. It supports the remote backend and the cloud block, so your existing configuration points at a new hostname and the CLI workflow you know stays the same.

It is the right option if you want flat costs instead of a per-resource meter, if you are moving to OpenTofu, or if you do not want your workflow tied to one vendor's licensing decisions. If you want it without running servers, read our guide to hosted Terrakube: what it includes, what it costs and when self-hosting fits better.

What Terrakube gives you that you used in HCP Terraform

Source: Terrakube on GitHub and docs.terrakube.io, checked October 9, 2026.

One honest difference: Sentinel is HashiCorp's proprietary policy language. If you have Sentinel policies, plan time to rewrite them in OPA's Rego.

Migrating workspaces from HCP Terraform to Terrakube

Terrakube's documentation describes two paths (Terrakube migration guide).

Path A: the Workspaces Importer. You give Terrakube your Terraform Cloud API token, and it replicates "name, description, Terraform version, execution mode, variables, tags and the current state." For VCS-driven workspaces, connect your VCS provider in Terrakube first. If your workspaces use different workflow types, run the importer once for each.

Path B: the CLI, one workspace at a time. This is the path we describe here. Point the cloud block at your Terrakube hostname. On Kevra Infra, use the hostname of your instance:

terraform {
  cloud {
    hostname     = "<your-kevra-infra-hostname>"
    organization = "your-org"

    workspaces {
      name = "your-workspace"
    }
  }
}

Then log in and move the state:

terraform login <your-kevra-infra-hostname>
terraform init -migrate-state

Terraform copies the current state from HCP Terraform to Terrakube. Run terraform plan afterwards: if the migration worked, the plan shows no changes.

Before you switch anything off in HCP Terraform, recreate workspace variables (Path B does not copy them), reconnect the VCS repository, and do one full plan and apply cycle on a low-risk workspace. Kevra-specific guides are in the Kevra Infra docs.

Self-host Terrakube, or let someone run it

Terrakube is open source, so you can run it yourself. Be clear about what that means. A production Terrakube setup has several moving parts: the API, the UI, the jobs service, the executor that runs your plans and applies, the open registry for modules and providers, a relational database, cloud storage for state and outputs, and Dex for login, plus TLS, backups and upgrades (Terrakube architecture). None of it is exotic. All of it is yours to patch, monitor and restore at 2 a.m.

That is the job Kevra Infra takes off your plate. We run Terrakube for you, as a hosted service:

• Flat monthly price, no per-resource meter. Starter is USD 39 per month with 1 organization. Pro is USD 79 per month with 3 organizations and email support. Hosted in the United States.
• Terraform and OpenTofu. Push OpenTofu or Terraform code; plans and applies run on the platform.
• Hosting, upgrades and uptime are on us. You do not run the API, the executor, the database or the storage behind it.
• Same open-source Terrakube. Your state is standard Terraform state.

FAQ

Is the HCP Terraform free tier gone?

No. The legacy Free plan ended on March 31, 2026. The current Free tier still exists, with up to 500 managed resources, unlimited users and one concurrent run (HashiCorp).

Can I go back to the legacy free plan?

No. HashiCorp states that the move to the enhanced Free tier "is not reversible back to older legacy plan types."

Do data sources count toward the 500?

No. Only resources with mode = "managed" count, and null resources are excluded.

Does Terrakube work with OpenTofu?

Yes. Terrakube runs the Terraform or OpenTofu workflow (Terrakube on GitHub).

Can I keep my existing state files?

Yes. Both the Workspaces Importer and terraform init -migrate-state move your current state into Terrakube.