MicroVMs now handle Netlify’s Edge Functions requests, and the company says the change cuts latency by roughly 5x at the median while also improving reliability. The update does not affect how developers write or use the functions.
Each day, roughly a billion Edge Functions run through the system, serving clients such as Sunweb and Loto-Québec. These functions manage personalization, routing, and authentication. Up until not long ago, every request was sent out to a hosted execution service. Today, they operate within MicroVMs sitting inside Netlify’s own edge network.
The change brings about a welcoming call that runs roughly 5–6ms at the middle point, having dropped from 25–40ms on the former system. Invocations that start cold, needing images to be fetched first, come in at an average of around 9ms. The fresh arrangement sends edge function records back 5 times quicker and offers a promise of 99.998% reliability.
How the Request Travels
The request finds its way to the nearest Netlify edge node, which then handles it. That node ends the TLS connection and runs a check, matching the request’s path against the deploy’s Edge Functions routes.
When no route matches, the request heads to the cache and then to the origin server. But when a route does match, the request would leave Netlify’s network completely under the old setup. It went out over the internet, ran the edge function, and returned to Netlify to pass on.
The request remains confined to Netlify’s network throughout. Instead of reaching its destination directly, it gets handed over to a compute node sitting within that network. That node then directs the request to a MicroVM, which might already be running from a previous call or could be freshly created for a new one, depending on whether the invocation is warm or cold.
The Machine Specification
Before the request is forwarded, the edge node generates a specification for the machine tasked with running the function. That specification identifies three images by name: the runtime, Netlify’s platform image, and the edge function image. It also establishes the CPU, memory, and connection limits.
On every invocation, the request carries the spec along with it. The spec’s hash combined with site-specific details forms a service ID, which keeps two deployments with different code or different environment variables apart as distinct services. They never end up sharing a single MicroVM.
What matters most is keeping the company’s failures from ever being possible at all. A deploy that might have been compromised instead runs inside its own isolated MicroVM, so even if it somehow breaks free from the runtime, it can’t reach out to harm other customers or the underlying compute layer.
V8 isolates, no matter their name, do not provide this level of isolation.
Choosing a Compute Node
Compute nodes sit behind each region, and the edge node picks one using rendezvous hashing so that the same service always lands on the same node. That stickiness is what gives Netlify its caching strategy, since requests spread evenly across the swarm would otherwise produce a higher level of cold starts.
The quickest way to send requests to a function is to direct them all to one compute node. That is also the route to creating a bottleneck — when one heavily used function fights for resources against everything else running on that same machine. When a service draws a big portion of a region’s traffic and stays fixed to a single node, it fills up that node while shortchanging other services.
Creating the Service
The compute node takes in a request carrying a machine specification along with a service ID. It begins by checking whether a service matching that ID has already been set up. Should a match be found, the request is then passed into that service so it can send its own request into the MicroVM.
Netlify can link several MicroVMs to a single site’s Edge Functions through a service, and it permits setting parameters for scaling MicroVMs in and out. Every service is set up so that a MicroVM shuts down after handling a fixed number of requests, which keeps MicroVMs from staying active indefinitely.
The same signals tell the system to start a new MicroVM ahead of time, before an existing one shuts down.
When no service for the site’s edge functions exists on the compute node, one is made. The node then examines whether it holds every image listed in the machine specification on disk. Any that are lacking get drawn from the edge node and set down on disk. This method ensures that Netlify only draws the edge function images that are actually being used in that region.
What Developers See
Nothing about writing or using Edge Functions has changed at all. Everything still works the same: URL imports, npm packages, Node built-ins, netlify.toml declarations, and local development. The only difference is that the functions themselves are now faster and more resilient.
The Numbers Behind the Shift
Here is what Netlify reports, and the figures make the case plain.
- ~5–6ms at median (p50), down from 25–40ms on the previous infrastructure
- 47.4% faster p99 invocations
- 99.998% availability
- 5x faster edge function log delivery
Cold invocations happen on about 1.2% of all invocations and take about 9ms on average. The company says the shift also improves security and reliability, and opens up more possibilities for running complex compute at the edge.
What This Means for Customers
The availability number is the real story here, even though the median latency drop gets top billing. A distributed system promising 99.998% availability offers a solid reliability promise.
Routing and personalization features built on Edge Functions rely on those services staying available. If they fail, the request flow gets interrupted.
The initial request number stands out as well. With 1.2% calls made, the issue stays small enough for the caching approach described earlier to keep most requests ready. Yet the cold start still costing 9ms shows that the plan accepts some delay as part of how things work.
Netlify’s isolation design deserves attention too. Each deploy gets its own MicroVM, which means the shared-runtime issue common to many serverless platforms is avoided. Should a deploy be compromised, it cannot break free from its runtime and interfere with other customers.
Starting up the system takes longer than it would otherwise. A cold invocation averages 9ms, which matters for interactive apps. The median latency sits at 5–6ms, so most requests finish fast. The 99.998% availability figure shows the outliers happen rarely, pointing to a reliable setup.
The collaboration between Netlify and Unikraft, described by the latter’s team, indicates that the company is not developing this technology alone. Transitioning from a hosted execution service to running MicroVMs within its own network demands significant infrastructure effort, which reflects the ambition behind the product.
It stands out that the company describes its own trade-offs, including the hot spot risk and the cold start delay, rather than presenting only the gains. Most cloud providers share only their best-case figures. Netlify has chosen to publish both the benefits and the costs.
What results is an Edge Functions platform that moves quicker and proves itself more dependable, with no need for developers to alter even a single line of code. The pairing of those two things — a gain in performance that sits alongside no friction for the people writing the code — is precisely the sort of upgrade that draws attention.
Anyone building on Netlify will find that Edge Functions run faster and more reliably now, with no change to how your existing code behaves. The infrastructure below underwent a dramatic shift, yet the surface remained entirely unchanged.
Source material: “5x faster Edge Functions: V8 isolates to Firecracker MicroVMs,” netlify.com.
Get the Notebook.
The day's best stories and every fresh verdict, in plain English, in your inbox by seven. One email a day, no more.