Netlify migrates a billion daily Edge Functions to Firecracker MicroVMs for 5x faster median invocations

Netlify has rebuilt the compute layer behind Edge Functions, replacing V8 isolates on an external hosted execution service with Firecracker MicroVMs running inside its own edge network. According to a Netlify blog post, roughly a billion Edge Functions execute on the platform every day — personalizing pages for Sunweb, handling cookie-based routing for Loto-Québec, and running personalization, routing and auth for hundreds of thousands of other sites — and warm invocations are now about five times faster at the median.

The performance figures

A warm invocation — routing to a compute node, entering a MicroVM, running the function and producing response headers — now costs about 5–6ms at the median (p50), down from 25–40ms on the previous infrastructure. Netlify also reports 47.4% faster p99 invocations, 99.998% availability and five-times-faster Edge Functions log delivery.

Cold starts happen when a request arrives in a region whose compute nodes have never seen the function and images must be fetched before anything can run. Netlify says this affects about 1.2% of invocations and takes roughly 9ms on average. All of these figures are the company's own, not independent measurements.

The new request path

Each request lands on the edge node closest to the client, where TLS is terminated and the path is checked against the Edge Functions routes for that deploy. Non-matching requests continue to cache and origin as usual. Under the old architecture, a matching request left Netlify's network, ran on a hosted execution service over the public internet and came back; it is now forwarded to a compute node inside Netlify's own network.

Before forwarding, the edge node writes a machine specification that travels with every request. It names three images — the JavaScript runtime, Netlify's platform image and the customer's edge function image — and sets CPU, memory and connection limits. A hash of the spec plus site-specific information becomes a service ID, so two deploys with different code or environment variables are different services that never share a MicroVM.

On the compute node, a service can own multiple MicroVMs, with parameters controlling when instances scale in and out. Each MicroVM handles a fixed number of requests before it is shut down, and the platform eagerly boots a replacement in anticipation. Missing images are fetched from the edge node and written to disk, so a region only pulls the functions that actually receive traffic there.

Sticky scheduling, with an escape valve

Compute nodes are selected through rendezvous hashing: the same service always lands on the same node, which keeps MicroVMs warm and code on disk and in cache. Netlify notes that spreading requests evenly across nodes would produce far more cold starts. The cost of stickiness is the hot spot, where a single busy function pinned to one node starves everything else on that machine. Above a traffic threshold, Netlify relaxes the stickiness and spreads the service across a slice of nodes to absorb spikes without degrading other services hashed to the original node.

Inside the MicroVM

Each function runs in its own Firecracker MicroVM, created in under a millisecond and started in about 2ms at p99 — feasible because the VM boots a stripped-down Linux environment rather than a full operating system. The function's files are mounted as an uncompressed EROFS image and memory-mapped, so the VM reads only the parts of the bundle it actually uses.

When the JavaScript server inside the VM starts listening on a port, Netlify takes a snapshot. Idle functions scale to zero rather than sitting warm, and the next invocation resumes from the memory-mapped snapshot without waiting for the full snapshot to be read back into memory. Unikraft's product manages the boot, snapshot, restore and scale-to-zero lifecycle; the two teams worked together throughout the migration, and Unikraft has published its own account of the project.

Netlify frames isolation as the decisive advantage: a potentially compromised deploy runs in a separate MicroVM, and even code that escapes the runtime cannot poison other customers or the compute layer — a guarantee the company says V8 isolates, despite their name, do not provide.

For developers, nothing changes: URL imports, npm packages, Node built-ins, netlify.toml declarations and local development all behave exactly as before. Operationally, the rebuild added local DNS resolvers on compute nodes and expanded metrics collection, drawing on earlier lessons that included exhausting ports on virtual switches.

Why it matters

Edge platforms have widely adopted V8 isolates for their fast startup and high density, but tenants then share a single runtime process, which caps how isolated one customer is from another. Netlify's results argue that Firecracker MicroVMs — with snapshot restore, memory-mapped EROFS bundles and stripped-down kernels — can now deliver isolate-class latency with a hardware isolation boundary between every deploy. At a billion invocations a day, with milliseconds of edge time compounding across personalization, routing and auth workloads, that combination is a serious data point in the isolates-versus-MicroVM debate, and a template other shared-runtime serverless platforms may need to respond to.