Environment Strategy

Two Supabase projects, three Cloudflare Pages projects, three branches.

Branch → environment matrix

Branch	Cloudflare project	Supabase project	Trigger
develop	DEV	qr-setu-dev (dyhjofjjuazhyqcvlrkx)	auto on green CI
uat	UAT	qr-setu-dev (shared with DEV)	manual workflow_dispatch
main	PROD	qr-setu-prod (ygmqxyrbnemhwkiyoboc)	manual workflow_dispatch

DEV and UAT share the Dev Supabase project. Only PROD is isolated (real user data). Each build injects its own VITE_SUPABASE_*.

Secrets & env

• .env.test — committed, dummy values only, for the test runner.
• .env.local — real DEV VITE_SUPABASE_*, never committed.
• .env.example — documents every server secret the functions read: SUPABASE_SERVICE_ROLE_KEY, SUPABASE_DB_URL, CLOUDFLARE_API_TOKEN, CLOUDFLARE_ZONE_ID, ENVIRONMENT, ENABLE_DEBUG_LOGS.
• No hardcoded production-fallback URL in the client — an E2E/cold-stack retry must never reach a real project.

CI/CD pipelines (target)

• Separate pipelines: frontend-ci.yml (build-and-test + sonar-scan + e2e-smoke + auto deploy-dev), reusable deploy.yml + deploy-uat.yml/deploy-prod.yml (workflow_dispatch + verify-ci), and backend-ci.yml (path-filtered supabase/**) + deploy-backend-prod.yml.
• Gates: SonarQube Community (GHA service container, baseline-gated) + CodeQL + Dependabot + secret scanning + DAST; bundle-size + Web-Vitals + load-test.
• Branch protection: PR + CODEOWNERS + required checks.

Cloudflare gotchas

• Each Pages project's "Production branch" must be renamed dev / uat / production.
• Bot Fight Mode can 403 smoke checks — allowlist the checker.

See Deployment & Promotion for the manual promotion runbook.