Netlify Rebuilds Edge Functions on Firecracker MicroVMs, Cuts Median Latency to 5-6ms

Netlify has rebuilt the infrastructure powering Edge Functions, a service that handles roughly a billion invocations a day for customers ranging from Sunweb, which uses it to personalize pages, to Loto-Québec, which uses it to route traffic based on a cookie check. The new architecture replaces a hosted, V8-isolate-based execution model with Firecracker MicroVMs running inside Netlify's own edge network, a change the company built in close collaboration with Unikraft.

Previously, requests matching an edge function left Netlify's network entirely, traveled to a hosted execution service, ran, and returned. Under the new system, matched requests are instead forwarded to a compute node within Netlify's own infrastructure, where they run inside a dedicated Firecracker MicroVM. Netlify says this keeps the entire request path under its control and removes a network hop that previously added latency.

The company reports that a warm invocation — covering routing to a compute node, entering a MicroVM, running the function, and producing response headers — now takes about 5 to 6 milliseconds at the median, down from 25 to 40 milliseconds on the prior infrastructure. Netlify also cites a 47.4% improvement in p99 invocation times, 99.998% availability, and edge function log delivery that is five times faster than before. Cold invocations, which occur when a request hits a region that hasn't yet cached the relevant function images, happen on about 1.2% of requests and add roughly 9 milliseconds on average.

The request path begins at an edge node, which terminates the TLS connection and checks whether the request matches a deployed edge function's route. If it does, the edge node writes a machine specification naming the runtime, platform, and function images, along with CPU, memory, and connection limits. That specification's hash, combined with site-specific information, becomes a service ID, ensuring that different deploys — even from the same customer — never share a MicroVM. Netlify argues this isolation is stronger than what V8 isolates alone can provide, since a compromised deploy is contained within its own MicroVM rather than sharing a runtime with other customers' code.

Each region routes requests to compute nodes using rendezvous hashing, which consistently sends a given service to the same node so its code stays cached and its MicroVM stays warm. To prevent a single high-traffic function from overwhelming one node, Netlify relaxes that stickiness above a certain traffic threshold and spreads the service across a slice of nodes instead.

Functions run in individual Firecracker MicroVMs that Netlify says are created in under a millisecond and start in about 2 milliseconds at p99, since they boot a stripped-down Linux environment rather than a full operating system. Function code is mounted as an uncompressed, memory-mapped EROFS image so the VM reads only the portions of the bundle it needs. Once a MicroVM boots and its JavaScript server starts listening, Netlify snapshots it; idle MicroVMs scale to zero, and future invocations restore from that memory-mapped snapshot rather than booting from scratch. Unikraft's product handles this boot-snapshot-restore-scale-to-zero lifecycle, with Netlify working alongside the company to validate it against its traffic volume and patterns.

On the operational side, Netlify said it added local DNS resolvers to compute nodes, expanded metrics collection to include boot time and time-to-first-port-open, and added circuit breakers to reroute or decommission unhealthy compute nodes quickly. Compute nodes are built from a Unikraft base image and run separately from Netlify's edge nodes, which lets the company scale and instance-type them independently. A control plane tracks node health and manages rollouts, bringing up a new fleet alongside the running one and shifting traffic only once the new fleet is verified healthy.

Netlify says the change requires no migration step and no changes to existing projects — URL imports, npm packages, Node built-ins, netlify.toml configuration, and local development all continue to work as before, at the same pricing. The company frames the rebuild as a foundation for further changes, including moving npm package support out of beta, revisiting existing operational limits such as the 50ms CPU cap, 512MB memory limit, and 20MB compressed code limit that stemmed from the old isolate-based model, and building features that depend on controlling the network path directly rather than reaching third-party services over the internet.