How Vercel Works

Vercel turns a Git repository into a globally served application. This page walks through what actually happens between a git push and a live site.

The deployment lifecycle

1. Trigger     git push / vercel deploy / dashboard import
2. Build       framework detected, dependencies installed, build run
3. Output      static assets + serverless/edge function bundles
4. Deploy      immutable deployment created with a unique URL
5. Serve       assets cached on the Edge Network; functions run on demand
6. Promote     a domain is aliased to the deployment (production or preview)

1. Trigger

A deployment can start from three places: a push to a connected Git repo (GitHub, GitLab, Bitbucket), the vercel CLI, or importing a project in the dashboard. The Git integration is the most common — it's the "push to deploy" workflow.

2. Build

Vercel inspects your repository, detects the framework, and runs the appropriate build command. For Next.js that's effectively next build; for a Vite app it's vite build, and so on. You can override the build command, output directory, and install command in project configuration. Builds run in an isolated environment, and the environment variables you've configured for that environment are injected.

3. Build output

The build produces two kinds of artifacts:

• Static assets — HTML, CSS, JS, images. These are uploaded to the Edge Network and cached.
• Functions — server-side code (API routes, server-rendered pages, middleware) compiled into Functions that execute on demand.

This separation is the heart of Vercel: static things are served instantly from cache; dynamic things run only when requested.

4. Immutable deployments

Every build becomes an immutable deployment with a permanent unique URL (something like my-app-abc123.vercel.app). Once created, that deployment never changes. Promoting to production doesn't rebuild — it re-points a domain alias at an existing deployment. Two consequences:

• Instant rollback. Reverting is just re-aliasing to a previous deployment, so it's near-instant. See vercel rollback.
• Every version stays reachable. Old preview URLs keep working, which is great for comparing versions or sharing a specific build.

The Edge Network

Vercel serves your app from a global network of points of presence (PoPs). Instead of one origin server in one region, requests are answered from a location physically near the user.

• Static assets and cached responses are served directly from the edge — fast, because nothing has to be computed.
• Cache-control and revalidation rules decide how long responses live at the edge before they're refreshed.
• Dynamic requests that can't be served from cache are routed to a Function.

Where code runs

Vercel offers more than one execution model, and a single app commonly uses several at once:

Edge runs close to the user with near-instant startup but a constrained runtime. Regional Functions give you a full Node.js/Python environment with configurable CPU and memory. The full breakdown — including Fluid Compute and how cold starts are handled — is on the Functions page.

Preview vs production

Because deployments are immutable and cheap to create, Vercel gives every push its own deployment:

• Preview — non-production branches and pull requests get a unique URL for testing and review. Preview comments let your team leave feedback directly on the deployment.
• Production — pushes to your production branch (usually main) are promoted to your production domain.

Both run the same infrastructure, so a preview is a faithful rehearsal of production. More detail in Deployments and environments.

Next

• Deployments and environments
• Functions and compute
• Getting started