Vercel 3,061 employs the Next.js 10,514 team, and its platform is the reference implementation of the framework's hosting contract. Connect a Git 1,932 repository and there is no build script, Dockerfile or server configuration to write: the project is detected, next build runs, and the output is split into static assets served from the CDN, prerendered pages, and functions for the routes that must run per request. Every push to the production branch redeploys, and every branch and pull request gets its own URL to click through. The same detection works from a terminal after npm 2,036 i -g vercel@59.25.0: vercel deploys a preview and prints its URL, vercel --prod goes straight to production. Environment variables are scoped separately to Production, Preview and Development, so a preview can point at a staging database — though NEXT_PUBLIC_* values are still inlined during the build (Environment Variables), so changing one means a redeploy, not a restart.
What you are buying is infrastructure for features that otherwise need assembling by hand: revalidated pages persisted to durable storage and pushed back out to the CDN rather than living on one machine's disk, a managed image service behind /_next/image, Partial Prerendering serving the static shell from the CDN while a function streams the dynamic holes into the same response, and proxy code running close to the visitor. None of it is private machinery: Vercel integrates through the same public Deployment Adapter API (adapterPath) any platform may use, and is one of two adapters the Next.js team calls verified — open source, and running the full compatibility test suite. The other is Bun 73,307 .
Nothing in this book requires Vercel: the rest of Deployment self-hosts every feature used so far. What does not transfer is the global network and the durable shared cache.