Life of a Vercel request: Application-aware routing
By Steven Van ·
Vercel explains how its gateway uses framework code to route requests, roll back instantly and keep frontends and backends on the same deployment.
Routing on Vercel is built into the platform as an application-aware gateway, not configured separately in a caching layer, according to the second part of the "Life of a Vercel request" series. The gateway reads routes, layouts, rewrites, middleware, functions and static assets from your framework code. That lets it make decisions such as skipping unnecessary compute.
The post walks through how a request is handled and what that design allows:
- Aliases: every domain, whether custom, third-party or *.vercel.app, is an alias that maps to one deployment. Vercel provisions and manages SSL/TLS certificates when a domain is aliased.
- Request path: a request goes through Anycast routing to the nearest Point of Presence, then DDoS mitigation and a first Web Application Firewall check in a Vercel Region. It is then de-aliased to its deployment. Because the WAF has the deployment's routing metadata, firewall rules can target parts of the application rather than only raw paths or regex patterns.
- Instant rollbacks: switching an alias to a previous deployment propagates globally within milliseconds, with no DNS propagation, warmup or rebuild. The CDN cache stays intact.
- Incremental rollouts: traffic can be split between two deployments for phased, blue/green style releases. A rollback returns the traffic to the earlier deployment.
- Skew Protection: requests in a session are routed to the same deployment, which keeps frontend and backend code from different deployments from mismatching.
Vercel
The platform for frontend developers — deploy, preview, and scale web apps and AI agents with zero config.
View Vercel →