FeaturesGovernance

Define once. Enforce everywhere.

Deployment Requests set the playbook for a single deployment. Deployment Rules go further — enforce change freezes, staging requirements, approval gates, and flow constraints across every deployment, org-wide, automatically.

Start 30-day trialNo credit card required.

Sound familiar?

How did this go out? I thought we weren't supposed to deploy on Fridays.

Did this skip staging? If we could only guarantee we always deploy and soak there first.

You remembered to do the database migration first right? Uh oh.

The auditor's asking for our controls around deployments but I can't find the doc.

Your org has rules around deployment. They're just not enforced anywhere.

Deployment Rules

A mandatory checkpoint at every deployment.

Versioner is a decision engine your pipelines are wired to consult before proceeding. Not a lock on your infrastructure — a mandatory checkpoint built into your deployment flow. Your pipeline reaches a deploy step, checks in with Versioner, and gets a verdict: clear to proceed, blocked, or here's what's missing.

Deployment Rules define your constraints. They evaluate automatically on every deployment, org-wide.

CI/CD pipeline

deploy step reached

Rules check

all rules evaluated

Rules pass

deployment proceeds

Violation detected

report mode · logged, proceeds

Violation detected

enforced mode · blocked

Four rule types

Each one maps to a real failure mode.

Every rule type exists because someone's runbook had a section for it. Deployment Rules make that section automatic.

Schedule rules

Define windows when deployments are allowed or blocked. Change freezes, peak traffic blackouts, release windows.

e.g. "No deploy Fridays." Prod locked Dec 23–Jan 2. No deploys during the board demo.

Flow rules

Define prerequisite environments and enforce the path a version must take to reach production. Set minimum soak times at each stop.

e.g. Require staging before prod. 36-hour canary soak before promoting.

DR required

Mandate that every deployment must be associated with an open Deployment Request before it can proceed.

e.g. No version of any product can reach production without an open DR.

Version approval required

Require a version-level approval from a specified role before that version can be deployed to target environments.

e.g. Versions must carry a QA sign-off before reaching production.

REPORT MODE

Not ready to block? Start in report-only mode.

Every deployment is still evaluated against your rules. Violations are logged and surfaced — but nothing is blocked. Build confidence, understand the blast radius, then flip to Enforced when you're ready.

Pre/post deployment steps

Not suggestions. Gates.

Add required steps to a Deployment Request and they become blocking conditions. A pre-deployment step must be completed before the deployment can proceed. A post-deployment step must be completed before the DR can close.

Database migrations before you ship. Smoke tests after. Maintenance banners up before, down after. Every step is logged with who completed it and when — an auditable record of exactly what happened and in what order.

Steps are a first-class feature of Deployment Requests, available on the Enforce tier.

DR-142 · API Product v2.15.0 → production

Pre-deployment

Enable maintenance banner

DONE

Migrate the database

REQUIRED

Post-deployment

Run smoke tests

PENDING

Deployment blocked until pre-step is complete.

DR Templates

Define the process once. Every deployment follows it.

DR Templates pre-configure Deployment Requests with your standard steps and approval requirements. Pick a template when opening a DR and it's already set up — the right pre-steps, the right approvals, the right post-steps. Nobody has to remember what a production deployment requires.

Pair with the DR Required rule: mandate a DR for every deployment, and let the template carry the institutional knowledge.

Flow rules

Enforce the order. Require the soak.

Define prerequisite environments a version must pass through before reaching production. Require staging before prod. Set a minimum soak time so a version has to survive 24 hours in canary before it can advance. Prevent skipped environments, premature promotions, and the race conditions that happen when teams move too fast or out of order.

dev

staging

canary

24h min soak

production

1h min soak

Version must pass through each prerequisite. Soak time must expire before promotion.

Advisory preflight

Ask before you ship.

Ask your AI coding agent — or ask directly — “what would it take to deploy product X to production right now?” Get a readiness report based on your actual rules and current state, without leaving your editor.

Not just a gatekeeper — a guide. The preflight response tells you what's blocking, what's missing, and what steps would clear the path. The category doesn't have this yet.

Available via Versioner's MCP server. Works with Claude Code, Cursor, and any MCP-compatible AI assistant.

preflight · api-service → production

// check_deployment_readiness

can_deploy_now: false

blockers: [

"No deployments on Fridays"

"Production requires an approved DR"

],

suggested_actions: [

"Create a DR targeting production"

"Schedule for Monday or later"

]

Everything. Free for 30 days.

Everything above is included on the Enforce plan. Every plan starts with a 30-day full trial, unlocked from day one. No credit card required.

  • Deployment Rules (all four types)
  • Report-only mode
  • DR Templates
  • Pre/post deployment steps
  • Flow rules & soak times
  • Schedule rules
  • Version approval required
  • Advisory preflight (MCP)