Production deployment

This project is set up for Vercel as the primary host for the backend (Express serverless entry) and web (SvelteKit). Supabase remains the database and auth provider.

Orchestrator workers (BullMQ) are not run on Vercel: when backend/config/orchestratorFlows.ts uses transport: “bullmq” for integration refresh or notification email, deploy separate always-on processes (for example on Railway) that share the same Redis and Supabase credentials as the API. See Orchestrator workers and Orchestrator workflows.

What you need

• Supabase project (URL, anon key, service role key)
• Vercel projects for backend/ and web/ (or your chosen host, with equivalent env injection)
• Optional: managed Redis if you set CACHE_PROVIDER=redis or if you use BullMQ orchestration — point REDIS_* at a host reachable from both the API and any worker processes
• Optional: one or more worker hosts for BullMQ flows (see Railway (orchestrator workers))

Secrets and configuration

• Never commit real secrets. Use backend/.env.development.example and backend/.env.production.local (gitignored) locally; use the Vercel dashboard (or another host’s secret store) in production.
• Mirror the same variable names as in backend/config/GlobalConfig.ts (via getEnv / getEnvBoolean / getEnvNumber).
• CORS: set FRONTEND_DOMAIN_URL without a trailing slash; include apex and www in ALLOWED_FRONTEND_ORIGINS when both are used. Align the web app’s VITE_API_BASE_URL with BACKEND_DOMAIN_URL.

Deploy with Vercel

Use the detailed CLI and project settings on Vercel. From the repository root:

pnpm vercel:deploy:backend:prod
pnpm vercel:deploy:web:prod

After deploy, configure OAuth redirect URIs, webhooks, and any third-party dashboards to use your production API URL.

Next steps