Staging Environment Setup

Executive Overview — all summaries for decision-makers.

Staging enables testing before production deploy.

Blueprint

File: render-staging.yaml (repo root)

Services:

Service	Name	Domain (planned)
Postgres	`mqa-postgres-staging`	internal
Backend	`mqa-backend-staging`	`staging.api.mqa.group`
Frontend	`mqa-frontend-staging`	`staging.portal.mqa.group`

Deployment

Render Dashboard → New Blueprint Instance
Repo: MQA-Group/MQA-Governance-Portal
Branch: develop
Blueprint path: render-staging.yaml

Note: Staging was already provisioned manually (Aug 2026). See STAGING-STATUS for IDs, URLs, and open steps (DB link, Azure, DNS).

DNS (Cloudflare — after MQA migration)

Type	Name	Target
CNAME	`staging.portal`	Render frontend staging URL
CNAME	`staging.api`	Render backend staging URL

Environment

Do not copy production env 1:1. Staging needs:

Own DATABASE_URL (empty or anonymized copy)
Own Azure AD app (staging redirect URI)
Own JWT_SECRET, CRON_SECRET
CORS_ORIGIN=https://staging.portal.mqa.group
VITE_API_BASE_URL=https://staging.api.mqa.group/api
VITE_APP_ENV=staging

Do not use production ANTHROPIC_API_KEY with full budget — rate limits / separate key recommended.

Branch Strategy (recommended)

Branch	Deploy target
`main`	Production (auto-deploy)
`develop`	Staging (auto-deploy)

Render: configure staging services on branch develop.

Data

Option A: Empty DB + prisma migrate deploy (no seed in staging via API)
Option B: Anonymized prod snapshot (no real emails in staging!)

Staging Go-Live Checklist

[ ] Blueprint applied
[ ] Custom domains + SSL
[ ] OAuth staging app
[ ] Smoke tests green
[ ] Team access documented