Stackorder

Website · Documentation · Getting started

Stackorder is lightweight Terraform and OpenTofu orchestration on GitHub Actions. A GitHub App and a small control-plane server work out which stacks a change affects and the order to apply them in, and GitHub Actions does all of the running. Credentials, state and modules stay in your GitHub organisation or personal account and your AWS account; the server receives metadata and redacted plan text, never cloud credentials, and stores no state, reading none unless an operator turns on shared outputs.

1. Pull request plans. Every push to a pull request scans the repository, sends the dependency graph to the server and plans each affected stack on your GitHub Actions runners. You get one check per stack and one sticky comment.
2. Apply gate. A stackorder apply comment, or the merge, is checked for who asked, approvals, fresh plans on the head commit, policy checks and stack locks. Every failure is reported together in one comment.
3. Dependency waves. Applies run one wave at a time in the order set by depends_on edges and reads_state edges, which come from terraform_remote_state and stackorder_outputs blocks. Each job runs under the stack's GitHub environment, and a failed stack blocks its dependents.
4. Drift. On a schedule, the server plans every stack at the head of the default branch and can open one GitHub issue per drifted stack.

The server coordinates and never executes: it stores no state and no plan files, and holds no cloud credentials unless an operator turns on shared outputs, which let its AWS role read the state objects the operator lists, never write them. The plan text it receives is redacted and capped at 256 KB. If it is down, pull request plans still run and only applies pause, except that a stack reading shared outputs cannot plan.

• Introduction: what the server does, and what it deliberately is not.
• Comparison: how Stackorder compares with Atlantis, HCP Terraform, Terrakube and Stategraph.
• Local demo: plan, apply and check drift on one machine, with no GitHub App and no AWS account.
• Getting started: take one repository from nothing to its first stackorder apply.
• How it works: the execution model, the apply gate, waves, locks and drift.
• Stack instances and Shared outputs: deploying one directory per environment, and reading another stack's outputs without reading its state.
• stackorder.yaml and Security model: the reference pages to read before production.

v0.4.0 is the current release. The CLI builds are on the stackorder/stackorder releases page, the server image is ghcr.io/stackorder/stackorder:0.4.0, repositories call the workflows as stackorder/actions@v1, and the stackorder/stackorder provider is published on the Terraform Registry and the OpenTofu Registry. The changelog lists what shipped and where the code departs from the design.

Report vulnerabilities privately, through each repository's Security tab, as the security policy describes. The security model sets out what each part of Stackorder can and cannot do if compromised.

The stackorder, actions, terraform-provider-stackorder and example-infra repositories are open source under the Apache License 2.0.