Deployment

The frontend runs on Vercel; the backend runs on Convex Cloud. They deploy separately.

Backend


npx convex deploy

This pushes functions, the schema and cron definitions to production. Convex refuses a deploy that would break the schema against existing data — treat that refusal as correct and write a migration.

For a development deployment, npx convex dev watches and pushes continuously.

Frontend

Vercel builds from the repository. A push to the default branch deploys to production; a pull request gets a preview deployment.

Both need NEXT_PUBLIC_CONVEX_URL and NEXT_PUBLIC_VAPID_PUBLIC_KEY set in Vercel’s project settings — a preview pointed at the production Convex deployment will read and write live data.

Order

Deploy the backend first

New frontend code often calls functions that do not exist yet. Deploying the backend first means the old frontend keeps working against the new backend.

Then deploy the frontend

Removing or renaming a Convex function is the reverse: change the frontend first, deploy it, and only then remove the function.

Continuous integration

Every push runs typecheck, unit tests, the production build, a mobile layout check at 360px, and an audit that fails on new critical or high advisories.

Before a tournament

Take a backup — see Backup and Restore
Deploy well before the day, never on it
Send a test email and a test push notification
Open the tournament on a phone and confirm the draw loads