Terraform Cloud Pricing Revealed

As of July 2026, HCP Terraform (the product formerly called Terraform Cloud) bills per managed resource per month: $0.10 on Essentials, $0.47 on Standard, $0.99 on Premium, with the first 500 resources free and self-hosted Terraform Enterprise quote-based. The meter is resource count, not how often you deploy, so the bill grows with your estate even when nothing changes. That's what sends most people to this page. Below: the tier table, what each tier gates, how Scalr's per-run and Spacelift's per-worker models come out on the same three workloads, and a short table for picking between them.

How Much Does Terraform Cloud Cost in 2026?

The published rates, per HashiCorp's pricing page as of July 2026:

The headline unit is per resource per month, but the meter is hourly under the hood: about $0.0001359 per resource-hour on Essentials, billed on the peak number of managed resources in a given hour, partial hours rounded up. A resource that lives for a week bills for a week. Test and dev resources count the same as production.

At the published starting rates, 1,000 resources cost about $100/month on Essentials or $470/month on Standard. 5,000 resources cost about $500 or $2,350. 10,000 cost about $1,000 or $4,700. Feature gating matters here: if you need audit trails or drift detection you're on Standard, and the whole estate is billed at the Standard rate.

Two things people get wrong about these tiers. Concurrency is fixed per edition and agents don't raise it; HashiCorp's support KB publishes Free = 1 and Standard = 3, and the Essentials and Premium integers aren't published. And SSO isn't a paid upgrade: HCP Terraform ships SAML on every tier including Free, and what starts at Essentials is mapping identity-provider groups onto teams. The tier-by-tier gating is in Terraform Cloud pricing and tiers explained.

If you want to price your own workload on a per-run model first, the Scalr pricing calculator takes about a minute, and the Scalr vs Terraform Cloud pricing breakdown sets the two meters side by side tier for tier.

Is Terraform Cloud Worth It in 2026?

Yes if you sit under the 500-resource Free tier, or if your governance depends on Sentinel and Vault. Beyond that, it comes down to your resource-to-run ratio. As of July 2026, HCP Terraform bills per managed resource, from $0.10 to $0.99 per resource per month by tier, and audit trails and drift detection start at Standard. A bill that grows with inventory rather than usage, or concurrency caps that queue your team, is the signal to price alternatives. The renew-or-switch guide covers that decision; the rest of this page prices it.

How Do Terraform Cloud, Scalr, Spacelift, env0, and OpenTofu Differ?

The market splits into platforms built around the Terraform object model (Terraform Cloud, Scalr), multi-IaC platforms that also run Pulumi, CloudFormation, and Ansible (Spacelift, env0, Terrateam), general CI systems you can bend to the job (GitHub Actions, GitLab CI, Jenkins), and open-source self-hosted tools (Atlantis, Digger). OpenTofu is the engine, not a platform: every platform below except Terraform Cloud runs it natively.

Terraform Cloud is HashiCorp's managed SaaS, owned by IBM since October 2024. It's the default for a reason: managed state with locking, deep ties to Sentinel and Vault, and solid VCS integration. The limits show up at scale. RUM pricing climbs with inventory, the Standard tier caps you at 3 concurrent runs, state can only live in the TFC backend, RBAC is a handful of system roles, and there's no native OpenTofu or Terragrunt support.

Scalr is built on the same remote operations backend model as TFC, which is why the CLI workflow carries over unchanged. The control plane is SaaS and runs execute either on Scalr's managed pool or on agents in your own infrastructure. The differences from TFC are where state can live (any backend Terraform supports, so S3, Azure Blob, or GCS in your account), the account → environment → workspace hierarchy for sharing credentials, modules, and policies, 147 granular RBAC permissions instead of system roles, native OpenTofu and Terragrunt support (Scalr is a founding member of the OpenTofu project), OPA checks before and after plan with impact analysis before a policy merges, and the reporting layer: run metrics, resource inventory, module and provider usage, workspace staleness, token lifecycle. It bills per qualifying run, and drift runs are free. It runs Terraform and OpenTofu only.

Spacelift treats IaC as a CI/CD problem. It runs Terraform, OpenTofu, Pulumi, CloudFormation, and Ansible from one interface, has a strong OPA engine and stack dependencies for orchestrated deployments, and ships Saturnhead AI for failure diagnosis. It's pull-request driven and doesn't support the Terraform CLI workflow or no-code provisioning, so a team that lives in terraform apply will feel the change. It's also more to set up and operate than TFC or Scalr, and it prices by concurrent worker, which has a structural problem covered in the pricing section below. If Spacelift is your leading candidate, the Spacelift alternatives comparison goes deeper on its tier gates.

env0 leans into FinOps and developer self-service: cost estimation in PR comments, estimated-versus-actual cost tracking, template-based provisioning with guardrails for non-experts, OPA support, and unlimited concurrency on every plan. It's multi-IaC like Spacelift. Its pricing is quote-based and billed per successful apply or environment, and its ecosystem is smaller than Spacelift's or Scalr's.

