Staging and CI setup

Before adding anything to GitHub, collect the three required values from the Dashboard.

1. Open the Dashboard — /keys/dashboard. Sign in with GitHub if prompted.
2. Go to Copy for CI — In the left sidebar, click Copy for CI (or open /keys/dashboard/copy-for-ci).
   • If you get a 404 or don't see "Copy for CI" in the sidebar, the dashboard may not have that page yet. Use Projects → click your staging project name → on the project page, scroll to the Copy for CI (GitHub Secrets) section.
3. Choose your staging project — On the Copy for CI page, click your staging project name. You'll land on that project's page with the Copy for CI section in view.
4. Copy the three required values: Project ID (Copy button), Environment ID (Copy button), and Gateway Key (click Create key in Access, then copy the key when shown—you only see it once). Store the key somewhere temporary until you add it to GitHub.
5. Optional later: note the route ID for smoke tests; from Routes/Policies pick a blocked model + provider for policy tests (see section 2).

Add these as GitHub (or GCP) secrets in section 2 and wire them into your workflow in sections 3–6.

Create these in the Dashboard before storing secrets.

• Non-production project or environment — Prefer a dedicated staging project; or add a staging environment to your existing project.
• Route for smoke tests (if you will run smoke) — Note the route ID (e.g. interactive) from Project → Routes.
• Optional blocked-model pair — A model + provider your staging policies reject (e.g. a model not on the allowlist).

Store secrets in your app repo: Settings → Secrets and variables → Actions → New repository secret. In workflows, map them to env vars (e.g. RESTORMEL_GATEWAY_KEY: ${{ secrets.RESTORMEL_GATEWAY_KEY_STAGING }}). GCP Secret Manager: same names, inject in the workflow as you do for app secrets.

Gateway Key (required)

Project ID (required)

Environment ID (required)

Smoke route ID (optional)

Blocked model ID (optional)

Blocked provider type (optional)

Keys base URL (optional; usually omit)

In your nightly workflow (e.g. nightly-gate-audit.yml), add env from staging secrets and run:

env:
  RESTORMEL_GATEWAY_KEY: ${{ secrets.RESTORMEL_GATEWAY_KEY_STAGING }}
  RESTORMEL_PROJECT_ID: ${{ secrets.RESTORMEL_PROJECT_ID_STAGING }}
  RESTORMEL_ENVIRONMENT_ID: ${{ secrets.RESTORMEL_ENVIRONMENT_ID_STAGING }}

# then:
run: npx @restormel/validate
# optionally: pnpm run smoke:restormel

Add smoke:restormel to nightly only if staging is stable and you're comfortable with nightly traffic hitting it.

Safer at first: After deploy, an operator runs pnpm run smoke:restormel manually and checks the dashboard.

Automated: Add a post–health-check step in deploy; inject staging secrets; run pnpm run smoke:restormel. Don’t make it deploy-blocking until the path and staging project are reliably healthy.

• Phase A — Secrets: RESTORMEL_GATEWAY_KEY_STAGING, RESTORMEL_PROJECT_ID_STAGING, RESTORMEL_ENVIRONMENT_ID_STAGING. Enough for PR doctor and npx @restormel/validate.
• Phase B — Add RESTORMEL_SMOKE_ROUTE_ID_STAGING. Enough for post-deploy or nightly pnpm run smoke:restormel.
• Phase C — Add RESTORMEL_SMOKE_BLOCKED_MODEL_ID_STAGING and RESTORMEL_SMOKE_BLOCKED_PROVIDER_TYPE_STAGING after staging policies are stable.

Nightly: add staging env and npx @restormel/validate (and optionally pnpm run smoke:restormel) to nightly-gate-audit.yml or equivalent. Post-deploy: add an optional step to deploy.yml that injects secrets and runs pnpm run smoke:restormel; don’t gate deploys on it until you’re confident.

See Verification strategy for CLI and smoke details; Phase 6 — Go live for the smoke script.