Terraform Cloud alternatives and Terraform automation tools, compared

Terraform automation and collaboration software, often called TACOS, runs plan and apply for a team: on pull requests, with locks, approvals and a record of what ran. These tools differ most on three things: where Terraform runs, who holds your cloud credentials, and how they order dependent stacks. The matrix below compares Stackorder with 8 other tools on those and 13 other features, with a source for every cell.

Stackorder is an open-source orchestrator for Terraform and OpenTofu on GitHub Actions. Its server never runs Terraform and never holds cloud credentials; your GitHub Actions runners do the work.

Last reviewed 2026-09-30 against each tool's own repository, documentation or pricing page.

Feature matrix

A dash means we haven't verified it, not that it's missing. Scroll sideways to see every tool; each tool's page cites every cell.

Feature	Stackorder	Atlantis	HCP Terraform (formerly Terraform Cloud)	Stategraph (formerly Terrateam)	Spacelift	env zero (formerly env0)	Scalr	Terrakube	OpenTaco (formerly Digger)
License	Apache-2.0, open source	Apache-2.0, open source; a CNCF Sandbox project	Proprietary, commercial; the Terraform CLI itself is under BSL 1.1 since version 1.6.0	MPL-2.0; Enterprise features need a commercial license	Proprietary platform; open-source tooling such as spacectl and the Terraform provider under MIT	Proprietary SaaS; its Terraform provider, Terratag and MCP server are open source	Proprietary SaaS; its Terraform provider is MPL-2.0 and its GitHub Action MIT	Apache-2.0, open source	Open core: MIT at the root, and a proprietary Digger Enterprise license for the `ee/` directory
Deployment	Self-hosted; setup mode creates the GitHub App from a manifest	Self-hosted only: Helm chart, Kubernetes manifests or Kustomize, OpenShift, an AWS Fargate module, GKE or GCE, or Docker	SaaS, with a separate HCP Europe region; Terraform Enterprise is the self-hosted distribution	Stategraph Cloud (SaaS), self-hosted (open source or Enterprise), or in your own AWS, GCP or Azure account	SaaS, now called Spacelift Deploy; self-hosted on AWS, Azure, GCP or on-premises Kubernetes only on the Enterprise+ tier	SaaS only, optionally with self-hosted agents; the control plane cannot be self-hosted	SaaS only, at scalr.io on Google Cloud in the United States; agents can run jobs in your network	Self-hosted only: a Helm chart on Kubernetes, or Docker Compose	Hosted app at otaco.app, or self-hosted with Docker Compose, Railway or Helm charts
Pricing	Free and open source; you run the server	Free; no paid tier or hosted offering	Per managed resource, billed hourly: Free up to 500 resources; Essentials from $0.10, Standard from $0.47 and Premium from $0.99 per resource a month; Terraform Enterprise custom	Cloud Free: 3 users, 50 runs a month, 1 worker. Pro: $12,000 a year with unlimited users, runs and workers. Self-hosted open source: $0, up to 3 active users a month per installation	Free: 2 users, 1 public worker. Starter+: $20,000 a year, unlimited users. Business, Enterprise and Enterprise+ by quote	Free: 250 runs a month, 30 active environments, 1 concurrent run, 1 self-hosted agent. Cloud Navigator and Cloud Pilot: custom, priced per successful apply or environment	Per run. Free: 50 runs a month with unlimited users, SAML SSO and agents. Business: $0.99 a run. Enterprise: custom, from 20,000 runs a year	Free; no paid tier, hosted service or commercial edition advertised	No public pricing page; Enterprise features by per-seat subscription, through contact or a demo
Maturity	v0.1.0, first released 2026-09-30; tested end to end against LocalStack, not yet against real AWS or a real GitHub organization by default	A CNCF Sandbox project, actively released; v0.48.0 added slim images	—	The vendor reports daily releases and more than 20,000 automated tests per change	—	—	—	Actively maintained: 2.33.2 released on 2026-09-14, with 2.34.0 in beta	Actively released: v0.6.151 on 2026-09-13, after roughly monthly releases through 2026
Where Terraform runs	Your GitHub Actions runners, GitHub-hosted or self-hosted; it manages no runners or agents	On the Atlantis server itself, not on CI runners	Disposable VMs in HashiCorp's cloud by default, or self-hosted agents that need only outbound access; a workspace can also run locally	Your GitHub Actions or GitLab CI runners; the server dispatches workflows and does not run Terraform	A fresh Docker container per job, on Spacelift's public workers or on private workers you run	env zero-hosted agents by default, or self-hosted Kubernetes or Docker agents in your infrastructure	Scalr's shared runners by default, or any number of self-hosted agents, each adding 5 concurrent runs	Its own executors: a persistent pod pool, ephemeral Kubernetes Jobs, or self-hosted agents	Your CI, GitHub Actions by default, for pull request automation and drift; Remote Runs (beta) in E2B sandbox VMs
State backend	Bring your own S3; never takes or releases the state lock	Bring your own; any backend except local state	Built in: HCP Terraform is the state backend	Your existing backend; Stategraph's database-backed state is a separate commercial product. Plan files stay in the server's database by default	Optional Spacelift-managed state on S3, with history and rollback, chosen when a stack is created; or your own backend	Optional env zero remote backend with locking and versioning, which can store state in your own S3 bucket; or a standard backend such as S3	Built in, in a Scalr-owned encrypted bucket; your own bucket through storage profiles on Enterprise; other backends with limits	Built in, per workspace, in Azure Storage, S3, Google Cloud Storage or MinIO; implements the TFE remote backend and `cloud` block	Your existing backend; or OpenTaco's HCP Terraform-compatible state service on S3-compatible storage
Modules	No registry; lists each module's consumers, and for git modules the version each pins and how far behind it is	No registry; the opt-in `--autoplan-modules` plans the projects that use a changed local module	Built-in private registry versioned by Git tags; the Explorer shows module usage across workspaces	No registry; a module-aware indexer, off by default, plans the directories that use a changed local module	Private module registry on paid accounts, with tests per version; module trigger policies see each module's consumers	Private module and provider registry, with download counts and the environments using each module	Built-in private registry, published from VCS or OCI; a Modules report shows versions across workspaces and flags outdated ones	Built-in private registry for modules and providers; a new SemVer tag imports a module version	No registry; `include_patterns` globs trigger projects when a module path changes
Self-hosted footprint	One container of about 30 MB and Postgres; actions that use no Docker	One Go binary or container with no external database; a persistent disk for plans and BoltDB locks, or Redis for locks	SaaS. Terraform Enterprise runs as containers with PostgreSQL, S3-compatible storage and Vault, plus Redis for active-active	Server and PostgreSQL behind a public HTTPS URL; a GitHub Action that runs as a Docker container	SaaS. Self-hosted: server and drain services on Kubernetes or ECS, PostgreSQL, object storage buckets, a queue and an optional MQTT broker	SaaS control plane. Kubernetes agent: Kubernetes 1.24 or later, one pod per deployment requesting at least 460m CPU and 1500Mi memory	SaaS control plane. Agent: at least 2 GB of memory and 1 CPU per run, 20 GB of disk, and outbound HTTPS to scalr.io	API, executor, registry, UI, Dex and OpenLDAP (on by default), with MinIO, PostgreSQL and Valkey subcharts that can be swapped for external services	UI, orchestrator, drift, drift trigger, state, token and sidecar services; three Postgres databases, S3-compatible storage and WorkOS
Cross-stack dependencies	A graph of stacks and modules from `depends_on`, module sources and `terraform_remote_state` reads, including cross-repository edges; applies in waves	`execution_order_group` for a global plan or apply, and `depends_on` between projects in one `atlantis.yaml`	Run triggers between workspaces, up to 20 sources each; Stacks, with linked Stacks, on RUM plans	Layered runs: `depends_on` between directories in one repository, optionally on specific outputs	Stack dependencies form a DAG, across repositories, and pass outputs downstream as inputs	Workflows, in which each environment lists what must deploy first under `needs`; Workflow Triggers chain deploys	Explicit run triggers between workspaces, up to 50 upstreams, also across federated environments; not inferred	Stable 2.33: shared state through `terraform_remote_state`. Run triggers with a dependency graph only in 2.34.0 pre-releases	`depends_on` between projects and numeric layers in `digger.yml`; Terragrunt dependency parsing
Cloud credentials	Not held by the server; the runner assumes your IAM role with its own GitHub OIDC token	Held by the server, which runs Terraform: instance or workload roles, environment variables, credential files or Vault	Held by the service: static credentials as variables, or short-lived OIDC credentials it receives for each run	Not held by the server; the runner uses OIDC or secrets stored in GitHub or GitLab	Spacelift assumes your AWS role, or a private worker does and the credentials never reach Spacelift; Spacelift-signed OIDC as an alternative	On hosted agents, env zero authenticates to your cloud: assume-role, stored keys, or OIDC tokens it issues; self-hosted agents read your own secret store	Held by default in encrypted provider configurations: keys, an IAM role, or per-run OIDC with Scalr as the identity provider; agents can keep them in your network	Held by the platform: static credentials as sensitive variables, or short-lived tokens from Terrakube's own OIDC issuer	Not held for pull request automation: credentials stay in your CI, with OIDC recommended; not documented for Remote Runs
Human sign-in	GitHub OAuth through the App, `read:org` scope only	—	—	—	SAML 2.0 single sign-on from the Enterprise tier	—	SAML single sign-on, included on the free plan	Dex connectors with groups, such as Azure AD, Google, Cognito, Keycloak, GitHub, GitLab or LDAP	WorkOS, required when self-hosting
Git hosts	GitHub only, by design	GitHub, GitLab, Gitea and Forgejo, Bitbucket Cloud and Server, Azure DevOps	GitHub, GitLab, Bitbucket and Azure DevOps, hosted and self-managed; an API-driven workflow for others	GitHub, including GitHub Enterprise Server, and GitLab	GitHub (including GitHub Enterprise), GitLab, Azure DevOps, Bitbucket Cloud and Data Center, and raw Git	GitHub, GitLab, Bitbucket and Azure DevOps; self-hosted GitHub Enterprise Server, Bitbucket Data Center and GitLab through an agent	GitHub, GitHub Enterprise, GitLab, Azure DevOps, Bitbucket Cloud and Data Center; VCS agents for private networks	GitHub (including Enterprise), GitLab, Bitbucket, Azure DevOps, and SSH repositories without webhooks	GitHub is the documented path; GitLab pipelines need an Enterprise license key
OpenTofu	Yes, with `tool: tofu`; tested end to end with OpenTofu 1.12	Yes, with `--default-tf-distribution=opentofu` or `terraform_distribution` per project	Not documented; it runs the Terraform CLI	Yes, with `engine: tofu`; also Terragrunt, CDKTF and Pulumi	Yes, first-class; all OpenTofu versions	Yes; OpenTofu is the default binary	Yes, first-class, billed the same as Terraform	Yes, chosen per workspace	Yes, per project with `opentofu: true`; Terragrunt and Pulumi too
Drift detection	Scheduled per stack with `drift.schedule`; with `open_issue`, one GitHub issue per drifted stack, closed when the drift is gone; never applies to fix drift	Alpha API endpoints since v0.45.0, off by default; no built-in scheduler, so an external job has to call them	Health assessments on Standard and Premium, for workspaces in remote or agent execution	Scheduled hourly to monthly, off by default; can open an issue or apply fixes with `reconcile`; one schedule in the open-source edition	Scheduled proposed runs with optional reconciliation; private workers only; Starter+ and above	Scheduled per environment, with alerts; optional automatic remediation by redeploying or opening a pull request	Scheduled daily or weekly per environment, with ignore, sync-state or revert actions; drift runs are not billed	A documented pattern: a plan template with an OPA check and a Slack notice, run on a workspace schedule	A drift service on a cron schedule, or a backendless Actions workflow, reporting to Slack or GitHub Issues
Policy checks	Not a policy engine; run OPA, conftest, Checkov or Infracost in hooks, and `stackorder check` records a named check the apply gate honors	Built-in Conftest (OPA) checks with policy-owner approval; `custom_policy_check` for other tools	Built in: Sentinel, OPA, and HCL-based Terraform policy in beta	OPA/Rego, Conftest and Checkov on every plan in every edition; Gatekeeper approval gates in Stategraph Cloud and self-hosted Enterprise	Built-in OPA/Rego policy engine with several policy types	OPA approval policies after plan and cost estimation, not enforced on pull request plans; cost estimates through Infracost	Built-in OPA before and after plan, with three enforcement levels; Checkov before plan	OPA through extensions and templates in stable releases; native policy governance in 2.34.0 pre-releases	OPA through Conftest, run as a workflow step against the plan
Pull request workflow	A check per stack, one sticky comment, and `stackorder plan`, `apply` and `unlock` comments; applies before merge by default, or on merge	`atlantis plan` and `atlantis apply` comments and autoplan on each commit; applies before merge by default; a lock per directory and workspace until the pull request merges or closes	Speculative plans posted as pull request checks; merges trigger plans; manual or automatic apply per workspace	Autoplan on each push, against the merge with the destination branch; a `stategraph apply` comment applies the reviewed plan; applies before merge by default, or on merge	Proposed runs on pushes, reported as commit statuses; opt-in plan comments and `/spacelift` commands; deploying before merge is supported	Plans on pull requests as a comment and status checks; plan and apply from comments, open to any commenter unless RBAC enforcement is turned on	A dry run on every pull request; `/scalr plan` and `/scalr apply` comments allow apply before merge; GitHub checks	Webhooks on push, pull request or release; an optional plan comment and `terrakube plan` and `terrakube apply` commands, except on Azure DevOps	`digger plan`, `apply`, `lock` and `unlock` comments; applies before merge by default, on merge if configured; pull request locks

What to look for in a Terraform Cloud alternative

Where Terraform runs: On the vendor's workers, on the tool's own server or executors, or on your own CI runners.
Who holds cloud credentials: The platform, a server you run, or your CI runner, which can assume a role with its own OIDC token.
State and modules: Whether the tool hosts state and a private module registry, or works with the backend and Git repositories you already have.
Git hosts: GitHub only, or GitLab, Bitbucket and Azure DevOps as well.
OpenTofu: Supported as a first-class tool, chosen per project or workspace, or not documented.
Cross-stack dependencies: Run triggers between workspaces, ordering within one repository, or a graph that also follows modules and state reads.
Pricing model: Free and open source, per managed resource, per run, per seat, or by quote.

Which tool fits which team

Your code is not on GitHub, or is on several Git hosts: Atlantis, Stategraph, HCP Terraform, Spacelift, env zero, Scalr and Terrakube all work beyond GitHub; OpenTaco's GitLab pipelines need an Enterprise license key. Stackorder is GitHub only, by design.
You want Terraform to run on your own CI runners, with cloud credentials in your CI: Stackorder runs on your GitHub Actions runners, Stategraph on your GitHub Actions or GitLab CI runners, and OpenTaco in your CI, GitHub Actions by default.
You want plan and apply from pull request comments on one server, with no CI runners involved: Atlantis runs Terraform on its own server, which holds your cloud credentials.
You want to self-host a platform that stores state and hosts a private registry: Terrakube is Apache-2.0 and does both. Terraform Enterprise, the self-hosted edition of HCP Terraform, is the commercial option.
You want a policy engine built in: Spacelift, Scalr, HCP Terraform, Stategraph and env zero evaluate OPA or Sentinel policies themselves, and Atlantis runs Conftest. Stackorder records the verdicts of the tools you run in hooks.
You want a managed service with no control plane to run: HCP Terraform, Spacelift, env zero and Scalr are SaaS, and Stategraph and OpenTaco also offer hosted editions.
You have many stacks on GitHub that depend on each other and on shared modules, with state in S3: Stackorder plans every stack a change reaches and applies them in dependency waves, from a graph of depends_on, module sources and terraform_remote_state reads.

One page per tool

Stackorder vs Atlantis
Free, Apache-2.0 CNCF project: a self-hosted server that runs plan and apply itself, driven by pull request comments.
Stackorder vs HCP Terraform (formerly Terraform Cloud)
HashiCorp's commercial platform, formerly Terraform Cloud: hosted runs, state, registry, policy and drift, priced per managed resource.
Stackorder vs Stategraph (formerly Terrateam)
Formerly Terrateam: runs Terraform on your GitHub Actions or GitLab CI runners, dispatched by its server. MPL-2.0, hosted or self-hosted.
Stackorder vs Spacelift
Commercial IaC platform, SaaS first: runs in containers on its own or your private workers, with an OPA policy engine and optional managed state.
Stackorder vs env zero (formerly env0)
Formerly env0: a proprietary SaaS for IaC automation and governance, with hosted or self-hosted agents, approval policies and drift remediation.
Stackorder vs Scalr
Proprietary SaaS remote backend and run platform in the Terraform Cloud model, with self-hosted agents and per-run pricing.
Stackorder vs Terrakube
Apache-2.0, self-hosted platform in the Terraform Enterprise mold: its own executors, built-in state and a private registry.
Stackorder vs OpenTaco (formerly Digger)
Formerly Digger: open-core orchestration that runs Terraform in your GitHub Actions, now with a state service, Remote Runs in beta and drift.

