Life of a Vercel request: Application-aware routing

Routing as application logic, not configuration

Most platforms treat routing as a configuration problem: stitch together YAML rules, wire up backends by hand, and hope the caching layer doesn't fight you. Vercel treats it as an extension of your codebase. Framework code defines the routing table, middleware, headers, and compute logic, and that definition gets baked into every immutable deployment.

The result is a gateway that doesn't just forward traffic. It understands the application behind the request—routes, rewrites, auth checks, static assets, function boundaries—and makes decisions accordingly. That means no manual wiring to backends, no hardcoded interpretation of intent, and a platform that can skip compute entirely when it knows a response can come from cache or an early return.

This application-aware approach shows up across the entire request lifecycle, from how domains map to code, to how rollouts and rollbacks happen, to how version skew is managed.

Domains as pointers, not endpoints

On Vercel, domain names—*.vercel.app subdomains, custom domains, third-party domains—are all aliases. An alias is a logical mapping that points to a specific deployment inside Vercel's global routing system. Under the hood, each deployment created from a build includes its own routing table, middleware, headers, and logic, giving the platform full context on what WAF rules make sense, what can be cached, and what needs to invoke compute.

Pointing a domain at a deployment is a pointer update at the software layer, not an infrastructure provisioning event. Vercel handles SSL/TLS certificate issuance and renewal automatically when that alias is set. No certificate management, no expiration risk, no downtime while certificates rotate.

A WAF that knows your application

Traditional WAFs evaluate requests blind, matching regex patterns against raw paths without understanding what they're protecting. Vercel's firewall, by contrast, gets integrated with routing metadata from the deployment itself. Protection rules can target specific application components rather than requiring unwieldy pattern matching. Since the firewall knows the application structure, it inspects routes that actually exist instead of guessing at intent.

After traffic enters the nearest Point of Presence via Anycast and passes initial DDoS mitigations, it hits the WAF and is enriched through "de-aliasing"—resolving which deployment a given domain maps to. From there, every routing decision can be made: return early, serve from the CDN, rewrite to another origin, or invoke a function. The destination for a request isn't a fixed target; the gateway decides dynamically for each one.

Instant propagation across the global network

Because domains are aliases sitting at the software layer, changing what deployment they point to is effectively instant. Updating an alias triggers global propagation that reaches all Points of Presence within milliseconds, without DNS propagation delay or warmup time.

That speed has practical benefits beyond just shipping a new build:

• Rollbacks are a one-step alias flip back to a previous, untouched deployment. No rebuild, no redeploy, no going through scale-down. The CDN cache stays warm because only the routing pointer changes.
• Incremental rollouts (blue/green deployments) stage a new build in preview, run health checks, then gradually shift traffic percentages to the green deployment. Just as quickly, the alias update process pushes traffic back to full blue if something goes wrong.
• Multi-tenant and microfrontend architectures become manageable when path-based rewrites can route across entirely separate deployments or external origins while keeping the user-facing URL stable and the app feel unified.

Staying on one version with Skew Protection

A backend deployed today can conflict with frontend code that a browser has rendered from yesterday's deployment. Skew Protection addresses this class of issues without rescheduling requests or coordinating across processes. The gateway tracks which deployment originally rendered the application for a given user, using a first-party cookie tied to that deployment.

When subsequent requests include that identifier, the gateway bypasses the alias mapping entirely and routes directly to the originating deployment. A user on the new UI hits the new backend; a user on the old UI stays on the old stack even while a rollout is mid-flight.

It's not just an interactive session concern. Search engines hold onto versioned URLs for weeks after deployment, and broken links result when those versions are normally deleted. Skew Protection keeps outdated crawler requests pointing at the correct version for up to 60 days, preserving page availability.

Continuous routing functions throughout a request

Routing on Vercel isn't a single decision made at the network edge. It's a continuous process layered through the backend forwarding system, where code runs at different stages as a request progresses.

The routing happens before, during, and after each inspection point—with middleware designed to run during routing itself, close to the user, with access to request headers, cookies, and pathname. Middleware supports short-circuiting the flow for quick responses like auth failures or geo redirects, mutating paths for feature flags and A/B experiments, injecting headers for downstream compute, or filtering application-level bots without hitting your functions.

The fundamental primitives offered by the routing system:

• Rewrites silently route a request to a different origin or path—internal or external—which is useful for services like pre-rendered CMS content for a blog or structuring microfrontends. For certain platforms like Dub or Mintlify, implementations use wildcard subdomains to support many custom domain users pointing several distinct hosts at shared internal apps.
• Redirects issue immediate browser-facing changes, valuable for SEO changes like canonicalizing duplicate content paths or managing account renewals on old legacy paths.

Both static definitions and dynamic code-generated replacements are derivation-versioned. Configuration doesn't hang globally outside your deployment lifecycle: Rewrites, redirects, and middleware rules are all scoped and stored inside each immutable snapshot of your code.

Between caching layers that avoid origin calls, early return logic, rewrites that alter existing paths yet preserve the UX, and de-aliasing code that maintains deploy locking, the platform continuously interprets application logic to push responses through, eliminating just where headroom remains.

Routing as Built-In Application Logic

The Vercel gateway operates as a routing layer that is deliberately aware of the infrastructure it sits in front of and the deployments it serves. Rather than functioning as a simple path-to-handler mapper, it uses the structure of your application code to determine how incoming traffic should be processed.

This approach is built on the idea that routing behavior should be derived from the application itself, not manually configured alongside it. Each framework implements routing differently, and Vercel analyzes and preserves the routing output generated during a build. This ensures that requests are handled according to the framework’s actual behavior and the developer's intent, whether that means serving a static asset, invoking a serverless function, or applying middleware-like logic before a response is returned.

Because the gateway has a view of every deployment, it can make routing decisions that account for the current state of the app. It knows which deployment is active, how requests should be shaped, and what code needs to execute. This happens without drift between the infrastructure layer and the application code, and without requiring manual updates when a new version is deployed.

For developers, the practical effect is control without the operational overhead. The gateway understands the application’s coded intent and translates it into real-world traffic handling. Programmatic control over routing happens in real time, but it remains predictable because it is derived from the same codebase as the app itself. Routing, in this model, is not just a gateway feature—it is an extension of your application's runtime behavior across domains and deployments.