Skip to content

Frontend Deployment

Build process

The dashboard is a Vite/React/TypeScript SPA deployed to Cloudflare Pages (project name dashboard). One build serves both eccdps.org and training.eccdps.org.

bash
cd ecc-dps-dashboard
npm run build                  # tsc -b && vite build → dist/
npx wrangler pages deploy dist --project-name=dashboard

npm run build runs the TypeScript project build first, so a type error aborts the deploy — treat the build as the release gate.

Environment configuration

The browser bundle can only contain public configuration:

VariablePurpose
VITE_DPS_API_BASE_URLThe public API URL (production: https://api.eccdps.org). Set per Pages environment (Production/Preview).
VITE_APP_ENVOptional explicit app-environment hint (demo); otherwise derived from the hostname (demo.eccdps.org → demo).

Never put SUPABASE_KEY (service role), the JWT secret, or DPS_API_KEY in the bundle or in Pages build variables — the browser never receives them. The Supabase anon key is served at runtime to signed-in sessions via /training/realtime-config.

The .env.example in the repo contains only the public API-base template; a local .env.local may set DPS_API_BASE_URL/DPS_API_KEY for the dev proxy only.

Custom domains and DNS

  • eccdps.org and training.eccdps.org are custom domains on the same Pages project (CNAME → dashboard.pages.dev, proxied). SPA fallback is on, so Pages serves the same index.html to both hosts and the app boots the correct application from the hostname (training.* → Training Center).
  • No _redirects file or per-domain build settings are required; the app self-selects by hostname/path.

Deployment verification

  1. Open https://eccdps.org/dashboard — sign-in works, sidebar renders.
  2. Open https://training.eccdps.org/training — Training Center boots (not a white screen), trainer/trainee roles resolve.
  3. Confirm the bundle talks to the right API (network tab: requests to https://api.eccdps.org, credentials included).
  4. Run the production smoke test.

Rollback

Cloudflare Pages keeps previous deployments; redeploy the previous production build from the Pages dashboard. Because the frontend only consumes API contracts, rolling the frontend back is safe as long as the previous build is compatible with the current API (the project keeps API response shapes backward compatible).