HCP Terraform free tier is gone. What a private registry costs now

On 31 March 2026, HashiCorp retired the legacy free plan for HCP Terraform. If you had an old free organisation, you have been moved to the new free tier, which caps at 500 managed resources. Above that you are into pay-as-you-go, billed on Resources Under Management: roughly $0.10 per resource per month on Essentials, $0.47 on Standard, and $0.99 on Premium, charged on your peak hourly resource count.

I want to work the maths honestly, because the number that matters is not the headline rate. It is what "a resource" means when the meter is running, and how quickly a normal estate crosses the free line. Then I will lay out the five ways out and price each one fairly, including the ones that are not us.

All figures below are illustrative and use the mid-2026 published rates. Check the current numbers against HashiCorp's own pricing and cost-estimation docs before you make a decision, links at the bottom.

What actually counts as a resource

A Resource Under Management is any resource in a Terraform-managed state file with mode = "managed". The count starts at the first plan or apply and runs per hour until the resource is destroyed. Partial hours bill as full hours.

The part that surprises people is the granularity. This is one aws_security_group:

resource "aws_security_group" "web" {
  name = "web"

  dynamic "ingress" {
    for_each = var.rules   # 9 rules
    content {
      from_port   = ingress.value.port
      to_port     = ingress.value.port
      protocol    = "tcp"
      cidr_blocks = ingress.value.cidrs
    }
  }
}

To RUM it is not one resource. Depending on how the provider expands the rules, a security group with nine rules can count as ten billable resources. You did not get ten times the value. You get ten times the line item. Multiply that pattern across VPCs, subnets, IAM policies, and everything provisioned by count and for_each, and the meter moves faster than your mental model of "how much infrastructure do we have".

Two things make forecasting harder than the old per-user pricing. First, the count is granular in the way above. Second, billing is on the hourly peak, so a deployment that briefly doubles your resource count to cut over blue-green inflates the bill for that hour even after the old resources are destroyed.

The worked example

Take a mid-sized platform team. Say 2,000 managed resources steady state, the kind of number a handful of production accounts reaches without anyone thinking they run a lot of infrastructure.

Tier	Rate / resource / month	2,000 resources	5,000 resources
Free	0 (max 500)	not available	not available
Essentials	~$0.10	~$200 / mo	~$500 / mo
Standard	~$0.47	~$940 / mo	~$2,350 / mo
Premium	~$0.99	~$1,980 / mo	~$4,950 / mo

You are on Standard or Premium the moment you want a sensible number of concurrent runs or policy sets, so the realistic column for a lot of teams is the $940 to $4,950 a month band, before any peak-hour spikes. None of that is outrageous for what a full execution platform does. The question is whether module and provider distribution, the thing you may actually be reaching for, should be priced off your total resource count at all.

The five ways out

Here is the honest menu. I have tried to price each one the way I would want a vendor to price it for me, which means naming where each one is the right answer even when it is not us.

1. Stay under the cap

If your managed-resource count genuinely sits under 500, the free tier is fine and you should use it. It gives you state, VCS integration, variable sets, unlimited users, and one policy set. It is tight for production but real for small teams and side projects. Do not over-engineer an escape from a bill you do not have.

Choose this if you are under 500 resources and expect to stay there.

2. State only, to S3

If what you use HCP for is really just remote state and locking, you do not need a platform for that. The standard http state backend, or S3 with a DynamoDB lock table, costs cents. You give up the run UI, run queue, and policy, and you keep your state for the price of a bucket.

Choose this if you drive plan and apply from your own CI already and only want somewhere safe to put state.

3. A TACOS (Spacelift, Scalr, env0)

If you want a platform to own execution, run queues, drift detection, and policy-as-code, buy one. These are good products and the registry comes bundled. Pricing is usually per-run or per-user rather than per-resource, which for many estates works out kinder than RUM, and Scalr in particular has leaned into being the RUM-refugee destination. This is a genuine recommendation, not a throat-clear.

Choose this if your CI/CD is weak, or you want one place that owns applies, approvals, and drift.

4. OSS self-hosted registry

If the problem is specifically module and provider distribution and your budget is zero, the open-source field is real: Terrareg, Terralist, Terrakube's registry component, and others. You trade money for maintenance and ops capacity. Some are modules-only, some do providers too, and their health varies, so check the project's recent activity before you commit.

Choose this if budget is zero and you have the ops capacity to run and patch it yourself.

5. A registry product (this is us)

If you want module and provider distribution, state hosting, supply-chain scanning, and a dependency graph across your estate, without paying for a full execution platform or running OSS yourself, that is the gap Terramantle fills. It is priced as a registry, not off your resource count, it runs self-hosted or cloud, and it works fully air-gapped. Deliberately, it does not run your Terraform, so your existing pipelines and credentials stay exactly where they are.

Choose this if distribution and lifecycle visibility are the actual problem, and you want to keep execution in your own pipelines.

A migration sketch

Whichever way you go, the move off HCP is smaller than it looks if you separate the pieces:

State. Pull each workspace's state from HCP and push it to your new backend (S3, or a registry product's state layer). This is a terraform state pull / push per workspace.
Modules. Republish your private modules to wherever they now live, and change the source address from app.terraform.io/... to the new host. Version constraints keep working because the registry protocol is the same one your CLI already speaks.
CI. Switch publishing and state auth to OIDC so there are no long-lived tokens to carry over.

The registry protocol being identical across Terraform and OpenTofu is what makes step 2 cheap. You are changing a hostname, not rewriting your modules.

The honest summary

RUM is not a scandal. It is a resource-metered price for a full execution platform, and if you want that platform it can be worth it. The trap is paying resource-metered execution pricing when the thing you actually needed was a place to distribute and govern modules. If that is you, price the registry as a registry and keep your pipelines.

If you run OpenTofu specifically, the private OpenTofu registry page covers how this looks under tofu, and if the sticking point is not wanting an agent in your network, no runners, no agents is the argument for keeping execution yourself.

Sources for the pricing figures, verify current rates before deciding: HCP Terraform cost estimation, Scalr on the free-tier change, Spacelift's 2026 pricing overview.