Reference build · 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? 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, then 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. 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

The release record is the gate: moving it to Approved is the approval, and who may move it is the record's permission, not a CI setting. Everyone sees which releases are staged, approved or blocked, the same way they see their tickets.

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

Stage 3 · Ship

Deploy fires from the approval

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 and the audit entry. When someone asks who shipped 1.42 and how anyone knew it was healthy, you open the run.

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, next to the tickets it ships.
Recorded: the approval is a state change with an actor and a timestamp, written to the record's activity trail where the whole team can find it later.
Carried with evidence: the same record holds version, risk and target date, so the approver decides with the context attached.
Conspicuous exceptions: the deploy lane fires from the Approved transition. Keep production credentials inside the workflow and a deploy with no run behind it stands out.

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 for exact software and optional implementation prices.