Give every deployment a playbook.
A Deployment Request is to shipping what a PR is to code, but it goes further. Group multiple products into one release, assign approvals to the right roles, and track every deployment from kickoff to completion.
Sound familiar?
“Wait, this was tested in staging first, right?”
“What all needs to go out with this?”
“Who approved this? I thought someone had eyes on it.”
“Something's off in prod. Who shipped last and when?”
No one has codified the deployment process. Versioner is your deployment process codified.
The Deployment Request
Structure that doesn't slow you down.
A PR tells your team: “I want to merge this code - please review.” A Deployment Request says: “I want to deploy this version - please sign off.” Same shape, familiar mental model. PRs didn't slow teams down, they added accountability and a shared record. DRs do the same for shipping.
A DR defines what's shipping - which products, which versions, who needs to approve it, and the context behind it: release notes, issue links, what's changed. Whether you're shipping one product or a coordinated release of five, required approvals aren't advisory. Until they're in, the deployment doesn't go.
Approval gates
Required approvals block the deployment.
Add a required approval slot to a DR and you're not just asking someone to sign off, you're creating a gate. Until all required approvals are in, the versions in that DR cannot be deployed. Not advisory. An actual block.
Required approvers are notified the moment a DR is in progress — a direct link to review and act, no digging required. When they approve or reject, the DR creator is notified with the result.
CI/CD pipeline
deploy step reached
Versioner call
product · version · env
DR check
open DR for this version?
All approvals met
approvals complete
Approval pending
report only mode · not enforced
Approval pending
enforced mode · approval required
Deployment proceeds
deploy step runs
Blocked
Some deployments aren't one product. They're three.
A new API contract requires a new client. A caching layer change needs the product and the frontend to land together. This is where DRs go further than the PR model: a PR maps to one codebase, but a DR can represent an entire release train.
Three products might also mean three engineers - or three teams - each asking “are you ready? did yours go?” A DR gives everyone the same live view: what's approved, what's pending, whether it's safe to proceed. The coordination overhead collapses. One set of approvals covers the coordinated whole.
API Service
v2.15.0
Breaking contract change
Frontend
v3.2.1
Consumes new API contract
Cache Layer
v1.4.0
Schema-aligned flush
Version sign-offs. Without the spreadsheet.
Version Approvals capture who signed off on a version and when: QA, Security, whoever you need. That record travels with the version: available for audits, compliance reviews, or the post-incident question about what was validated before something shipped. No spreadsheet required.
Version Approval rules, available on the Enforce tier, turn these into a hard gate.
Version approvals · API Product v2.14.1
Regression suite passed
No new attack surface
Same decision engine. Broader authority.
On this tier, the decision engine has one job: check whether a version being deployed has its required DR approvals in place, and block it if not. That's a real gate, not advisory.
What you can't do yet is mandate that every deployment must have a DR in the first place, or define schedule rules, flow rules, and soak times that run org-wide. That's Deployment Rules: the same engine, with the authority to enforce your standards automatically, everywhere.
Explore Deployment RulesSchedule rules
No deployments on Fridays. Prod locked during the holiday freeze.
Flow rules
Staging must be hit before prod. Require a 24-hour canary soak.
DR required
Mandate that every deployment is tied to an open Deployment Request.
Version approval required
A version must carry a QA sign-off before it can reach production.
Pre/post deployment steps
Required steps that gate the deployment: database migrations before, smoke tests after. Each step is logged with who completed it and when.
Everything. Free for 30 days.
Everything above is included on the Protect plan. Every plan starts with a 30-day full trial, unlocked from day one. No credit card required.
Start 30-day trial- Deployment Requests
- Version Approvals
- Role-based approvals (RBAC)
- Deployment Rules
- DR Templates
- Pre/post deployment steps
- Flow rules & soak times
- Schedule rules
- Advisory preflight (MCP)