Vercel details Fluid, the single compute layer behind its builds, sandboxes and functions

Vercel has pulled back the curtain on the compute layer that runs its platform, saying that builds, sandboxes and serverless functions all sit on a single system it calls Fluid. According to the Vercel blog, the system already handles more than 15 million builds a day, 25 million sandboxes a week and a trillion requests a month, and anyone who has shipped on Vercel has been running on it without knowing.

A machine assembled per workload

The core idea is that workloads differ in how long they run, how much memory they consume and how much of the environment they control, and that each of those differences traditionally demanded its own compute primitive. Vercel's answer is to assemble the machine a workload needs when the workload arrives, reconfigure it while it runs, and absorb traffic bursts as they happen.

Vercel sketches a progression to justify the design: hardware you upgraded by hand, then rented bare metal, then cloud VMs you could request and discard at will. Its claim is that agents now iterate faster than a standard VM can provision, and that this gap is what Fluid is built to close.

Hive, Fluid images and Vercel Drives

Fluid rests on three pieces. Hive is the layer that provisions isolated virtual machines, usually ones kept warm so they are ready immediately. It picks an appropriate machine for the job, maintains isolation in a multitenant environment, and exposes one control-plane API that every Vercel product builds on.

Fluid images supply the environment. Developers push their own image to the Vercel Container Registry and run it across sandboxes and functions. Vercel converts these into a format it calls VHS (Vercel Hive Snapshot), an optimized boot format — the same technology behind Dockerfile deploys and sandbox custom images — so a machine can resume from a snapshot instead of cold-booting and be ready in milliseconds. Vercel notes that v0 already uses it to build and run its own development environments.

Vercel Drives provide storage that travels with the workload rather than sitting stranded on one machine's disk. Because storage outlives the compute attached to it, Vercel says you can swap the machine underneath and continue exactly where a previous session stopped. Drives attach to sandboxes today in a private beta, and will extend to the rest of Fluid from there.

The execution model on top is Fluid compute: many requests share a single instance instead of each request spinning up its own, and with Active CPU pricing, customers pay for CPU only while their code is actively working — not while it waits on a database or a model.

Built with agents in mind

Vercel frames agents as the workload that most needs this style of infrastructure. An agent runs untrusted code, so its machine needs a secure boundary. It brings its own tools, so it needs its own environment. And it creates and destroys machines constantly, so its state has to survive the compute underneath. Vercel claims Hive can provision a full VM in milliseconds while carrying filesystem state along, delivering isolation tighter than containers or isolates typically offer, without the startup penalty that stronger boundaries usually cost. The inversion, as the blog puts it, is that instead of fitting your work to a fixed machine, you describe the work and the machine conforms to it.

Why it matters

The consolidation argument is the most consequential part for developers. Because functions, sandboxes and builds share one compute layer, an improvement in boot time, isolation, scheduling or caching lands across all of them at once rather than being rebuilt three times, and new shapes of compute can be added without re-architecting the foundation.

For teams building AI agents, provisioning speed is iteration speed: if an agent waits seconds for a VM, the product waits too. Vercel's millisecond boot claims and Active CPU pricing speak directly to that cost.

The caveats are worth stating. The usage figures and performance claims come from Vercel itself, with no independent benchmarks cited, and Drives — arguably the piece that makes persistent agent state practical — remains in private beta and currently limited to sandboxes.