How Vercel CDN works

Every request to a Vercel deployment flows through a globally distributed CDN before it reaches your application code. The CDN handles routing, caching, security, and compression automatically, so your app is fast by default.

When a visitor requests a page, the CDN processes it through a series of layers. Each layer can resolve the request on its own or pass it to the next.

Requests arrive at the nearest Point of Presence (PoP) out of 126 locations worldwide. The PoP terminates TCP and routes the request to the nearest Vercel region over a private network in single-digit milliseconds. The region terminates TLS, applies compression, and processes the request through the remaining layers.

The Vercel Firewall inspects every request before it reaches your application. It operates in three layers:

• Platform-wide firewall: DDoS mitigation and protection against low-quality traffic, active for all customers at no cost.
• Web Application Firewall (WAF): Custom rules to block or challenge requests based on IP, path, headers, geographic location, and more.
• Bot management: Detect and manage automated traffic with configurable policies.

Blocked requests never reach the routing or caching layers.

Before the CDN checks any cache, it evaluates routing rules in order:

1. Redirects: Return a new URL to the client (e.g., enforce HTTPS, move pages, localize paths)
2. Rewrites: Map a public URL to a different backend path without changing what the visitor sees
3. Headers: Add or modify request and response headers, including security headers and cache-control directives

If a redirect matches, the CDN responds immediately. Rewrites and header rules continue through the remaining layers.

After routing rules resolve, the CDN determines which deployment handles the request:

• Skew Protection: Locks each client session to a specific deployment version so client-side code and server responses stay in sync. This prevents errors caused by version mismatches during deployments.
• Rolling Releases: Gradually shifts traffic from your current production deployment to a new one across configurable stages. You can monitor metrics at each stage and abort if needed.
• Microfrontends: Routes requests to different microfrontend applications based on path configuration in microfrontends.json. This routing happens within the same request with no additional network hop.

Vercel maintains two tiers of caching. Together, they minimize how often your functions run:

• CDN cache: It stores responses at the nearest PoP, closest to your visitors and is controlled by Cache-Control headers your functions return. A CDN hit serves the response without reaching your origin.
• ISR cache: A durable store in your configured function region: Vercel selects one region if you have multiple regions configured. It persists content for up to 31 days. When the CDN misses but the ISR cache has the content, Vercel serves it without invoking your function.
  • Request collapsing further protects this layer by deduplicating concurrent requests to the same ISR path into a single function invocation.

For data fetched inside your functions (individual API calls, database queries), runtime cache provides an additional caching layer that works alongside response caching.

If no cache has the content, the request reaches Vercel Functions in the nearest compute region. Your function generates a response. Vercel caches it based on the caching headers or framework configuration, then serves it to the visitor.

Vercel supports 35 frontend frameworks with local development environments. Through framework-defined infrastructure, Vercel transforms your build outputs into globally managed infrastructure for production.

If you use Vercel Functions without a framework, run vercel dev to test locally.