Use case · Deploy gates

Deploys need judgment. Give the judgment a place to live.

The pipeline is the easy part. The hard part is the pause before production — who decided this release was safe, and where is that written down? In most teams it's a thumbs-up in a chat thread. Rollout builds and stages automatically, then holds production until a person moves the release to Approved — a recorded state change the whole team can see.

release → ready → build → stage → a person approves → deploy → verify → deployed → audit

Stage 1 · Automate the safe part

Marked Ready — built and staged without anyone asking

A release record moving to Ready is the trigger. The pipeline builds the image, deploys it to staging, marks the record Staged, and asks the approvers for sign-off. No bot reminders, no copy-pasted checklists — the workflow is the checklist.

Release pipeline build lane: a release marked Ready triggers the build and staging deploy — Captured from a representative demo workspace.

Stage 2 · The gate

The gate is a status a person moves

There's no hidden pause buried in CI config. The release record is the gate: moving it to Approved is the approval. Everyone sees which releases are staged, which are approved, and which are blocked — the same way they see their tickets.

Release readiness records with status, version, risk, and target date — the gate states of every release — Captured from a representative demo workspace.

Stage 3 · Ship

Deploy fires from the approval — not from a terminal

The Approved status change triggers the deploy lane: production rollout, health verification, record marked Deployed, audit entry written. The person who approved never touches kubectl — and a deploy outside the lane is conspicuous, because it has no run and no recorded approval behind it.

The deploy lane: a release approved by a person triggers the production deploy and health verification — Captured from a representative demo workspace.

Stage 4 · Evidence

The run is the receipt

Every deploy is a run: the approval that triggered it, the exact commands, the health check response, the record update, the audit entry. When someone asks "who shipped 1.42 and how did we know it was healthy?" — you open the run, not your memory.

Deploy run #88: the approval trigger, production deploy, and health verification, each step recorded — Captured from a representative demo workspace.

Why

Why a status gate beats a pipeline pause

Visible: gate state lives on a record the whole team can see — not in a CI job only the release engineer knows how to read.
Recorded: the approval is a state change with an actor and a timestamp, written to the audit trail — not a 👍 that scrolls away.
Carried with evidence: the same record holds version, risk, and target date — the approver decides with the context attached, not from memory.
One path to production: the deploy lane only fires from the Approved transition, so the gate can't be worked around quietly.

Put a gate in front of production

Run it in Cloud Pro or license Business for your own infrastructure. Add Design Partner implementation if you want the first release process built with the founder.

Prefer to talk it through? Talk to the founder

Want the numbers first? See pricing — exact software and optional implementation prices are published there.