Behind the scenes of Vercel's infrastructure: Achieving optimal scalability and performance

The deployment path

Deployments on Vercel start with code from one of the more than 35 supported frameworks, or with a prebuilt project that conforms to the Build Output API. You can trigger a deployment through the Vercel CLI or by pushing code to a git repository, where the Vercel Git integration watches for commits and initiates builds automatically.

A CLI-triggered deployment begins with two API calls. First, a POST request uploads the project files to a scalable, secure, and highly durable data storage service. Once that completes, a second POST request starts the build and deployment process.

Before the deployment is created, Vercel authenticates the user and verifies the request's integrity and permissions to guard against unauthorized access. It also validates the Vercel configuration in the vercel.json file.

If validation passes, the deployment is scheduled for building via a queue service. The build container can start processing immediately if sufficient build concurrency is available under the project's billing plan: Hobby teams get 1 concurrent build, Pro teams can purchase up to 12, and Enterprise teams can buy a custom number of build slots.

The build step converts the source into a Vercel deployment by running a "builder" against the code. Builders can be provided internally by Vercel or installed from an npm registry. The build system automatically detects frontend frameworks or recognizes prebuilt output conforming to the Build Output API spec. While processing files, the container pings an API endpoint that tracks deployment status; the CLI and dashboard read this endpoint to show progress to users.

The build output targets one of Vercel's supported runtimes and provisions resources including:

• Vercel Functions for API routes and server-side rendered pages
• Edge Functions for Middleware and other code using the edge runtime
• Optimized Images
• Static output

Once resources are provisioned, a Deployment database document is created and deployment metadata is uploaded to static storage. That metadata is later used during the request phase to route users to the correct location and select the right resource based on the incoming request path. The deployment is then ready to be served via the Vercel CDN.

What happens on request

When a browser hits a Vercel-hosted URL, a DNS lookup resolves to an anycast IP address owned by Vercel with the cname.vercel-dns-0.com CNAME record. Unlike GeoDNS, which routes users to unique endpoints based on location, Vercel uses a networking service with anycast routing to direct traffic to the optimal data center, determined by hop count, round-trip time, and available bandwidth. This approach reduces latency for users in different regions.

The same networking layer provides automatic failover and DDoS protection, with performance features designed to improve resiliency and reduce the impact of attacks. The anycast IP connects the user to the nearest edge location, which acts as a gateway to the network infrastructure.

The request now enters Vercel's Kubernetes cluster. It is first inspected and filtered for malicious traffic, then routed to a virtual machine serving as a reverse proxy within the cluster. This gateway handles request rewriting and proxying. It determines which deployment version to serve based on the request hostname, fetches that deployment's metadata, and checks whether the request path matches a defined route. If no route matches, the request resolves with a 404; otherwise it proceeds to generate a response.

If Routing Middleware is enabled, the request may first be forwarded to a platform that executes edge functions before continuing to the response phase.

Response generation by resource type

The response phase varies depending on the type of resource being served:

• Static resources (pages, fonts, unoptimized images): the gateway downloads the resource from static storage.
• Vercel Functions (server-rendered pages, API routes): the gateway triggers a Serverless Function execution in the region where the function was deployed.
• Edge Functions (pages or API routes using the edge runtime): the gateway formats the request to invoke an Edge Function execution at the edge.
• Incremental Static Regeneration pages: the gateway checks whether the page was rendered before and its static output is in static storage. If not, it invokes a Serverless Function to generate the content dynamically. The same invocation happens for stale content, where the cached resource has passed its time-to-live: the stale version is served while the function regenerates in the background.
• Optimized images: requests are forwarded to a dedicated service that optimizes the image on the fly, using modern formats supported by the requesting client's browser. The optimized image is cached at the edge until it expires, at which point a stale version is served while re-optimization happens in the background. Expiration is set by a configuration option or the upstream image's Cache-Control header.

All responses are cached according to caching headers to speed up subsequent requests.

What the platform abstracts away

The architectural picture explains why deploying to a managed platform differs from running your own stack. Self-managed infrastructure requires selecting hardware and operating systems, configuring networks, maintaining software stacks, and continuously monitoring and patching against vulnerabilities. Handling traffic spikes adds another layer of work.

Vercel handles these concerns internally, letting the development team concentrate on code. The Git integration creates preview deployments for each commit, giving teams an immediately available updated product for review. Comments on Preview Deployments give team members a dedicated environment for feedback on each change.

Under the hood, this infrastructure is assembled from AWS services: S3 for file and metadata storage, Simple Queue Service for scheduling builds, an auto scaling fleet of Fargate-powered EC2 instances for builds, Global Accelerator for anycast networking, the AWS Global Network connecting edge locations, EKS for the Kubernetes cluster hosting the reverse proxy layer, and Lambda for Serverless Function executions.