Before · During · After deployment
Approval-gated deployment playbooks for GitHub, GitLab and Azure DevOps teams
Stop approving production deploys with a thumbs-up in chat. Every release runs through a playbook: evidence per step, sign-off by real Approvers (four-eyes where it matters) and a pipeline gate that keeps the deploy waiting until the plan is approved.
- Four-eyes per plan or per step
- Gate fails closed
- HMAC-signed webhooks
- Audit log of everything
Product tour video
How it works
One playbook, three phases, nothing skipped by accident
Every plan is a snapshot of your template: 19 steps by default, each required or optional, each with the evidence it needs. The plan as a whole is approved first; then each phase opens only when the previous one is complete.
- 8 default steps
Before deployment
Scope, green CI, reviews, scans and a written rollback plan, all signed off before anyone presses deploy.
- Release scope and notes drafted
- CI is green on the release commit
- Every included change has a code review approval
- Security and dependency scans pass
- Rollback plan written
- Database migrations reviewed with a down scriptoptional
- Backup or snapshot takenoptional
- Stakeholders told about the deployment windowoptional
- 6 default steps
During deployment
A go or no-go decision, the deploy itself and a watched run. Your pipeline waits at the gate until this phase opens.
- Go or no-go decision
- Trigger the deploy
- Watch the run to completion
- Smoke tests on the target environment
- Staged or canary rolloutoptional
- Live status update to the teamoptional
- 5 default steps
After deployment
Health checks, release notes and a final sign-off, so “done” means verified, not merely shipped.
- Health check for the first hour
- Release tag and notes published
- Deployment signed off as complete
- Linked issues and work items closedoptional
- Short retro notesoptional
Evidence goes in per step; optional steps can be proposed for skipping with a reason, and the skip needs sign-off too. A rejection stops the step and starts a new round. Template managers edit the default template; every save is a new version, and running plans keep the steps they started with.
Four-eyes principle
Two different people, where it matters
Switch four-eyes on for the whole plan, or only for the risky steps: the default template marks the rollback plan, the go or no-go decision and the final sign-off.
- A four-eyes approval needs two distinct Approvers.
- Whoever submitted the evidence (or proposed the plan or skip) can never approve it.
- Clear badges and “1 of 2 approvals” progress on every step.
- Approvals, comments and the approver count land in the audit log and the webhook payload.
- Source
- Workflow, pipeline job or release stage
- Evidence needed
- Run link and who triggered it
Evidence: github.com/acme/web/actions/runs/99887766
Submitted by Tom Templates
✔ Approved Alice Approver — “Run started cleanly”
Roles & workspaces
The right people sign off, everyone else can follow along
Multi-tenant workspaces with four roles. A person can hold several; only signed-in Approvers can approve.
Viewer
Read-only: follows plans, steps and status.
Approver
Approves or rejects plans, steps and skip proposals, with a comment.
Template manager
Edits the playbook template. Every save becomes a new version.
Admin
Invites people, assigns roles, manages connections and tokens. Can only approve when also an Approver.
Pipeline integration
Your deploy waits at the gate
Pipelines poll GET /api/gate/<plan> with a workspace API token. The answer is allow: true only once the plan (or a given phase or step) is approved.
- Fails closed. Missing, invalid or revoked token, unknown plan or any error: allow is false.
- Per phase or step. Wait for plan approval, the Before phase, or everything up to a specific step.
- Signed status webhooks. JSON POST on every plan and step change, signed with HMAC-SHA256 (X-Playbook-Signature-256), with a delivery log.
- Tokens stored hashed. Created and revoked on the Connections page.
Works today with GitHub Actions; a demo workflow shows a deploy job waiting for approval.
# .github/workflows/deploy.yml
- name: Wait for the Deployment Playbook
timeout-minutes: 60
env:
TOKEN: ${{ secrets.PLAYBOOK_API_TOKEN }}
PLAN: ${{ inputs.plan_id }}
run: |
URL="https://deployment-playbook.com/api/gate/$PLAN?phase=during"
until curl -fsS -H "Authorization: Bearer $TOKEN" "$URL" \
| jq -e '.allow == true'; do
sleep 15 # gate closed: keep waiting
done
- name: Deploy
run: ./deploy.sh{ "allow": false, "planStatus": "waiting_for_approval", ... }
{ "allow": true, "planStatus": "in_progress", "currentPhase": "during", ... }Integrations
Fits the pipelines you already run
The gate is plain HTTPS, so any CI/CD can call it today. Native integrations are on the way.
GitHub
- Pipeline gate for GitHub ActionsAvailable
- Signed status webhooksAvailable
- Native GitHub App: deployment protection rules and check runsComing soon
GitLab
- Gate via any pipeline job (curl)Available
- Native protected-environment approvals and commit statusesComing soon
Azure DevOps
- Gate via “Invoke REST API” environment checkAvailable
- Native PR statuses and service-hook mappingComing soon
Audit log & security
Every decision on the record
When someone asks “who approved this deploy?”, the answer is one click away.
Append-only audit log
Plans, steps, approvals, rejections, skips, roles, invites, templates, tokens and webhooks, with who and when.
Workspace isolation
Every read and write checks workspace membership first; other tenants’ plans simply don’t exist for you.
Server-side permissions
Roles are enforced on the server, not just hidden in the UI.
Hashed secrets
Passwords with bcrypt; session and API tokens stored as SHA-256 hashes.
Signed webhooks
Outgoing payloads carry an HMAC-SHA256 signature over timestamp and body.
Verified incoming hooks
GitHub, GitLab and Azure DevOps webhooks are verified per workspace; unverified ones are rejected.
Ship with sign-off
Create a workspace, invite your Approvers and run your next release through the default playbook.