OpenTofu is the Linux Foundation fork of Terraform under MPL 2.0, a drop-in replacement for Terraform below 1.6 with identical HCL. It needs a management platform to give you what TFC gives you end to end. Scalr, Spacelift, and env0 all run it natively.

How Do the Platforms Compare Feature by Feature?

How Much Do These Platforms Actually Cost?

Three different meters. Terraform Cloud charges for what you own, Scalr for what you do, Spacelift for how many things you can do at once. Which one favours you depends on your resource-to-run ratio.

Scalr: per run

Scalr's Free plan covers 50 qualifying runs a month with community support. Business starts at $99/month for 100 runs (about $0.99 a run) with volume discounts as run volume grows; the live calculator is at scalr.com/pricing. Enterprise is custom-priced and adds controls over data location, encryption keys, identity, and audit trail, plus higher dedicated CPU and memory resources and enterprise contracts. Free and Business share the core feature set.

There are no per-user or per-resource fees. Drift runs, policy-failed runs, and failed init runs aren't billed. Concurrency isn't a line item either. As of September 2026 Scalr's pricing FAQ gives new accounts five concurrent runs by default on the Scalr-managed runner pool, raised free of charge on request with a valid use case, and each self-hosted agent adds five more at no platform cost. That per-agent ratio is there to keep execution reliable, not to meter anything.

Spacelift: per concurrent worker

As of July 2026, per Spacelift's pricing page: Free gives you 2 users and 1 public worker. Starter+, the entry paid tier, is $20,000/year with unlimited users, 2 public workers, and 1 private worker (a second is available). Business and above are quote-based and sized by private worker count (Business 3, Enterprise from 5). A worker processes one run at a time, so worker count is your maximum concurrency, and there's no published per-worker price.

The invoice is flat for the contract, which is the model's selling point. The structural problem is that a fixed slot count is always the wrong number. Buy too few and engineers queue during releases. Buy too many and you rent idle capacity. Capacity planning that the vendor should be doing lands on you: forecast peaks, watch utilisation, go through procurement when you need one more slot, and that one more slot can push you into the next bracket. It bites hardest during an incident, when parallel fixes across many workspaces queue behind the cap and the bottleneck in recovery becomes a purchase order. Per-run pricing avoids all of that: one more run costs one more run. The longer version is in How to evaluate IaC platform pricing models. And if you're staring at a queued run right now, check which queue it is, because the CLI prints one message for a workspace queue and a near-identical one for an organization limit, and only the second is about capacity you can buy.

env0: per apply or environment

As of August 2026, per env0's pricing page: a free tier at $0 in perpetuity with 250 runs/month, up to 30 active environments, unlimited users, agents, and concurrency, and community support (launched August 5, 2026). Cloud Navigator is quote-based, billed per successful apply or environment, up to 100 active environments. Cloud Pilot uses the same billing unit with unlimited environments and adds Cloud Analyst, advanced drift analysis, cost management, and self-hosted agents. The $1,500/month Cloud Compass tier is no longer listed.

Three workloads, three bills

All figures use the published starting rates as of July 2026.

At the small end it's a tie, and the real question is which free-tier cap you hit first: resources, runs, or users and workers. In the middle it's Scalr or HCP Essentials depending on whether you need Standard's features, with the difference that Scalr's bill stays flat as the resource count grows and HCP's doesn't. At the top, Scalr is the only one of the three with a published price, and it tracks run volume rather than estate size.

Platform fees aren't the whole cost. Migrating TFC to Scalr has a free migration period and an automated script; TFC to Spacelift has a Python script and no free period. Ongoing operations are lowest on TFC and Scalr (managed, or minimal agent management), medium on Spacelift (workers and database), and highest self-hosted. The learning curve runs the same way: near zero moving TFC to Scalr, medium for Spacelift's CI/CD model, high if you own the whole stack.

What Are Your Self-Hosted and Open-Source Options?

Scalr with self-hosted agents is the hybrid option: Scalr runs the control plane, you run the agents. Agents pull code from your VCS and execute runs inside your network, so cloud credentials are injected only at runtime on the agent and never reach the SaaS side, and with VCS Agents even code retrieval stays internal. The cost is that you run, patch, and scale the agents yourself, and they need outbound access to the Scalr control plane.

Atlantis is the original open-source Terraform automation tool: one binary that listens for pull request comments and runs plan and apply. It's simple to deploy and free, and it's fine for a small team or a proof of concept. It's single-threaded, all credentials sit on one server, drift detection is limited, and development has slowed. Teams tend to outgrow it within a year or two.

Digger is a stateless orchestrator that listens for PR comments and triggers jobs in your existing CI (GitHub Actions, GitLab CI). Credentials stay in the CI environment, scaling comes from the CI platform, and there's no central server to protect. The trade is a smaller ecosystem and fewer advanced features, and you need a CI platform to begin with.

Terrateam takes the orchestrator pattern further with a Postgres-backed server that's horizontally scalable, adds HA and RBAC, and runs Terraform, Pulumi, and Terragrunt. It needs a database and more setup than Digger, and the community is younger.

Can You Just Build Your Own Pipeline in GitHub Actions?

