Compare

Spacelift vs Stategraph

Spacelift locks a stack for each run and caps concurrency at your worker count. Stategraph locks the resources a change touches, plans across states in one transaction, and has no limit on workers, runs, or users.

Book a Demo Start Free

Teams running Terraform on Stategraph

Read the case studies →

How Stategraph is better

1. Concurrency

No limit on workers

Spacelift runs one run per worker, so concurrency stops at the workers on your plan. Stategraph has no limit on concurrent workers, runs, or users.

Discover Orchestration →

“A worker is a logical entity that processes a single run at a time. As a result, your number of workers is equal to your maximum concurrency.”
Spacelift worker pools documentation

Spacelift Free

1 worker

public

Spacelift Starter+

3 workers

2 public, 1 private

Spacelift Enterprise

5 to 30

private, by quote

Stategraph

Unlimited

concurrent workers

Spacelift worker counts and quote from spacelift.io/pricing and docs.spacelift.io, 2026-09-16.

2. Locks

Locks on resources, not the stack

A tracked run “gets an exclusive lock on the stack, blocking other runs from starting.” Stategraph locks the resources a change touches, so changes that do not overlap apply at the same time.

Learn about parallel applies →

Spacelift, one stack

stack runs

✓ run 01HZ: finished (0:04) ⏸ run 01J0: queued, stack locked ⏸ run 01J1: queued ⏸ run 01J2: queued, no worker ⏱ 12m elapsed · 3 runs waiting

Stategraph, one state

resource locks

✓ tx 01HZ: applied (0:04) ✓ tx 01J0: applied (0:04) ✓ tx 01J1: applied (0:05) ✓ tx 01J2: applied (0:05) ⏱ 5s elapsed · 0 waiting

Illustrative: four changes to different resources in one stack.

3. Changes across stacks

Producer and consumer in one plan

A Spacelift dependency runs the downstream stack “only after another stack have finished running,” so the pull request shows only the upstream plan. Stategraph plans both together and commits both states in one transaction.

Multi-state transactions →

stategraph · cross-state plan

# edit rm1 only: http_proxy_port 8080 → 9090 $ stategraph plan State 0 · rm1 (producer) ~ terraform_data.http_proxy_port input: 8080 → 9090 ~ output.http_proxy_port: 8080 → 9090 State 1 · rm2 (consumer, reads rm1's pending output) ~ terraform_data.firewall_rule_port_min input: 8070 → 9080 Plan: 0 to add, 2 to change, 0 to destroy ✓ across 2 states, one plan, one apply

Real output. Same terraform_remote_state HCL.

Side by side

Spacelift vs Stategraph: Key differences

Capability	Stategraph	Spacelift
Plan scope	✓Only what the change reaches	✗The whole stack, every run
Lock scope	✓The resources a change touches	✗The stack, with an exclusive lock per run
Concurrency	✓Unlimited workers, runs, and users	✗Your worker count: 1 on Free, 3 on Starter+, more by quote
A change across stacks	✓One plan, one transaction	●A tracked run after the upstream apply
Engines	●Terraform and OpenTofu. Orchestration adds Terragrunt, CDKTF, Pulumi	✓Terraform, OpenTofu, Terragrunt, Pulumi, CloudFormation, Kubernetes, Ansible
Query your infrastructure	✓SQL across every resource and state	●Resources view, values shown as checksums
Drift detection	✓Scheduled, tag-scoped, on the Free plan	●Starter+ and above, and “only works on private workers”
Policy	●OPA, Conftest, and Checkov, on every plan	✓OPA Rego at eight decision points. Paid plans only

Spacelift facts and quotes from spacelift.io and docs.spacelift.io, 2026-09-16.

Same HCL, same providers

How to switch

Start with Orchestration.
Move state into Infrastructure as a Database when you want it.

Orchestration

from Spacelift stacks to pull requests

# 1. Spacelift manages the state? Pull it in a task, # and push it to a backend you own. Skip if you have one. $ terraform state pull > terraform.tfstate $ terraform init # with your backend "s3" block $ terraform state push terraform.tfstate # 2. Install the GitHub App or connect GitLab, and commit # the workflow file the console gives you. # 3. Open a pull request. The plan lands as a comment. # Comment stategraph apply, or apply on merge.

Infrastructure as a Database

from Spacelift state to Stategraph

# 1. Pull the state of a stack $ terraform state pull > terraform.tfstate # 2. Import it. Modules and providers do not change. $ stategraph import tf # 3. Plan and apply from Orchestration or your CI $ stategraph plan $ stategraph apply # To leave: write a state file back at any time $ stategraph states export

Keeping Spacelift as the trigger? Run the Stategraph CLI from its custom workflow: Spacelift guide →

“We wanted to keep everything in the pull request flow. Stategraph gave us everything we needed, and it was significantly cheaper.”

Security Engineer at Zip, after evaluating Atlantis, Spacelift, and Terraform Cloud · Read the case study →

FAQ

Common questions

Try it with your own state

Import a state file and run your first plan in under 30 minutes. Pro is free for 30 days, no credit card.

Book a Demo Start Free