Deploy on Vercel
Set up the six Node-hosted starters and their production databases.
Use this guide for the Supabase, Convex and Neon kits. Start from the environment example and README in the repository you chose.
1. Configure the backend
Supabase: create or select your project, link the CLI, and apply the repository's migrations from apps/database. Include the MCP migration. Configure Auth, email delivery and callback URLs for your own domain.
Convex: select your production deployment and publish the schema, functions and both gateway components. Set MCP_APP_URL on the backend to the website's canonical origin. Keep the existing Convex Auth providers and signing keys when updating an existing app.
Neon: create or select your Postgres database and apply the migrations using the migration connection. Use the runtime connection strings for the website. The TanStack Neon kit has separate auth, application and worker roles; preserve their RLS boundaries.
The two Neon repository names still include planetscale. You don't need a PlanetScale database for these versions.
2. Import the repository
Create a Vercel project from your own repository. Check its root directory, package manager and build command against that kit's README and Vercel configuration.
These are monorepos. Some projects build from the repository root and others use apps/web. Keep the configuration shipped with your kit rather than applying one setting to all six.
3. Add production environment variables
Set the database/backend credentials, auth configuration, app origin and email configuration. Use the exact variable names from the kit's env example.
The app origin is NEXT_PUBLIC_SITE_URL for Next.js Supabase and Convex, NEXT_PUBLIC_APP_URL for Next.js Neon, APP_URL for TanStack Supabase, and APP_BASE_URL for TanStack Neon. TanStack Convex uses the app/backend configuration documented in its README.
For Supabase, the browser gets the public key. The secret/service-role key belongs only on the server. For Neon, the migration owner's connection is used by migrations, not by the normal application process.
4. Deploy and test
Build using the repository's normal command. Test a preview with its own callback configuration, then publish production.
Open /login and /sign-up, create a test account, verify its email, and create a workspace. On the connection page, confirm that the displayed server URL belongs to the deployment you intended.
Convex MCP addresses use the backend's .convex.site origin. The other four Vercel-hosted MCPs use the website origin. Follow connect an agent to test consent and a tool call.