Use case

Developer Self-Service

Developers open a pull request. The plan, the cost, the policy check, and the approval land in that pull request. The platform team writes the guardrails once, as config, and stops being the queue.

Pull Request Workflow Guardrails as Config Scoped Tokens No Global Lock
Book a Demo See self-service in action

Self-service with guardrails

Developers get autonomy. The platform team keeps control, without reviewing every change by hand.

Git workflows

Infrastructure changes go through the pull requests developers already open.

  • Plan on every pull request, merge to apply
  • Runs your Terraform or OpenTofu, modules unchanged
  • Or keep your CI and run the Stategraph CLI in it

Guardrails as config

Approval rules and policy checks live in the repository, not in a reviewer's head.

  • Apply requirements per directory and environment
  • OPA, Conftest, and Checkov gates before merge
  • A failing check opens a named gate a human approves by token

Scoped access

A token gets exactly the access the change needs, down to a single resource.

  • Plan without apply, for reviewers and previews
  • One state, or a slice of one, for a pipeline
  • A token never exceeds the session that created it

No waiting on a lock

Product teams stop queueing behind each other's changes.

  • Resource-level locking, so disjoint changes apply at the same moment
  • Overlap is rejected at commit, then re-planned
  • One atomic transaction across states

Cost in the plan

Developers see the bill before they merge.

  • Current-vs-planned cost delta under the plan
  • Thresholds that require extra approval
  • Attribution by tag, owner, and environment

Answers without a ticket

What exists, and what a change touches, without asking the platform team.

  • SQL across every resource and state
  • Blast radius before merge, remote-state consumers included
  • Drive plan, apply, and query from an AI agent with SKILL.md workflows

See self-service in action

A developer provisions a staging database through a pull request. Nobody on the platform team touches it.

● Add staging database for new user service #324 open
A alice-dev opened this pull request
Adding an RDS instance for the new user service: PostgreSQL, encrypted storage, private subnets.
# environments/staging/rds.tf + identifier = "staging-user-service" + engine = "postgres" + instance_class = "db.t3.small" + storage_encrypted = true
S stategraph-bot commented
Stategraph Plan Output
+ aws_db_instance.app_db + aws_db_subnet_group.app_db + aws_security_group.app_db + aws_security_group_rule.app_db_ingress Plan: 4 to add, 0 to change, 0 to destroy Downstream: 0 consumers outside this change
Cost estimation+$25.55/mo
Policy✓ Conftest passed
Approvals for staging✓ platform 1/1
To apply these changes, approve and merge.
B backend-lead approved these changes
LGTM. Go ahead and provision the database.
S stategraph-bot commented after merge
Apply complete
Resources: 4 added, 0 changed, 0 destroyed Transaction recorded: author alice-dev, state staging/database

Guardrails, written once

The platform team decides who can apply where, and how much access a pipeline gets. Both are config.

Who can apply, per environment

Anyone applies to development. Staging needs one platform approval. Production needs the platform team and the security team.

# .terrateam/config.yml apply_requirements: checks: - tag_query: "dir:environments/staging/**" approved: enabled: true any_of: ["team:platform"] - tag_query: "dir:environments/production/**" approved: enabled: true all_of: ["team:platform", "team:security"]

How much a pipeline can do

The staging pipeline gets a token that can apply to the staging state and nothing else. It cannot manage users, mint more tokens, or touch production.

# an apply-only token, scoped to one state $ stategraph user access-tokens create \ --name ci-staging-apply \ --apply \ --apply-state '<staging-state-id>=*'

What the platform team gets back

Self-service only works if the platform team is not the serialization point. That is an architecture property, not a process one.

Parallel, not queued

Independent teams and independent changes do not wait on each other. Contention tracks real overlap, not headcount.

Guardrails as config

Approval rules, policy gates, and cost thresholds are in the repository, reviewed like any other change.

Least privilege by default

People and pipelines get plan or apply on the states and resources they own. Nothing more.

Every change attributed

Each apply is a transaction with an author and a timestamp on an immutable timeline you can query.

Running the internal platform the rest of the company depends on? See Stategraph for platform engineering →

Ready to enable developer self-service?

Give developers autonomy while the platform team keeps control.

Book a Demo Explore Orchestration