Check staging before production promotion

API keys can start and read scans on every plan, subject to the workspace's limits. The script below calls POST /api/v1/scans, then reads the report and blocker endpoints. It uses the staging URL and marks the environment as staging.

The Agency-only deploy hook at POST /api/v1/hooks/scan only starts an asynchronous scan. It does not evaluate the completed report or prevent a production release. Free workspaces are limited to one custom site; bind the intended site in advance. See the API reference for the current endpoint and plan contracts.

1. Create an API key in Settings → API keys, and store it as the CI secret LAUNCH_READY_KEY. Do not put a key in a URL or source file.
2. Use a Launch Ready project for the site you intend to check. Set PROJECT_ID to its id and STAGING_URL to the publicly reachable staging origin. Resolve Free site binding before running CI.
3. Set MIN_PAGES_CHECKED to the minimum pages that must be checked for this release, based on your own expected coverage baseline. The example fails closed if the scan is capped, page counts are missing, or the minimum is not reached.
4. Give each staging deployment a stable, unique DEPLOYMENT_ID. It is sent as the idempotency key, so retrying the same CI job reuses its scan instead of starting another one.

node examples/deployment-checks.mjs

The reusable Node.js example requires Node.js 18 or later and uses the built-in fetch API. Set MAX_WAIT_SECONDS to override its five-minute default. API errors, malformed responses, and failed scans do not return a successful check.

Run the scan job only after the staging deployment succeeds. Make the production job depend on that job and protect its GitHub production environment with required reviewers. Replace the placeholder promotion command with your authorized deployment step.

jobs:
  staging-check:
    needs: deploy-staging
    env:
      LAUNCH_READY_KEY: ${{ secrets.LAUNCH_READY_KEY }}
      PROJECT_ID: ${{ vars.PROJECT_ID }}
      STAGING_URL: ${{ vars.STAGING_URL }}
      DEPLOYMENT_ID: ${{ github.run_id }}-${{ github.run_attempt }}
      MIN_PAGES_CHECKED: ${{ vars.MIN_PAGES_CHECKED }}
    steps:
      - uses: actions/checkout@v4
      - run: node examples/deployment-checks.mjs

  promote-production:
    needs: staging-check
    environment: production
    steps:
      - name: Promote the validated revision
        run: ./your-authorized-production-promotion-command

Configure required reviewers for the production environment. The check script never promotes a release. If it reports ready_with_warnings, the approver must record the warning disposition and any accepted exception in the release record before approving.

Synthetic fixtures and tests for these outcomes live in the fixture set and its test. They demonstrate local policy behavior only, not hosted availability or provider delivery.

npx vitest run tests/deployment-checks.test.ts

Scan coverage depends on plan limits, reachable pages, rendering, and enabled checks. A non-capped scan still cannot prove that every route, user journey, form submission, or production configuration was checked. Choose the page minimum for your site, investigate unexpected coverage changes, and complete relevant manual, security, accessibility, legal, and rollback reviews.

Keep staging and production URLs distinct, protect API credentials as CI secrets, and avoid publishing customer reports. A scan is an input to your release process, not a certification or guarantee.