Netlify moves Edge Functions to Firecracker microVMs, cutting warm overhead to 5-6 ms

What changed

Netlify has migrated its Edge Functions from a hosted V8-isolate execution service to Firecracker microVMs running on compute nodes inside its own edge network, according to a dev.to analysis of the company's engineering write-up. The platform now handles roughly a billion Edge Function invocations per day, which makes even small per-request costs expensive twice over: users experience them as latency, and the platform pays for them across enormous volume.

The reported results are notable. Median warm invocation overhead fell from roughly 25-40 ms on the previous infrastructure to about 5-6 ms, p99 invocations became 47.4 percent faster, availability sits at 99.998 percent, and log delivery is around five times quicker. Unikraft, which worked with Netlify on the execution layer, reports a 2 ms p99 for microVM startup across the fleet.

The dev.to piece argues the architectural shift matters more than the benchmark numbers. Previously, a request matching an Edge Function route left Netlify's network entirely and ran on an external provider. Now the edge node that terminates TLS checks the deployment's routes and forwards matching requests to a regional compute node. Runtime startup is only one term in request latency: network hops, placement, image availability and logging all sit on the critical path, so eliminating an external hop can matter as much as a faster runtime.

The request carries its machine spec

Before forwarding, the edge node attaches a specification describing the machine that should execute the function: the runtime, a platform image, the customer's function image, plus CPU, memory and connection limits. Netlify hashes this specification together with site-specific data to derive a service ID, so different deploys or environment-variable sets map to different services, and different services never share a microVM. Deployment identity becomes part of the isolation boundary rather than a convention layered on top of a shared process.

Placement and image distribution

Each region contains a pool of compute nodes, and Netlify applies rendezvous hashing so a given service usually lands on the same node. That preserves locality: once a node has fetched a function image, later requests reuse the copy on disk, and existing microVMs or snapshots stay useful. Pure stickiness would let one busy tenant saturate its chosen node, so placement relaxes above a threshold and spreads a hot service across several nodes, trading some cache warmth for capacity.

Cold starts are treated largely as an image-distribution problem. Netlify reports the cold path affects about 1.2 percent of invocations and takes roughly 9 ms on average. Nodes fetch images on first use rather than receiving every customer's code in advance, cache them locally, and prune stale copies automatically, an approach Unikraft describes as on-demand image resolution. A new deploy therefore does not need fleet-wide synchronization before it can serve traffic.

Why the microVMs boot fast

Each function runs in its own Firecracker microVM booting a stripped-down Linux environment rather than a full general-purpose guest. Function files are mounted as an uncompressed, memory-mapped EROFS image, so the VM reads only the pages it actually touches instead of copying the entire bundle into memory first. Once the JavaScript server starts listening, the platform snapshots the VM; idle instances scale to zero, and later requests restore from the memory-mapped snapshot without waiting for every page to load.

The dev.to article draws a broader lesson here: "VM" is too coarse a performance category, because a purpose-built microVM restored from a snapshot starts along a very different path than a conventional cloud VM booting an ordinary operating system.

Isolation improvements

Netlify also frames the migration as a security change. If customer code escapes the JavaScript runtime, it now faces a VM boundary before it can reach another tenant or the compute host, a stronger separation than mutually untrusted programs running as isolates within one shared process. The dev.to article cautions that no virtualization boundary should be described as unbreakable, but the migration does change where a compromise has to cross next.

Why it matters

Edge platforms have long traded isolation against latency: isolates are fast but share a process, while VMs isolate well but boot slowly. At a billion daily invocations, Netlify's numbers suggest that microVMs combined with identity-based placement and on-demand image caching can approach isolate-level latency while keeping VM-level isolation between tenants. The reusable lessons extend beyond one platform: keep execution inside your own network, make deployment identity part of the isolation model, and treat cold starts as a distribution problem rather than purely a boot problem.