Netlify has shifted its Edge Functions away from V8 isolates run by an external execution service, onto Firecracker microVMs running directly inside its own edge network. The change, detailed in a technical post published on October 1, 2026, touches no public API but reshapes the latency and isolation profile of code running at the edge.
Bringing execution back in-house
Until now, a request destined for a Netlify Edge Function was routed to a third-party execution service before returning to Netlify’s network. With Firecracker microVMs, popularized by AWS Lambda for their fast boot times and lightweight hardware-level isolation, the code now runs inside Netlify’s own edge infrastructure. The company now controls the entire request path, from entry point to response.
The measured performance gains
Netlify published precise figures from its own production telemetry, comparing the old and new architectures for “warm” invocations, meaning without a cold start.
| Metric | Before (V8 isolates) | After (Firecracker microVMs) |
|---|---|---|
| Median latency (p50) | 25 to 40 ms | 5 to 6 ms |
| p99 latency | baseline | -47.4% |
| Measured availability | – | 99.998% |
| Cold invocation (≈1.2% of requests) | – | ≈9 ms with image retrieval |
No code changes required
For teams already running Edge Functions, the switch is transparent: URL imports, npm packages in use, and existing configuration all keep working unchanged. A developer relying on familiar command-line tooling for their deployment workflow has nothing to adapt.
export default async (request, context) => {
const country = context.geo?.country?.code ?? "US";
const response = await context.next();
response.headers.set("x-edge-country", country);
return response;
};
export const config = { path: "/*" };
Stronger isolation between customers
Unlike V8 isolates, which share a single process across multiple executions, each Firecracker microVM gets its own virtualized kernel resources. A compromised or unstable function belonging to one customer can no longer affect workloads from a neighbor on the same physical machine, an argument that teams running their own self-hosted infrastructure know well from the opposite angle: the stronger the isolation, the less monitoring has to compensate for it.
Netlify’s median Edge Function latency drops from 25-40 milliseconds to 5-6 milliseconds, with no code changes required on the developer side.
What Netlify is planning next
By now controlling the full request cycle, Netlify says it intends to take large npm package support out of beta, revisit certain execution limits upward, and manage network routing directly rather than depending on a third-party provider for that step.
Key takeaways
The move to Firecracker microVMs sharply cuts median latency for Netlify Edge Functions without requiring any migration work from developers. Most of the benefit comes from removing a network hop to an external execution service, now brought in-house.
Announcements like this deserve a bit of distance from figures supplied by the vendor itself: cutting median latency by four or five times is a remarkable result, but it is worth re-verifying under real conditions before it ends up in a sales pitch. What matters more here is the underlying pattern: edge computing platforms are steadily bringing back in-house the pieces they were still outsourcing two years ago, a sign that the market is consolidating around a handful of proprietary architectures. — Simon Janvier
Further reading: Netlify’s technical post, “5x faster Edge Functions: from V8 isolates to Firecracker MicroVMs”.
