Vercel

In short: A hosting platform specialised in Next.js projects (and other frontend frameworks) — every git push can automatically trigger a new deploy.

In more detail: Projects belong to a “team” or the personal account; each project has its own environment variables, domains and storage connections (e.g. Vercel Blob). The CLI (vercel) can deploy manually in parallel with the automatic Git deploy (vercel --prod) — useful, for example, if the Git commit author is blocked from the automatic deploy.

Our context: The central hosting platform for Emzett — a dedicated account/team was set up, separate from the former partner’s old Bellator Vercel account.

In Depth

Production and preview deployments

Every push to the configured production branch (usually main) automatically triggers a production deploy; pushes to other branches or pull requests, on the other hand, automatically create their own preview deployments — each a completely standalone version of the app reachable under its own URL, isolated from production. This allows a change to be tested live (including real server functionality, not just static HTML) before it’s even merged. Each preview deployment can also have its own environment variables — e.g. a test database instead of the real production database — so that experiments in preview environments stay risk-free with regard to real user data.

Serverless vs. edge functions

On Vercel, Next.js projects run by default on a mix of statically pre-rendered pages (wherever possible, e.g. pages without user-specific content) and serverless/edge functions for everything that has to be computed dynamically per request (API routes, Server Components with database access). The difference between the two function types: serverless functions run in a full Node.js environment (more compatibility, but a slower cold start), edge functions in a leaner runtime distributed closer to the user (faster cold start, but more limited Node.js API support) — which type is used can be controlled per route via export const runtime = "edge". The “cold start” refers to the time until a function that isn’t currently running is ready for a new request — with low traffic (the function is rarely called) this difference is more noticeable than with constantly high load, where functions usually stay “warm” anyway.

Edge network and CDN

Static content (pre-rendered pages, images, CSS/JS bundles) is automatically delivered via a global CDN (content delivery network) — Vercel keeps copies at many geographically distributed locations, so that a user gets the content from the nearest location instead of from a single, potentially distant server. This noticeably reduces loading times, especially for users who are geographically far away from the original server location.

Build process and caching

On every deploy, Vercel runs the complete Next.js build process (next build) in an isolated build environment — dependencies are cached between builds (cache for node_modules) to speed up repeated builds of the same project. If a build fails (e.g. due to a TypeScript error or a missing environment variable), the previous, working production version stays live unchanged — so a failed deploy doesn’t automatically take the app down, it’s simply discarded.

Domains and DNS

Vercel projects automatically get a *.vercel.app subdomain; custom domains can additionally be connected via DNS records (usually A or CNAME records). For production use, a custom domain almost always makes more sense than the automatically generated Vercel subdomain, if only for recognisability and independence from the hosting platform.

See also: Environment Variables, Vercel Blob Storage, DNS records