The first version looks like this, and it takes ten minutes:

name: Terraform Plan
on:
  pull_request:
jobs:
  terraform:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: hashicorp/setup-terraform@v3
      - name: Configure AWS
        uses: aws-actions/configure-aws-credentials@v4
      - name: Terraform Plan
        run: terraform init && terraform plan -no-color

Then week one you want the plan posted to the PR. Week two you have three environments and two AWS accounts. Week three you need approvals and status checks. By month two you're implementing state locking with S3 and DynamoDB, passing plan artifacts between jobs, and untangling concurrent runs that stepped on each other. By month three it's policy enforcement, cost estimation, and drift detection, and by month six someone notices you're rebuilding Terraform Cloud in YAML.

DIY Actions is reasonable for one person, one environment, or as a way to learn. Past two or three people or two environments, pair Actions with Digger or Terrateam and let them own the orchestration, or use a dedicated platform.

How Do You Actually Migrate Off Terraform Cloud?

The decision and migration guide covers the stay-or-go call and the full mechanics. The short version:

Before you start, count workspaces, calculate monthly run volume, document variables, VCS integrations, policies (Sentinel or OPA), and approval workflows, and work out your current TFC spend in resource-hours so you compare like with like.

To Scalr, both platforms are remote operations backends, so the workflow carries over. Setup is a day or two: create the account, connect VCS, configure cloud credentials, and optionally request the free migration period. Scalr's TFC migration script then moves organizations to environments, workspaces to workspaces, variables, and state, and validates the result; run test applies on non-critical workspaces. Spend three to seven days testing: drift detection on migrated workspaces, applies on dev, PR workflows, approval chains, and policies (Sentinel doesn't translate to OPA one to one, so plan for a rewrite). Cut critical workspaces over in a maintenance window with a rollback plan (a state push back to TFC), then cancel TFC, archive the old workspaces, pull TFC credentials out of CI, and update docs. A team with 1–10 workspaces usually finishes in 1–2 days; plan 1–2 weeks for 10–100 workspaces and 2–4 weeks for 100+.

To Spacelift, budget more, because you're moving to a stack model. Planning takes three to five days (stack hierarchy and dependencies, Sentinel to OPA, worker configuration). The Python migration script moves workspaces to stacks with their variables and state in a day or two. Then one to two weeks configuring stack dependencies, policies, and integrations, one to two weeks testing on non-critical stacks, and a week of production cutover and training. Small teams take 2–3 weeks, medium 4–8 weeks, large enterprises 2–3 months.

Whichever you pick: all platforms support terraform state pull and push, state is locked during transfer, verify integrity afterward and keep a backup for 30 days. You'll reconnect each VCS provider (often new OAuth tokens and webhook URLs) and should test PR automation and branch protection before trusting them. Plan an hour or two of training for Scalr and more for Spacelift.

Which Platform Is Right for Your Team?

If a contract renewal is what brought you here, the 2026 Terraform Cloud renewal decision guide weighs renewing, renegotiating, migrating, and moving to open source before you sign. A reasonable four-week path for a TFC team: assess against the table above, take a Scalr trial and run a proof of concept on non-critical workspaces, build the cost case, then plan the migration with the team.

What Else Do Teams Ask Before Switching?

What happens to our Sentinel policies? Sentinel is HashiCorp-specific. Scalr and Spacelift use Open Policy Agent, so policies get rewritten rather than ported. Both platforms publish examples, and Scalr shows a policy's impact across existing workspaces before you merge it.

Do we have to change our Terraform code to use Scalr? No. Same terraform binary, same HCL. The backend block changes, and the migration script handles that.

Can Scalr keep state in our own S3 bucket? Yes. Any backend Terraform supports (S3, Azure Blob, GCS, HTTP) works; state lives in your backend while the run executes in Scalr. Terraform Cloud only uses its own backend.

Where do our code and credentials go? Code stays in your VCS. Credentials are injected into agents at runtime and never touch the SaaS control plane. With VCS Agents, code retrieval also happens inside your network, so your VCS never has to be reachable from the internet.

Does Scalr support SCIM? Yes, for Okta and Microsoft Entra ID, on the Enterprise plan. Users are added and removed from your identity provider, which is what prevents orphaned accounts.

How does Scalr's hierarchy work? Three scopes. Account holds organization-wide settings, shared credentials, modules, and policies. Environment is the project or team scope, roughly a TFC organization, and inherits from account. Workspace is one infrastructure project and inherits from environment. Set a thing once at the highest scope that makes sense and every workspace below it gets it.

What's the difference between pre-plan and post-plan OPA checks? Pre-plan checks run before the plan exists and can reject a run on source, author, or branch, so the plan never runs. Post-plan checks inspect the plan and enforce what changes are allowed: which resources, what cost. You want both.

What if we want to leave Scalr later? Scalr is a standard remote operations backend, so you move back to Terraform Cloud, Terraform Enterprise, or any other backend with terraform state pull and push.

Pricing and feature claims re-verified against vendor pages on July 21, 2026 (env0 on August 27, 2026). Pricing changes; check the vendor's page before you sign anything.