If you logged into HCP Terraform sometime this spring and noticed your free plan suddenly behaving differently, you’re not imagining it. HashiCorp ended the legacy free plan on March 31, 2026, and every org still sitting on it got force-migrated to the “enhanced” Free tier. The new free experience caps you at 500 managed resources and one concurrent run. That’s plenty for a tutorial. It is not plenty for a real EKS cluster plus its VPC, security groups, IAM, and the dozen other resources that come along for the ride.
So a lot of teams are now shopping for somewhere else to run plans and store state. I’ve been through this evaluation a couple of times now, and the short version is: the right answer depends almost entirely on your team size and how much ops work you’re willing to absorb. Let me walk through what actually changed, the one thing you should do before anything else, and how the real contenders stack up.
What actually changed
The legacy free plan was user-based — historically it limited free orgs to five active members, and that was the main wall people hit. The enhanced Free tier flips the model. Now you get unlimited users but a hard ceiling of 500 managed resources, plus a single concurrent run. (HashiCorp’s own post frames this as a generosity upgrade, and for tiny setups it genuinely is.)
The catch is how fast 500 resources disappears. A managed resource is anything in your state that Terraform tracks — not just the EC2 instances you think about, but every subnet, route table, IAM policy attachment, and CloudWatch alarm. A single moderately complex environment can blow past 500 on its own. Once you do, you’re looking at the Standard tier, which is consumption-priced per resource per hour.
One more thing worth knowing: the migration to the enhanced tier can’t be reversed back to legacy Free. There’s no undo button here.
Before you touch anything: pull your state
This is the part people skip and regret. Workspace deletion in HCP Terraform is unrecoverable. If you’re planning to leave — or even if you’re just nervous about the transition — export your state files first.
For each workspace, you can pull state with the API or the CLI. The simplest path if your workspace is wired to a local config is:
terraform state pull > backup-$(date +%F).tfstateIf you’ve got dozens of workspaces, script it against the HCP Terraform API using your workspace IDs and a token, and drop each state file somewhere durable like a versioned S3 bucket. Do this before you start pointing your backend somewhere new. State is the one artifact you can’t regenerate — everything else (your config, your modules) lives in Git, but a lost state file means reconciling reality by hand.
Verify the backups open and parse before you trust them. A zero-byte file because your token lacked permissions is the kind of thing you discover at exactly the wrong moment.
The decision tree
There are really three roads out of here:
Stay on enhanced Free if you’re a solo dev or a homelab and you can live under 500 resources with one run at a time. No migration, no new bills. Honestly, for a lot of personal projects this is fine and you should just stay put.
Move to a hosted TACOS (Terraform Automation & Collaboration Software — Spacelift, Scalr, env0 and friends) if you want the managed run/state experience without operating it yourself, and you have a budget. This is the closest thing to a drop-in replacement.
Go fully self-hosted with Atlantis or OpenTofu plus your own CI if you’d rather trade money for control and you have the ops muscle to run it. Free at the license level, not free in your time.
The hosted options are where most teams land, so start there.
Hosted TACOS, compared
The thing nobody tells you up front is that these vendors don’t price the same way, and the pricing model matters more than the feature checklist. A platform that’s cheap for a 3-person team with huge infra can be brutal for a 30-person team with modest infra, and vice versa.
Spacelift
Spacelift prices primarily on managed resources, with concurrency as a paid lever on top. Paid plans start around $250–$399/month depending on which source and tier you look at, and you pay for how many jobs can run simultaneously. (Spacelift’s pricing page lists a free-forever plan capped at 2 users, 1 concurrency, and 50 runs/month — which, notably, is more generous than HCP’s old legacy free in some dimensions and includes drift detection, OPA policy, audit logs, and custom hooks.)
The resource-based model makes Spacelift cost-effective when you have a big infrastructure footprint but a small team. It’s the inverse of what bites you if your infra is small but your run volume is high. Spacelift’s policy-as-code is built on Open Policy Agent, which is a real plus if your team already speaks Rego or wants portable policies.
Scalr
Scalr positions itself as the closest drop-in replacement for Terraform Cloud, and its pricing is the one I find easiest to reason about. It’s run-based: the free tier includes 50 monthly runs with access to all features, and additional runs are $0.99 each with volume discounts kicking in automatically at higher usage. (Scalr publishes its pricing openly, which I appreciate — no “contact sales” gate.)
Crucially, Scalr doesn’t charge for concurrency. The managed runner pool starts at 2 concurrent runs on Free, 5 on Business, 10 on Enterprise, and scales free of charge on request. You can also deploy unlimited self-hosted agents, each adding 5 concurrent runs at no extra cost. If predictable per-run math and concurrency-without-a-paywall matter to you, Scalr is hard to beat.
env0
env0 leans on a per-environment and per-apply model, with plans commonly reported starting around $349/month and current list prices quote-based. The pitch is environments-as-a-product: it’s strong on ephemeral environments, cost visibility, and TTL-based teardown. env0 also places no limit on concurrent runs in your org, which is a nice match if you have bursty CI.
Where env0 gets fuzzy is exact pricing — you’ll likely end up talking to sales for anything beyond the entry plan, which is the opposite of Scalr’s approach.
A rough way to choose between the three: small team, big infra → Spacelift; want TFC parity and transparent per-run cost → Scalr; environments-centric workflow with lots of ephemeral stacks → env0. None of them are wrong; they’re just optimized for different shapes of pain.
The self-hosted paths
If the idea of swapping one SaaS bill for another doesn’t sit right, you’ve got options that cost nothing to license.
Atlantis
Atlantis is the veteran here. It’s a PR-driven workflow: open a pull request, Atlantis runs terraform plan and posts the output as a comment, and you atlantis apply from the PR once it’s approved. It’s free, open source, and battle-tested at serious scale.
The cost is that you run it. That means a server (or container) with network access to your cloud, credential management, upgrades, and high-availability if you can’t tolerate it being down during an incident. Atlantis also doesn’t give you the polished drift detection, RBAC, and policy dashboards that the hosted TACOS bundle in — you assemble that yourself. For a team that already lives in GitHub and has someone comfortable operating a service, it’s a great fit. For a team that wanted to stop operating infrastructure tooling, it’s a step backward.
OpenTofu + your own CI
The other self-hosted route is OpenTofu running inside GitHub Actions, GitLab CI, or whatever pipeline you already have. You write the plan/apply steps yourself, store state in an S3/GCS backend with locking, and gate applies behind your existing review process.
OpenTofu has one feature that makes this genuinely nicer than rolling the same thing with classic Terraform: state encryption is built in. You can encrypt state and plan files at rest with a key from AWS KMS, GCP KMS, or a passphrase, configured right in the backend block. With stock Terraform, state encryption is something you bolt on at the storage layer; OpenTofu treats it as a first-class concern. If you’re putting state in your own bucket, that’s reassuring.
The trade-off is the same as Atlantis, minus the prebuilt PR integration: you own every line of the pipeline. There’s no drift dashboard unless you schedule a plan job and parse the output yourself.
OpenTofu vs staying on Terraform
Since you’re already moving, it’s a natural moment to ask whether to jump to OpenTofu entirely. A few honest points:
Module compatibility is excellent — OpenTofu forked from Terraform and stays close to it, so the vast majority of existing modules and providers just work. The registry has a mirror, so you’re not stranded for providers.
The licensing angle is the headline reason people switch. Terraform moved to the Business Source License (BSL); OpenTofu is under the MPL and governed by the Linux Foundation. If your org is allergic to BSL terms, or you just want a community-governed tool, OpenTofu removes that question. The state encryption feature is a concrete technical win on top of the licensing comfort.
The counterpoint: if you’re paying for a hosted TACOS anyway, the licensing difference matters less, and some teams prefer to stay on the tool HashiCorp ships. There’s no wrong answer — just be deliberate rather than switching on vibes.
A migration playbook by team size
Here’s how I’d actually decide, depending on who you are.
Solo dev or homelab. Stay on enhanced Free if you fit under 500 resources. If you don’t, go OpenTofu + GitHub Actions with an S3 backend and state encryption. You don’t need a platform; you need a working plan on PR and an apply on merge. Total cost: whatever your bucket costs, which is roughly nothing.
5-engineer startup. This is the sweet spot for Scalr or Spacelift’s lower tiers. The 50 free runs on Scalr or the entry Cloud plan on Spacelift will likely cover you, and you get drift detection, policy, and audit logs without building them. The few hundred dollars a month buys back real engineering time you’d otherwise spend babysitting Atlantis. Pick Scalr if you want predictable per-run billing, Spacelift if your infra footprint is large relative to your headcount.
50+ engineer platform team. Now concurrency, RBAC, policy-as-code, and self-hosted runners stop being nice-to-haves. Evaluate Spacelift and env0 seriously against Scalr, and weigh self-hosted agents (Scalr’s free concurrency-per-agent model is attractive at scale). If you have a platform team that wants to own the stack, Atlantis or OpenTofu + CI with a real CD platform behind it is viable — but price it in engineer-hours, not just licenses.
The migration mechanics are the same across all of these: export state, stand up the new backend, import or migrate state into it, run a plan to confirm zero diff, then cut over your pipelines. The zero-diff plan is your proof the migration worked. If that plan wants to destroy and recreate half your infra, stop and figure out why before you apply anything.
One thing to try this week, even if you’re not migrating yet: go pull and back up your HCP Terraform state files. It costs you ten minutes and removes the single scariest failure mode from the whole transition.
Sources: