Stackorder vs Terrakube

Q: Does Terrakube order runs across workspaces?

In the stable 2.33 line, workspaces share state through terraform_remote_state. Run triggers with a dependency graph are in the 2.34.0 pre-releases and, on 2026-09-30, in no stable release. Stackorder orders applies across stacks with its dependency graph.

In short

Both: Apache-2.0 and self-hosted, for Terraform and OpenTofu.
Terrakube: A platform in the Terraform Enterprise mold: its own executors, built-in state, a private registry, and four Git hosts.
Stackorder: Runs on your GitHub Actions runners, stores no state or modules and holds no cloud credentials; one container and Postgres; GitHub only.

Terrakube and Stackorder are both open source under the Apache License 2.0, and both are self-hosted. Terrakube is a full platform in the Terraform Enterprise mold: it implements the TFE remote backend, runs Terraform and OpenTofu on its own executors, stores state, hosts a private registry for modules and providers, and works with GitHub, GitLab, Bitbucket and Azure DevOps.

Stackorder is deliberately smaller. It runs nothing itself: GitHub Actions runs every plan and apply on your runners, state stays in your S3 bucket, and the server, one container and Postgres, decides which stacks run and in what order.

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

Stackorder and Terrakube side by side

Numbers link to the sources. A dash means we haven't verified it, not that it's missing.

Feature	Stackorder	Terrakube
License	Apache-2.0, open source³⁵	Apache-2.0, open source¹
Deployment	Self-hosted; setup mode creates the GitHub App from a manifest^{28, 32}	Self-hosted only: a Helm chart on Kubernetes, or Docker Compose⁵
Pricing	Free and open source; you run the server³⁵	Free; no paid tier, hosted service or commercial edition advertised³
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^{33, 34}	Actively maintained: 2.33.2 released on 2026-09-14, with 2.34.0 in beta⁴
Where Terraform runs	Your GitHub Actions runners, GitHub-hosted or self-hosted; it manages no runners or agents²⁴	Its own executors: a persistent pod pool, ephemeral Kubernetes Jobs, or self-hosted agents^{8, 9}
State backend	Bring your own S3; never takes or releases the state lock²⁴	Built in, per workspace, in Azure Storage, S3, Google Cloud Storage or MinIO; implements the TFE remote backend and `cloud` block^{10, 11}
Modules	No registry; lists each module's consumers, and for git modules the version each pins and how far behind it is²⁴	Built-in private registry for modules and providers; a new SemVer tag imports a module version¹⁴
Self-hosted footprint	One container of about 30 MB and Postgres; actions that use no Docker²⁴	API, executor, registry, UI, Dex and OpenLDAP (on by default), with MinIO, PostgreSQL and Valkey subcharts that can be swapped for external services⁶
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^{25, 26}	Stable 2.33: shared state through `terraform_remote_state`. Run triggers with a dependency graph only in 2.34.0 pre-releases^{12, 13}
Cloud credentials	Not held by the server; the runner assumes your IAM role with its own GitHub OIDC token²⁷	Held by the platform: static credentials as sensitive variables, or short-lived tokens from Terrakube's own OIDC issuer^{21, 22}
Human sign-in	GitHub OAuth through the App, `read:org` scope only²⁸	Dex connectors with groups, such as Azure AD, Google, Cognito, Keycloak, GitHub, GitLab or LDAP²³
Git hosts	GitHub only, by design²⁴	GitHub (including Enterprise), GitLab, Bitbucket, Azure DevOps, and SSH repositories without webhooks¹⁹
OpenTofu	Yes, with `tool: tofu`; tested end to end with OpenTofu 1.12^{31, 33}	Yes, chosen per workspace²⁰
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²⁹	A documented pattern: a plan template with an OPA check and a Slack notice, run on a workspace schedule¹⁵
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³⁰	OPA through extensions and templates in stable releases; native policy governance in 2.34.0 pre-releases¹⁶
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²⁵	Webhooks on push, pull request or release; an optional plan comment and `terrakube plan` and `terrakube apply` commands, except on Azure DevOps¹⁷

Key differences

Where Terraform runs

Terrakube runs Terraform and OpenTofu on its own executors: a persistent pod pool, ephemeral Kubernetes Jobs created by its API, or self-hosted agents. Its GitHub Action only asks the Terrakube API to run a template; the job still executes on Terrakube. Stackorder runs every plan and apply on your GitHub Actions runners and manages no runners of its own.

