Stategraph Orchestration

Every infrastructure change ships from a pull request

A plan on every pull request, policy before merge, and dependency-aware runs across thousands of workspaces. Terraform, OpenTofu, Terragrunt, CDKTF, and Pulumi.

Open source, MPL-2.0 GitHub and GitLab Free for small teams

Start free Read the docs

Teams running Terraform on Stategraph

Read the case studies →

In the pull request

What a change looks like

The plan

Open a pull request, get a plan

Orchestration plans every pull request and posts the result as a comment. The plan, the cost, the policy checks, and the approvals are in the review, and the apply runs on merge or on a comment.

How workflows run →

OpenAdd API server #482

stategraphbotcommented

production/compute
+ google_compute_instance.api_server
+ google_compute_disk.data
Plan: 2 to add, 0 to change, 0 to destroy
Downstream: production/networking, updated in this plan

$Cost +$266.24/mo (+14%)
✓Policy 2/2 checks passed
✓Platform team 1/1 approved
⏱Security team 0/1 required for production

Merge pull requestapply on merge, or comment stategraph apply

Illustrative. The layout follows the comment Orchestration posts.

Order

Runs in dependency order, in parallel where it can

Networking first, then data and compute together, then the applications. Orchestration derives the order from your layers and stacks and runs each layer in parallel.

Layered runs → · Stacks →

Layer 0

terraform validate

Layer 1

prod/networking

Layer 2, in parallel

prod/databaseprod/eks

Layer 3

prod/application

Sign-off

Who approves, and what stops an apply

Apply requirements set the approvals per environment. A failing Checkov, Conftest, OPA, or custom check opens a named gate, and a person with the right role approves it by token, in the pull request.

Apply requirements → · Gatekeeper →

Apply requirements

developmentanyone
staging1 × platform
prod2 × platform + security

Gatekeeper

check failed→gate opened→approved, apply

stategraph gate approve <token>

Drift

Drift found on a schedule, fixed on request

Schedules run hourly through monthly, scoped by tag query, inside a maintenance window you set. A drift run opens an issue, or reconciles the drift for you.

Drift detection →

Drift detected · prod/database

- backup_retention_period = 14
+ backup_retention_period = 7
- multi_az = true
+ multi_az = false

schedule: daily · tag_query: prod · reconcile: true

Monorepos

One expression selects the directories a rule applies to

A tag query scopes workflows, access control, apply requirements, drift schedules, and any command typed into a pull request. Centralized configuration governs hundreds of repositories from one, and parallel and batched runs split a change that is too large for a single CI run.

Tag queries → · Centralized configuration →

.stategraph/config.yml

access_control: policies: - tag_query: "prod and not deprecated" apply: [team:platform] plan: ['*'] drift_detection: schedules: prod: tag_query: "prod" schedule: hourly reconcile: true apply_requirements: checks: - tag_query: "dir:prod/**" approved: all_of: [team:platform, team:security]

Illustrative. The keys are documented in the configuration reference.

With Infrastructure as a Database

Set the engine to Stategraph

Orchestration runs whichever engine you configure. With the Stategraph engine, each plan reads only the resources the change reaches, pull requests that touch different resources do not queue, and a change across states is one plan. It works without it too, against plain Terraform or OpenTofu state.

Use with Orchestration →

stategraph · multi-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.

Docs

Every step of the run is yours to configure

Workflows

Plan and apply steps, hooks, custom commands, multi-environment layouts, gitflow, rollbacks, apply after merge, layered runs.

Governance

RBAC, Gatekeeper, drift detection, centralized configuration, configuration overrides.

Security

OIDC for AWS, GCP, and Azure, private runners, plan file storage, GitHub environments, the audit trail.

IaC tools

Terraform, OpenTofu, Terragrunt, Pulumi, CDKTF, a custom engine, and moving off HCP Terraform.

Configuration reference

Every key in .stategraph/config.yml: dirs, workflows, hooks, tags, access control, apply requirements, drift, cost estimation.

Pull request commands

plan, apply, apply-force, unlock, gate approve, repo-config, and help, typed as comments.

Deployment

Run it where your security team wants it

Stategraph Cloud

Managed by us. Free for small teams, one flat price above that.

Self-hosted

Open Source under MPL-2.0, or Pro for the same price as on Stategraph Cloud. Docker Compose or Kubernetes, air-gapped if needed.

BYOC

We operate it inside your AWS, GCP, or Azure account. You own the data and the account.

Plans and applies run on your own GitHub Actions or GitLab CI runners, so your cloud credentials stay there. Pricing →

Start Running Terraform in Pull Requests

Start with 30 days of Pro, no credit card, then stay free on the hosted plan. Move to Pro when you outgrow the limits.

See pricing Read the docs