What Stackorder is, and what it is not

Stackorder is a GitHub App plus a small control-plane server that decides which stacks to run and in what order, then lets GitHub Actions do all of the running. Its server does two jobs: dependency resolution, and a record of every plan, apply and drift check. It is deliberately not a state backend, module registry, secrets store, policy engine or runner.

Read the comparison in the documentation for the reasoning row by row, or the overview of how Stackorder works.

When something else fits better

You are not on GitHub. Stackorder is GitHub only, by design.
You want the tool to host state or modules. Stackorder stores neither. Stack discovery looks for backend "s3" blocks, and state links assume S3.
You want a policy engine built in. Stackorder records the verdicts of the tools you run; it does not evaluate policy itself.
You want managed runners or agents. Use GitHub's own runner mechanisms; Stackorder does not manage them.

Frequently asked questions

What is the best open-source alternative to Terraform Cloud?

For teams on GitHub with state in S3, Stackorder (Apache-2.0) is an open-source Terraform Cloud alternative that runs plans and applies on your own GitHub Actions runners: see Stackorder as a Terraform Cloud alternative. Terrakube (Apache-2.0) is the closest self-hosted match if you need the tool to host state and a private registry, and Atlantis (Apache-2.0) runs plan and apply on its own server from pull request comments.

Which of these tools run Terraform on GitHub Actions?

