Vercel in production

Vercel is the deployment target for all 18 Next.js applications in the Avo stack. Each site maps to a separate Vercel project linked to its own GitHub repository. Pull requests get automatic preview deployments with isolated environment variables, so a broken schema change never reaches production.

The deployment workflow is: GitHub Actions runs tsc --noEmit and the regression test suite on every push to main. If those gates pass, the Vercel CLI (v34) triggers a production build. The build runs pnpm 9 on Node.js 20. Build times average 2-3 minutes for the marketing site; the larger dashboard sites with more pages take 5-7 minutes.

Example workflow: setting up a new Next.js project on Vercel for a client from scratch. 1. Create the Vercel project with vercel link, set the framework preset to Next.js and the install command to pnpm install. 2. Add all required environment variables via vercel env add for each of production, preview, and development environments. Never skip the preview environment; preview deployments need real (or test) values to function. 3. Pull env vars locally with vercel env pull .env.local before starting development. Commit the .env.example with placeholder values. 4. Push a test PR. Confirm the preview deployment URL is accessible and all environment-dependent features (auth, payments, email) work in the preview environment. 5. Set up a GitHub Actions step that runs tsc --noEmit and the test suite on every push. Gate the Vercel production promotion on both gates passing. 6. After go-live, configure Vercel Analytics and set up an uptime check against the /api/health route. If the route returns anything other than 200, page the on-call.

Environment variables are managed in the Vercel dashboard and pulled locally with vercel env pull. The production set includes 40 variables covering ClickHouse connection strings, Clerk publishable and secret keys, Stripe live keys, Resend API key, and the Argus backend URL. The .env.example files in each repository document every expected variable so a new deployment never silently fails due to a missing key.

The Edge Network handles CDN caching for static assets and ISR-cached pages. Case study pages with revalidate: 3600 stay cached at the edge for up to an hour before revalidation. This keeps Time-to-First-Byte under 50ms for cached pages regardless of the visitor's geography.

Vercel Functions (the Next.js API routes) run on the Node.js runtime by default. The only exception is the middleware layer (src/middleware.ts), which runs on the Edge runtime for sub-5ms auth checks before the request reaches the function.

One operational lesson: Vercel's routing layer can cache stale 404 responses for routes that existed, were deleted, and were re-created. The /api/health endpoint returned a cached 404 after a routing refactor until the deployment cache was purged.