Pricing is often the trigger for teams to start questioning Terraform Cloud.They run the math on their managed resources, factor in the security group rules and IAM policies that nobody has changed in 18 months, and realize they're paying for infrastructure that is simply sitting there. Under the RUM model, those resources bill the same whether they're changing daily or dormant.
The December 2025 free-tier end-of-life email accelerated the questioning for many teams, but the bills are rarely the central issue. That is usually scope. Terraform Cloud was designed for Terraform, but If your stack has grown to include OpenTofu, Pulumi, CloudFormation, or Kubernetes manifests, you're now running multiple tools to manage infrastructure that a single platform should handle. The bills simply crystallize the doubts many teams have over more fundamental shortcomings. Here’s what you should consider when selecting an alternative:
Know what you're actually replacing
Before evaluating alternatives, it helps to be honest about which features you actually use.
Terraform Cloud offers remote state with locking, VCS-driven plan and apply, policy enforcement via Sentinel and OPA, secrets management, and RBAC. That's a meaningful bundle, but most teams use a subset of it.
If your main use case is "remote backend with a UI," a generic CI system plus a managed state backend may be all you need. If you depend on governance, multi-team approvals, and policy enforcement, you need a platform that can carry those capabilities, Otherwise, you'll have to rebuild them yourself after the migration.
The mistake teams make is replacing the billing without replacing the capabilities. They move to GitHub Actions, discover they've lost drift detection, and spend the next six months writing YAML to approximate what they had.
Be aware of the alternative categories
Terraform Cloud alternatives fall into three broad buckets.
Dedicated IaC orchestration platforms (Spacelift, env zero, Scalr, Pulumi Cloud) are purpose-built for managing infrastructure workflows. They come with state management, policy as code, drift detection, and self-service patterns out of the box. You trade platform lock-in for operational completeness.
Generic CI/CD systems (GitHub Actions, GitLab CI/CD, CircleCI) can run terraform plan and terraform apply alongside your application pipelines. They're fast to set up if your team already uses them. The gap is everything beyond execution: you configure state, build policy checks, and wire up drift detection yourself.
Self-hosted open-source PR automation (Atlantis) gives you a GitOps-driven Terraform workflow at no license cost. You absorb the operational overhead of running and maintaining the service. Free to use; not free to run.
Investigate your eight options
1. Spacelift
Spacelift is an infrastructure orchestration platform that manages Terraform, OpenTofu, Terragrunt, Pulumi, CloudFormation, Kubernetes, and Ansible from a single control plane. OPA-based policies apply across plan, apply, push, approval, and notification decision points — not just at plan time.
To make that concrete, here's a plan policy that restricts which EC2 instance types your team can deploy:
package spacelift
approved_types := {"t3.small", "t3.medium", "m6i.large", "m6i.xlarge"}
deny contains sprintf("EC2 instance type %s is not on the approved list", [resource.address]) if {
some resource in input.terraform.resource_changes
resource.type == "aws_instance"
some action in resource.change.actions
action in {"create", "update"}
not approved_types[resource.change.after.instance_type]
}
The policy reads the Terraform plan, checks every aws_instance being created or updated, and blocks the run if the instance type isn't on the approved list. The same Rego-based approach extends to approval policies (require two reviewers on production stacks) and push policies (decide which branches trigger runs).
Pricing is plan-based with no RUM billing, starting at $399/month. Self-hosted workers are available at all paid tiers for teams with air-gapped or on-premises requirements.
Spacelift Intelligence adds AI-powered provisioning via natural language and automated diagnostics, running inside the same policy and audit model as the rest of the platform.
Best for: Platform engineering teams managing multi-IaC environments who need governance, self-service infrastructure, and enterprise-grade policy enforcement in one platform.
Not the right fit if: You only need a state backend, you're Terraform-only with no compliance pressure, or you have a significant Sentinel investment with no appetite to port to Rego
2. Pulumi Cloud
Pulumi Cloud is the managed backend for Pulumi's infrastructure-as-code framework, where engineers define infrastructure in TypeScript, Python, Go, C#, or Java rather than HCL.
The notable differentiator is the Automation API: a programmatic interface that embeds Pulumi deployments inside application code, which is useful for self-service portals that need to provision environments on demand.
As of May 2026, Terraform state management in Pulumi Cloud is in public preview. Resources stored there count toward Pulumi's credit-based billing the same way Pulumi-managed resources do — so the RUM model doesn't disappear, it just changes vendor.
Best for: Teams already writing TypeScript, Python, or Go who want to apply software engineering practices to infrastructure.
Not the right fit if: Your team is committed to HCL workflows or you're trying to escape resource-based billing.
3. GitHub Actions
GitHub Actions is the most common first stop for teams leaving Terraform Cloud, and for obvious reasons: if your code already lives in GitHub, there's no new vendor, no migration of access controls, and a large marketplace of reusable Actions.
A minimal plan-on-PR workflow looks like this:
name: terraform-plan
on: pull_request
permissions:
id-token: write
contents: read
jobs:
plan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v6
- uses: aws-actions/configure-aws-credentials@v4
with:
role-to-assume: arn:aws:iam::123456789012:role/terraform-ci
aws-region: us-east-1
- uses: hashicorp/setup-terraform@v3
with:
terraform_version: 1.9.8
- run: terraform init && terraform plan -no-color
The gap shows up quickly: no managed state, no drift detection, no native policy enforcement. You configure an S3 backend yourself, build governance in YAML, and discover that "low overhead" meant low overhead to start, not to maintain.
Best for: Small teams on GitHub who need simple Terraform automation without a second platform.
Not the right fit if: You need managed state with locking, drift detection, or policy enforcement without building it yourself.
4. GitLab CI/CD
GitLab CI/CD's main advantage over GitHub Actions for Terraform users is the built-in HTTP state backend with encryption, locking, and versioning tied to project permissions. That removes the day-one task of configuring a separate S3 bucket and DynamoDB table.
One migration note worth flagging: the official Terraform CI/CD templates (Terraform/Base.gitlab-ci.yml) were deprecated after HashiCorp's license change and removed in GitLab 18.0. If your pipelines still reference them, migrate to the GitLab OpenTofu CI/CD component, which is the path GitLab now recommends.
Best for: Teams already on GitLab who want a single-vendor DevSecOps platform with native state management.
Not the right fit if: You need infrastructure governance beyond what a general-purpose pipeline can provide.
5. CircleCI
CircleCI fits when it's already the CI system of record and introducing a second platform isn't on the table. Reusable orbs handle Terraform workflow setup, and CircleCI's SOC 2 Type II and FedRAMP Tailored designation makes it viable for regulated industries where CI/CD certification matters.
The same limitations apply as any generic CI tool: no native understanding of Terraform state, plan review, drift detection, or policy enforcement.
Best for: Teams already on CircleCI who want to extend application pipelines to include Terraform, or organizations in regulated sectors needing FedRAMP-authorized CI/CD.
Not the right fit if: Infrastructure governance is the priority.
6. env zero
env zero covers Terraform, OpenTofu, Terragrunt, Pulumi, CloudFormation, Helm, and Kubernetes from one platform, with OPA-based policies, cost estimation via Infracost, and a self-service portal for non-technical teams.
The pricing model is flat-fee rather than per-resource, starting at $1,500/month — which removes the RUM unpredictability but sets a higher floor than alternatives.
A notable gap: env zero’s cloud-account scanning currently covers AWS only, so multi-cloud shops still need a separate inventory source for Azure and Google Cloud.
Best for: Platform teams that need FinOps controls alongside IaC governance, particularly where multiple business units share cloud infrastructure and need per-team cost visibility.
Not the right fit if: You need deep native support for Pulumi or Azure Bicep at scale.
7. Scalr
Scalr focuses exclusively on the Terraform and OpenTofu ecosystem, organized in a three-tier hierarchy (account, environment, workspace) that mirrors Terraform Cloud closely enough to make migration straightforward.
Pricing is run-based rather than per-resource: runs blocked by OPA policies, drift detection runs, and failed pre-checks don't count against your quota. Atlantis-style PR commands (/scalr plan, /scalr apply) are supported natively.
Best for: Teams on Terraform Cloud who want a near drop-in replacement with more predictable pricing and no workspace restructuring.
Not the right fit if: Your stack includes CloudFormation, Pulumi, or Kubernetes manifests — Scalr is intentionally Terraform and OpenTofu only.
8. Atlantis
Atlantis is the open-source reference implementation for the PR-comment Terraform workflow. Engineers run atlantis plan and atlantis apply as comments on pull requests. The plan output posts back to the PR, locking happens per project directory, and the audit trail lives in PR history.
A basic atlantis.yaml looks like this:
version: 3
projects:
- name: production-network
dir: terraform/prod/network
apply_requirements: [approved, mergeable]
workflow: production
workflows:
production:
plan:
steps: [init, plan]
apply:
steps: [apply]
The apply_requirements block is where governance lives. Combined with branch protection rules, it determines which PRs can run apply and under what conditions.
Atlantis remains actively maintained, with around 9,100 GitHub stars and a v0.43.0 release shipped May 5, 2026.
Best for: Small to medium teams comfortable running their own service, who want GitOps-driven Terraform automation without a license cost.
Not the right fit if: You have compliance pressure, multi-IaC stacks, or no platform engineer willing to own the upgrade and on-call story. Atlantis is free to license. It is not free to run.
How to choose
Start with what you actually use. List the Terraform Cloud features your team relies on: remote state, plan/apply execution, policies, secrets, or approvals. If it's mostly "remote backend with a UI," generic CI plus a managed state backend may be enough. If governance is the core of your workflow, you need a platform that carries it.
Map your IaC tools. Terraform-only broadens your options. Multi-IaC (CloudFormation, Kubernetes, Pulumi) pushes you toward platforms that standardize across tools without requiring separate pipelines per tool.
Compare pricing models, not just prices. The question isn't which tool looks cheapest today. It's how the bill behaves as you add engineers, resources, and concurrent runs. Per-resource billing is unpredictable at scale. Per-run billing is more foreseeable. Flat fees are predictable but set a floor.
Think about who owns the platform. A self-hosted tool is free to license. It is not free to maintain. Be honest about whether you have a platform engineer willing to own upgrades, on-call, and capacity planning for your CI infrastructure.
Check governance requirements before you commit. If your compliance posture depends on specific certifications or data residency guarantees, verify that a replacement covers the same ground. Assuming it does costs more to fix later than checking upfront.
Know when to stay
The migration argument weakens significantly if any of these apply.
- You're under 500 managed resources on Terraform only. The enhanced Free tier covers you, with unlimited users.
- You've built significant Sentinel policy. Sentinel doesn't port to other platforms. Rebuilding mature governance is real work.
- Your team is small and your workspace model is simple. The collaboration features still work. Don't fix what isn't broken.
- Your compliance posture depends on HashiCorp's specific certifications. Verify a replacement covers the same ground before assuming.
The pricing argument starts to matter around 1,000 to 2,000 managed resources, or when you need IaC tools that Terraform Cloud doesn't support.
What to do next
Most teams migrating from Terraform Cloud land in one of four places: a multi-IaC governance platform, a Terraform-focused replacement with more predictable pricing, a generic CI system paired with a managed state backend, or a self-hosted open-source PR automation tool.
The right bucket depends on where your infrastructure practice is headed, not just where it is today.
If you want to see how Spacelift stacks up for your specific setup, the migration walkthrough from Terraform Cloud to Spacelift covers the practical steps. Or try it free and run it against your existing stacks.
Top comments (0)