V8 Isolates vs Firecracker MicroVMs for Edge Functions

Edge functions sit in front of a site and run on every matching request, so the milliseconds they consume are milliseconds a user spends waiting. That makes the execution substrate an unusually high-leverage architectural decision: the runtime model determines how fast a function can start, how strongly one tenant is separated from another, and which workloads are even possible to support.

Netlify recently rebuilt its Edge Functions platform, moving from a hosted execution service built on V8 isolates to Firecracker MicroVMs running inside its own edge network. The company reports the new architecture is roughly 5x faster at the median, with warm invocations dropping to about 5–6ms at p50 from 25–40ms previously. This article looks at the tradeoffs behind that kind of migration: what V8 isolates buy you, what MicroVMs buy you instead, and where each model tends to break down.

A V8 isolate is a JavaScript execution context inside a shared process. Multiple tenants’ functions can run in the same V8 process, separated by the engine’s own heap and context boundaries rather than by a kernel-enforced boundary. Startup is extremely cheap because there is no kernel, no virtual machine, and no guest operating system to boot — you spin up a context and run code.

A Firecracker MicroVM is a lightweight virtual machine. It has its own kernel, its own memory space, and a hardware-virtualization-backed boundary. Firecracker was designed to make VMs small and fast enough to be practical as a per-tenant unit, but it is still a VM: there is a guest kernel, a boot path, and a memory image to restore.

The tradeoff is not subtle. Isolates optimize for density and start latency. MicroVMs optimize for isolation and for giving the workload a real machine to run on.

Isolates have historically been the default choice for edge compute precisely because they start fast. There is no boot sequence in the traditional sense, so the platform can pack many tenants into one process and pay almost nothing to bring a new function online.

MicroVMs change that calculus, but not as much as the reputation suggests. Netlify reports that its Firecracker MicroVMs are created in under a millisecond and start in about 2ms at p99. That is achieved by starting a stripped-down Linux environment rather than a full operating system, and by taking a snapshot of the MicroVM once the JavaScript server is listening on a port. When the function is not being invoked, the MicroVMs scale to zero; the next invocation starts a new MicroVM from that snapshot. Because the snapshot is memory-mapped, the VM can begin executing without waiting for the entire snapshot to be read back into memory.

The remaining cold path is image availability. When a request arrives in a region that no compute node has seen before, the relevant images must be fetched before anything can run. Netlify says this happens on about 1.2% of invocations and takes about 9ms on average. That is the real cold-start cost in the new model — not VM boot, but pulling the function’s images into a region for the first time.

Most invocations are warm, and the warm path is where the architecture shows up in latency budgets. Netlify describes the sequence as: the request lands on an edge node, the node writes a machine specification, the request is routed to a compute node, and the compute node forwards it into a MicroVM. A warm invocation — routing to a compute node, entering the MicroVM, running the function, and producing response headers — now costs about 5–6ms at median.

The interesting design detail is how the platform keeps MicroVMs warm without creating hot spots. Each region has a group of compute nodes, and the edge node picks one using rendezvous hashing so the same service lands on the same node every time. That stickiness is what keeps the code on disk and in cache. But pinning every request for a busy function to a single node is also how a hot spot forms, so the platform relaxes stickiness above a threshold and spreads the service across a slice of nodes. The result is a deliberate compromise: accept some additional cold starts in exchange for not letting one customer’s traffic spike starve other services on the same box.

This is where the two models diverge most sharply, and it is the part of the tradeoff that is easiest to underrate.

V8 isolates, whatever they are called, do not provide the isolation level of a VM. Multiple tenants share a process, and the boundary between them is enforced by the runtime rather than by the kernel. That is fine for many workloads, but it means a runtime escape is a shared-process problem.

With MicroVMs, each function runs in its own VM. Netlify’s machine specification names three images — the runtime, the platform image, and the edge function image — and the hash of that spec plus site-specific information becomes a service ID. Two deploys with different code or different environment variables are different services, and they never share a MicroVM. A potentially compromised deploy runs in a separate MicroVM, and even if it escapes the runtime, it cannot poison other customers or the compute layer itself.

That is a meaningful difference in failure modes. It is also the reason MicroVMs are attractive for platforms that run untrusted code from many customers, where the blast radius of a single escape matters more than the marginal cost of a VM boundary.

The execution model also sets the ceiling on what a function can do. Netlify notes that its documented limits — 50ms of CPU per request, 512MB of memory, and 20MB of compressed code — came from the isolate-based execution model. Those limits are not arbitrary; they reflect what is reasonable to allocate inside a shared process.

A real VM with a real filesystem changes that. Netlify points to npm package support, currently in beta with caveats around native binaries and importing files at runtime, as one area where a real filesystem removes most of the reasons those caveats exist. The company also frames the new architecture as opening up work that depends on controlling the network path rather than reaching a third party across the internet.

There is a cost side too. Running MicroVMs means running compute nodes, building them from a base image, installing packages, and keeping a control plane that tracks which nodes exist and which are healthy. Netlify describes building compute nodes separately from edge nodes so the edge nodes stay lightweight, so different instance types can be used, and so the two tiers can scale independently. Deploys work by bringing up a new fleet alongside the running one, scaling it to match, and taking over traffic only once it is healthy. That is more operational surface than a hosted isolate service.

The migration is a useful case study because it does not claim isolates were simply wrong. Isolates are cheap to start and dense to pack, and for a long time that was the right tradeoff for edge compute. What changed is that the platform wanted isolation it could defend, a filesystem it could expose, and control over the network path — and it was willing to take on the operational burden of running MicroVMs to get them.

For teams choosing an edge runtime, the practical questions are:

• How much do you trust the code? If you run untrusted multi-tenant code, a VM boundary is a stronger default than a shared process.
• What does the workload need? Native binaries, a real filesystem, and network control are easier to support on a VM than inside an isolate.
• How much does cold start actually cost you? If most of your traffic is warm, the warm path dominates, and the warm path is where routing, caching, and node stickiness matter more than the boot mechanism.
• Who operates it? A hosted isolate service is someone else’s problem. MicroVMs mean owning the compute tier, the control plane, and the rollout strategy.

Netlify’s numbers describe one platform’s experience, not a universal result. But the shape of the tradeoff is general: isolates buy density and simplicity, MicroVMs buy isolation and capability, and the right answer depends on which of those you are short on.