How Fluid Compute Reworks Function Execution on Vercel

Fluid compute is Vercel’s next-generation execution model, built for workloads that spend significant time waiting on external APIs or models. Traditional serverless architectures optimize for fast execution, but that assumption breaks down when requests sit idle during I/O. Fluid addresses this by dynamically reusing existing resources before provisioning new ones, adjusting to traffic in real time.

At the core of this system is the Vercel Functions router. It orchestrates every invocation with the goal of minimizing cold starts, maximizing concurrency, and keeping resource usage tight. Rather than spinning up new instances for each request, the router routes traffic to pre-warmed or already-active instances whenever possible.

The Architecture Behind the Router

Fluid instances are designed to handle multiple concurrent requests, which reduces idle compute cycles. The router assigns requests to instances based on live metrics such as load, availability, and request type. This pairing of routing intelligence with flexible execution lets Fluid scale responsively without over-provisioning.

Security is baked into the design: instances communicate exclusively with the router through persistent TCP tunnels. They never accept direct traffic. Instead, each instance establishes a bidirectional connection with the router, receiving invocation data and streaming responses back over that same tunnel. This gives the Functions router precise control over workload distribution and scaling decisions while keeping the infrastructure surface small.

Request Lifecycle: From Keystroke to Response

The router optimizes every request in four stages, handling routing, compute selection, execution, and scaling in real time.

1. Routing, security, and caching. When a user hits enter, the request travels via Anycast to the nearest Vercel Point of Presence (PoP). Before execution begins, the Vercel Firewall inspects the traffic and blocks threats like DDoS attacks and suspicious patterns. If the response is cached at the edge, it is served instantly and never reaches the router. Otherwise, the request moves on for execution.

2. Compute selection. The Functions router determines the optimal execution region based on proximity, load, and availability. It then picks the best compute instance:

  • In-flight instances that are actively processing are prioritized for efficiency.
  • Pre-warmed instances that were proactively spawned but are currently idle minimize cold starts. Bytecode caching further reduces their startup time.

3. Processing and response optimization. Once an instance is assigned, the function runs its logic, queries databases, or calls APIs. If streaming is enabled, the response begins flowing as soon as data is available, which improves Time to First Byte (TTFB).

4. Adaptive scaling. Fluid continuously monitors traffic patterns, instance health, and workload fluctuations. During surges, it proactively scales new instances; when demand drops, it gracefully scales down idle instances to avoid wasted compute.

The Cost Impact

Because Fluid prioritizes existing resources with idle capacity, projects that enable it have cut compute costs by up to 85%. The savings come not from better scaling alone, but from eliminating idle compute time entirely. With Fluid, you pay only for the compute actually used, not for instances sitting around waiting for work.