Stackorder runs every plan and apply on your GitHub Actions runners. Stategraph Orchestration, formerly Terrateam, runs them on your GitHub Actions or GitLab CI runners, and OpenTaco, formerly Digger, runs its pull request automation in your CI, GitHub Actions by default. Atlantis runs Terraform on its own server, HCP Terraform on HashiCorp-hosted VMs or self-hosted agents, Spacelift in containers on its public workers or your private workers, env zero on its hosted or self-hosted agents, Scalr on its shared runners or self-hosted agents, and Terrakube on its own executors.

Which of these tools are open source?

Stackorder, Atlantis and Terrakube are Apache-2.0. Stategraph Orchestration is MPL-2.0, and its self-hosted open-source build allows up to 3 active users a month per installation. OpenTaco is open core: MIT at the root, with a proprietary license for its ee/ directory. HCP Terraform, Spacelift, env zero and Scalr are proprietary platforms.

Which of these tools hold cloud credentials?

The Stackorder and Stategraph servers never hold them: the CI runner does, and OpenTaco keeps them in your CI for its pull request automation too. The Atlantis server holds them because it runs Terraform. HCP Terraform, and env zero and Scalr by default, store credentials or receive short-lived ones for each run; Spacelift assumes your role unless a private worker does it; Terrakube stores static credentials or issues its own OIDC tokens.

Try Stackorder on your own repositories

Free and open source under the Apache License 2.0. The getting started guide takes one repository from nothing to a first stackorder apply; the local demo runs on one machine with no GitHub App and no AWS account.

Get started Try the local demo

Star stackorder on GitHub to follow releases.