Cloud Computing's own domain covered cloud hosting in general, provider-agnostic terms. Vercel is a specific, opinionated answer to one narrower question: how should a modern frontend framework actually get deployed — and the answer is shaped entirely by the fact that Vercel's own team also builds Next.js.
2 min read
Vercel is the company behind Next.js (this curriculum's own React & Next.js domain), and its hosting platform is deliberately optimized around exactly the rendering patterns Next.js supports — Static Generation, Incremental Static Regeneration, Server-Side Rendering, and Edge rendering (lesson 4 covers all four directly). This isn't a coincidence worth glossing over: features ship in Next.js and Vercel's platform together, often in the same release, because the same team controls both. Deploying a Next.js app somewhere else (a general container host, a plain Node server) still works, but loses automatic access to several platform-level optimizations this domain covers that only exist because Vercel built them specifically for its own framework.
Railway's and Render's own domains (covered next in this curriculum) are built to run arbitrary services — a background worker, a database, a cron job, any Dockerized process. Vercel's platform is narrower by design: it runs frontend-framework builds and the serverless/edge functions a frontend app needs, not a general long-running server process or a persistent database. Reaching for Vercel to host a standalone API server with no frontend framework in front of it works against the platform's actual design center, even though it's technically possible in limited cases.
git push → Vercel builds the project → deploys it →
every commit gets its own URL (lesson 2) →
production deploys are promoted explicitly or automatically
Every push to a connected Git repository triggers a build and a deployment — this is the foundation every other lesson in this domain builds on. There's no separate "deploy" command to remember and no manual server to SSH into; the entire lifecycle is driven by Git activity, which is also exactly why understanding Vercel well means understanding how it reads a repository's branches and commits, not just how to configure a dashboard.
Most of this curriculum's other infrastructure domains (Cloud Computing, AWS) stay deliberately provider-agnostic or AWS-specific for good reason — but Vercel, Railway, Render, and Supabase (this domain and the three that follow) are covered by name because they're the actual platforms real projects — including this very curriculum's own app — are built and deployed on day to day. Learning Vercel's specific usage limits, deployment model, and rendering options isn't academic background; it's the same kind of concrete, operational knowledge this curriculum's own Vercel usage incident (a real production issue covered later in lesson 11) required to actually diagnose and fix.
Check your understanding
A quick comprehension check — not tracked, not graded, just for you.
1. Why are Vercel's platform features and Next.js's framework features often tightly coupled?
2. How does Vercel's design center differ from Railway's or Render's?
3. What drives the entire Vercel deployment lifecycle?
Vercel