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
What you can do today
Everything a gated release needs
All of this is live in the product now.
Playbooks from templates
Versioned templates with BEFORE, DURING and AFTER phases and steps; every release gets its own plan.
Four-eyes approvals
Sign-off per plan or per step, with a comment. Turn on four-eyes to require two different Approvers.
Roles & permissions
Viewer, Approver, Template manager and Admin, enforced on the server.
Audit log & evidence
Evidence attached to each step and an append-only record of who did what, and when.
Pipeline gate, API & MCP
A gate your pipeline polls until the plan is approved, plus API tokens for the REST API and the MCP server.
Plans from a tag
TeamNative GitHub App, GitLab and Azure DevOps integrations turn a tag into a plan and report status back.
Block the deploy
BusinessGitHub deployment protection rule, GitLab protected-environment approvals (GitLab Premium) and an Azure DevOps environment check.
Sign-in & company SSO
Email, Google, GitHub or Microsoft sign-in; company SAML or OIDC SSO on Business.
Team invites
Invite teammates by email and give each one the roles they need.
Outgoing webhooks
HMAC-signed events for your own chat, dashboards or tooling.
Hosted in the EU
Your data stays in the EU.
Simple plans
Free, Team, Business and Enterprise per workspace, with a 14-day trial and no card required.
Coming soon
On the roadmap
Jira Service Management & ServiceNow
Open or link a change request, sync approvals and the audit trail, and wait for CAB approval before deploying.
SCIM user provisioning
Create and remove workspace members automatically from your identity provider.
Azure DevOps pull request statuses
See the plan’s status directly on the pull request.
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 with any CI/CD that can make an HTTPS call. On GitHub, GitLab or Azure DevOps, the native integrations do this for you.
# .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
Connect GitHub, GitLab or Azure DevOps per workspace on the Integrations page. Team plans create plans and report statuses; Business also blocks the deploy until the plan is approved.
GitHub
- GitHub App: a tag or release creates a plan from a templateTeam
- Check run on the commit, updated as the plan movesTeam
- Deployment protection rule: the deploy waits until approvedBusiness
GitLab
- Tag pipelines create plans; commit statuses on the commitTeam
- Protected-environment deployment approvals via the API (needs GitLab Premium)Business
Azure DevOps
- “Code pushed” service hook: a tag creates a plan; Git commit status links to itTeam
- “Invoke REST API” environment check that holds the stage until approvedBusiness
Coming soon: Jira Service Management and ServiceNow change requests.
No native integration needed? The pipeline gate works on every plan, including Free.
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.
Sign-in your way
Email and password with verification and password reset, Google, GitHub or Microsoft sign-in, and company SSO (SAML or OIDC) on Business.
Secrets protected
Passwords with bcrypt; session and API tokens as SHA-256 hashes; stored third-party secrets encrypted with AES-256-GCM.
Hosted in the EU
Your data stays in the EU.
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.
Details in the security overview →
Pricing
Simple pricing per workspace
Start free. Viewers are always free; only members who approve, manage templates or administer count. Prices excl. VAT.
Free
Try the playbook with a small team
€0forever
- 3 members (beyond Viewers)
- 2 active plans
- 1 template
- 30-day audit history
- Four-eyes approvals
- Pipeline gate API
- 1 outgoing webhook
- Community support
Team
Most popularFor one product team shipping every week
€49per workspace / month
14-day free trial, no card required
- 10 members (beyond Viewers)
- 25 active plans
- 10 templates
- 1-year audit history
- Everything in Free
- GitHub, GitLab and Azure DevOps integrations: plans from tags, commit and check-run statuses
- 1-year audit log
- Email support
Business
For several teams and regulated releases
€149per workspace / month
14-day free trial, no card required
- 40 members (beyond Viewers)
- Unlimited active plans
- Unlimited templates
- 3-year audit history
- Everything in Team
- Deployment blocking: GitHub protection rules, GitLab environment approvals, Azure DevOps environment checks
- Unlimited plans and templates
- 3-year audit log + export
- Company SSO (SAML or OIDC)
- Priority support
Enterprise
Custom contract
Custom
- Unlimited members, plans and templates
- Custom audit log retention
- Everything in Business
- SSO set-up help (SCIM planned), data residency
- SLA, DPA, invoice billing
All prices in EUR, excluding VAT. Paid plans start with a 14-day free trial without a card; without a card the workspace returns to Free when the trial ends. Cancel any time, effective at the end of the period. See the Terms and the cancellation policy.
Ship with sign-off
Create a workspace, invite your Approvers and run your next release through the default playbook.