Staging Environment Setup

Executive Overview — all summaries for decision-makers.

Staging ermöglicht Tests vor Production-Deploy.

Blueprint

Datei: render-staging.yaml (Repo-Root)

Services:

Service	Name	Domain (geplant)
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

Hinweis: Staging wurde bereits manuell provisioniert (Aug 2026). Siehe STAGING-STATUS für IDs, URLs und offene Schritte (DB-Link, Azure, DNS).

DNS (Cloudflare — nach MQA-Migration)

Type	Name	Target
CNAME	`staging.portal`	Render Frontend Staging URL
CNAME	`staging.api`	Render Backend Staging URL

Environment

Kopiere Production-Env nicht 1:1. Staging braucht:

Eigene DATABASE_URL (leere oder anonymisierte Kopie)
Eigene Azure AD App (staging redirect URI)
Eigener 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

Kein Production ANTHROPIC_API_KEY mit vollem Budget — Rate-Limits / separates Key empfohlen.

Branch-Strategie (empfohlen)

Branch	Deploy-Ziel
`main`	Production (Auto-Deploy)
`develop`	Staging (Auto-Deploy)

Render: Staging-Services auf Branch develop konfigurieren.

Daten

Option A: Leere DB + prisma migrate deploy (kein Seed in Staging via API)
Option B: Anonymisierter Prod-Snapshot (keine echten E-Mails in Staging!)

Checkliste Staging Go-Live

[ ] Blueprint applied
[ ] Custom Domains + SSL
[ ] OAuth Staging-App
[ ] Smoke-Tests grün
[ ] Team-Zugang dokumentiert