State and modules

Terrakube stores each workspace's state in Azure Storage, S3, Google Cloud Storage or MinIO, implements the TFE remote backend and cloud block, and hosts a private registry for modules and providers. Stackorder stores neither: state stays in your S3 bucket and modules stay in git.

Footprint

Terrakube's Helm chart deploys an API, an executor, a registry, a UI, Dex and, by default, OpenLDAP, with MinIO, PostgreSQL and Valkey subcharts; production should use an external Redis. Stackorder runs one container and Postgres.

Dependencies

In Terrakube's stable 2.33 line, workspaces share state through terraform_remote_state. Run triggers with a dependency graph and cycle checks were merged in September 2026 and ship only in 2.34.0 pre-releases. Stackorder builds a graph of stacks and modules, plans downstream stacks in the pull request, and applies the affected stacks in waves.

Credentials

Terrakube holds static cloud credentials as sensitive variables, or, with dynamic provider credentials, holds an RSA key and acts as an OIDC issuer whose short-lived tokens AWS, Azure, GCP or OpenBao and Vault trust. The Stackorder server has no cloud access at all: each GitHub Actions job assumes your role with its own GitHub OIDC token.

Git hosts and sign-in

Terrakube works with GitHub, GitLab, Bitbucket and Azure DevOps, and signs people in through Dex with many identity providers. Stackorder is GitHub only, by design, and signs people in with GitHub OAuth.

Where Terrakube is strong

Open source under Apache-2.0 and self-hosted, with no paid tier.^{1, 3}
Implements the TFE remote backend and cloud block, so the Terraform CLI can target it.¹¹
State and a private registry for modules and providers, built in.^{10, 14}
GitHub, GitLab, Bitbucket and Azure DevOps, plus SSH repositories.¹⁹
Sign-in through Dex, with group-based authorization and many identity providers.²³
Dynamic provider credentials for AWS, Azure, GCP and OpenBao or Vault instead of stored keys.²²
Terraform or OpenTofu, chosen per workspace.²⁰
Executors as a static pod pool, ephemeral Kubernetes Jobs or self-hosted agents.^{8, 9}
Actively maintained: 2.33.2 was released on 2026-09-14, and 2.34.0 is in beta.⁴

When to choose which

Choose Stackorder when

Your code is on GitHub and you want Terraform or OpenTofu to run on your own GitHub Actions runners, under AWS roles the runner assumes with its own GitHub OIDC token.
You have many stacks that depend on each other or on shared modules, and you want a change planned everywhere it lands and applied in dependency waves.
You want a small open-source server you host yourself, which holds no cloud credentials and no state, and whose outage pauses applies but not pull request plans.

Choose Terrakube when

You want a free, self-hosted platform that hosts state and a private module and provider registry, in the model of Terraform Enterprise.
Your code is on GitLab, Bitbucket or Azure DevOps. Stackorder is GitHub only, by design.
You already run Kubernetes and want the platform to own execution, with sign-in through your identity provider.
You are moving off Terraform Enterprise workflows and want to keep the remote backend.
You want a tool with more production use: Stackorder's first release, v0.1.0, came out on 2026-09-30.

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.

Frequently asked questions

Are Terrakube and Stackorder both self-hosted and open source?

Yes. Both are open source under the Apache License 2.0 and you host both yourself. Terrakube deploys with a Helm chart or Docker Compose as an API, an executor, a registry, a UI and Dex, with MinIO, PostgreSQL and Valkey subcharts. Stackorder is one container and a Postgres database.

Does Stackorder have a module registry like Terrakube?

No. Terrakube hosts a private registry for modules and providers. Stackorder records module consumers and, for git modules, the version each stack pins, but it is not a registry.

Does Terrakube order runs across workspaces?

In the stable 2.33 line, workspaces share state through terraform_remote_state. Run triggers with a dependency graph are in the 2.34.0 pre-releases and, on 2026-09-30, in no stable release. Stackorder orders applies across stacks with its dependency graph.

Does Terrakube run Terraform on GitHub Actions?

No. Terrakube's GitHub Action asks the Terrakube API to run a template, and the job executes on Terrakube's executors. With Stackorder, every plan and apply runs in your GitHub Actions jobs.

Which Git hosts do they support?

Terrakube supports GitHub, including Enterprise, GitLab, Bitbucket, Azure DevOps and SSH repositories. Stackorder supports GitHub only, by design.