GuidesTutorial

Release gates

Turn stored evidence into a hard allow or deny decision in CI.

Guides

Release Rules

Release Rules turn PreFlight evidence into a hard release control. Instead of hoping someone ran checks before promoting, CI or Vercel asks PreFlight one question — is this project safe to deploy right now? — and blocks the release when the answer is no.

Gates evaluate stored check runs, Uptime Monitoring samples, revenue snapshots, Database Change Check, and provider probes against a per-project policy. The result is a single allow/deny signal with actionable blockers and dashboard deep links.

How it works

Your CI job or Vercel deploy hook calls the gate endpoint. PreFlight evaluates current evidence and returns:

HTTP 200 with allowed: true when the release is safe.
HTTP 409 with allowed: false and a blocker list when it is not.

Evaluate release readiness. Optional query: ?mode=strict or ?mode=relaxed.

curl -sS -H "Authorization: Bearer pf_live_..." \
  "https://getpreflight.dev/api/v1/projects/<project-id>/deploy-gate?mode=strict"

Example blocked response:

{
  "allowed": false,
  "mode": "strict",
  "project_name": "vibecoder-saas",
  "blockers": [
    {
      "key": "checks_not_clean",
      "severity": "failed",
      "source": "checks",
      "message": "2 failed, 1 warnings.",
      "dashboard_url": "https://getpreflight.dev/dashboard/projects/.../checks"
    }
  ],
  "warnings": [],
  "summary": "1 blocker."
}

Fail your CI job on HTTP 409. Each blocker includes a dashboard_url linking straight to the failing surface.

Strict vs relaxed mode

| Mode | Behavior | Best for | | --- | --- | --- | | `strict` | Warnings **and** failures block the deploy | Production releases | | `relaxed` | Only hard failures block; warnings are reported but allowed | Staging, preview branches, fast internal iterations |

Set the default mode in the gate policy on /dashboard/deploy-gates. Override per request with ?mode=strict or ?mode=relaxed.

In strict mode, allowed requires zero blockers and zero warnings. In relaxed mode, warnings do not prevent allowed: true.

Default policy

When no custom policy exists, PreFlight applies these defaults:

| Setting | Default | | --- | --- | | Enabled | `true` | | Mode | `strict` | | Require Uptime Monitoring | `true` | | Require Payment Sync | `true` | | Block on schema drift | `true` | | Max check age | 24 hours | | Min pass percentage | unset (disabled) |

What a gate can require

Each requirement maps to a blocker source. The policy controls whether that source blocks, warns, or is ignored.

| Requirement | Source | What it enforces | | --- | --- | --- | | Clean checks | `checks` | Latest standard check run is `success`; in strict mode, no warnings | | Max check age | `checks` | Latest check is newer than `max_check_age_hours` — stale evidence blocks | | Uptime Monitoring active | `Uptime Monitoring` | Uptime Monitoring enabled, not paused, last sample clean | | Payment Sync | `revenue` | Recent Revenue Ledger snapshot with no unresolved drift | | Schema drift | `schema` | Supabase Database Change Check is clean | | Provider health | `provider` | No recent failed or warning probe within the check-age window | | Pass-percentage floor | `checks` | Recent pass rate stays at or above `min_pass_percentage` |

Tuning the policy

Real pipelines need escape hatches that do not gut the gate:

| Control | Purpose | | --- | --- | | `warn_only_sources` | Downgrade a whole source (e.g. `revenue`) from blocking to warning while stabilizing | | `ignored_probe_keys` | Exclude specific noisy probes from gate evaluation | | `min_pass_percentage` | Allow a known-flaky suite when overall pass rate stays above a floor | | `enabled: false` | Open gate — returns `allowed: true` with a "policy is disabled" summary | A disabled gate provides no protection. Keep the policy enabled for production projects. Use `warn_only_sources` or `relaxed` mode when you need temporary flexibility without turning the gate off entirely.

Wiring into CI

Create an API key. In Settings → API keys, generate a workspace-owner key. The raw pf_live_… value is shown once. Configure the gate policy. Open Release Rules, select the project, and set requirements for production vs staging. Add a gate step before deploy. Call GET /deploy-gate and fail the job on HTTP 409. Choose a mode. Use strict for production and relaxed for preview branches. Read the blockers. Each entry includes dashboard_url, source, and message for fast triage.

GitHub Actions example

- name: PreFlight release rule
  run: |
    code=$(curl -sS -o gate.json -w "%{http_code}" \
      -H "Authorization: Bearer ${{ secrets.PREFLIGHT_API_KEY }}" \
      "https://getpreflight.dev/api/v1/projects/${{ vars.PREFLIGHT_PROJECT_ID }}/deploy-gate?mode=strict")
    cat gate.json
    if [ "$code" != "200" ]; then
      echo "release rule blocked the release."
      exit 1
    fi

Vercel integration

Add the gate call as a step before vercel deploy --prod, or use a GitHub Action that runs on deployment_status. Pair with Vercel Watch so deployment drift is caught between gate checks.

Trigger a check with POST /projects/:id/checks and an Idempotency-Key before calling the gate when your pipeline just deployed. The gate reads stored rows — it does not run probes itself.