Netlify Edge Functions execute customer code inside the full runtime, in the request path of production sites. Until recently that execution layer belonged to a third-party platform, so every request for a new capability was out of Netlify’s hands. Now they run on Unikraft microVMs, across every tier, from Free to Enterprise, as detailed in Netlify’s own engineering blog post. Netlify also gained something it never had before: Ownership of the runtime itself, and with it a roadmap of capabilities the previous architecture could not offer. Since switching to Unikraft, Netlify’s edge functions overhead for each request dropped from 50 ms to 6 ms.

The tradeoff used to be that if you wanted compute in the request path, you gave up control of the runtime. Unikraft gave us the microVM foundation and now everything above it is ours to decide. That’s the difference between shipping what a vendor supports and shipping what our customers ask for.

— Dana Lawson, CTO, Netlify

A full runtime in front of every important request

Netlify is a full-stack, AI-native platform for production-grade applications, home to almost 20 million developers and thousands of enterprises. Edge Functions are its primitive for arbitrary compute at the edge: Customers ship code that runs close to their users, before a request reaches the site. Teams use them for regional personalization, authorization, and routing logic, and customers count on them keeping time-to-first-byte (TTFB) low. That position in the stack makes for some extremely tight timing.

Within single-digit milliseconds, we need to find a machine, allocate it, boot the runtime, load the customer’s code, and run their routing logic. And sometimes that’s during a spike of 200x, because a customer has a launch.

— Ivan Zarea, Director of Platform Engineering, Netlify

Thus, there are two major constraints for Netlify Edge Functions: (a) overhead must be low enough that customers add logic to the request path without hesitating and (b) the system must absorb request-shaped load, including 200x spikes, without falling over. In addition to that, Netlify ships changes to its own platform code frequently and needs to roll them out without redeploying the fleet.

Where the previous setup hit its limits

Before Unikraft, Netlify handed Edge Functions requests to a third-party hosted platform that owned the load balancing, the compute allocation, and the provisioning. It worked, but it capped the product in three major ways:

Co-Designing Before the Contract

Netlify was always open and direct about the collaboration. When we started out, the technology was convincing but not yet everything Netlify needed. Instead of a vendor evaluation, the two teams ran a design partnership. Among other issues, we have worked together on how load balancing would work and how customer code images would be cached, on a shared whiteboard.

Important parts of our solution were designed together with the Unikraft team even ahead of an official go/no-go. That gave us the confidence that as soon as we discovered unknowns, we could work them out together. Problems at this scale bring unknowns to light. There is no other way.

— Ivan Zarea, Director of Platform Engineering, Netlify

The go/no-go itself was formal. In November 2025 Netlify opened a decision document with three options on the table: Keep the existing setup, build the platform in-house, or migrate to Unikraft. Since you’re reading this, you know what they decided :)

Migrating every tier without customers noticing (mostly)

The migration was a multiple-months project, where Netlify and Unikraft collaborated closely, with weekly check-ins, animated slack conversations, and shared dashboards. Netlify validated the new platform against its largest customers’ traffic patterns, and scheduled maintenance windows before cutting over. Today, every tier of Netlify Edge Functions runs on Unikraft.

Six milliseconds to say yes

The headline result is the per-request overhead.

While it was 30-50 milliseconds for starting an instance on the previous infrastructure, it’s only 6 milliseconds on the new one. That’s a pretty drastic difference.

— Aarthy Kolachalam Chandrasekhar, Staff Software Engineer, Netlify

Six milliseconds completely changes what Netlify can offer. The vision behind Edge Functions was compute in the request path without performance impediments which opens a host of new possibilities.

Being able to say you can add routing decisions or personalization to a country and it costs you six milliseconds — that is extremely powerful.

— Ivan Zarea, Director of Platform Engineering, Netlify

A VM boot faster than a network round trip

Conventional wisdom says virtual machines are too slow for per-request compute. Entire product categories exist because VM boots were assumed to cost seconds. On Netlify’s fleet, booting a Unikraft microVM costs 2 milliseconds at the 99th percentile.

The P99 for booting a VM is now 2 milliseconds. That means getting the VM booted onto the correct machine with their code on disk… everything before the runtime itself starts. That’s fantastic.

— Jake Champion, Staff Software Engineer, Netlify

Feeding that boot path is an image-loading mechanism the two teams designed specifically for Netlify. Customer code images load on demand. When a request lands on a node, the node checks its local cache, and on a miss pulls the image directly from Netlify. The cache decision takes under a millisecond.

The same mechanism gives Netlify something they wanted as much as speed: rollout control. Because images resolve at request time, Netlify flags versions per site, per customer, and per account tier. Changes to the platform code reach free-tier sites quickly and enterprise sites on a slower, deliberate cadence, with no fleet redeploy.

Reliability and scale

Reliability was always a hard requirement for a company operating at Netlify’s scale. Today, Edge Functions run at just shy (99.998%) of five nines of availability, for compute that fronts every important request to a customer site.

The platform’s behavior under load shows up in the operational details too. Log delivery, which customers watch while debugging, dropped from a median of 2.5 seconds on the previous platform to 500 milliseconds, including Netlify’s enrichment pipeline, and that doesn’t change under stress.

This morning, log volume in one region increased 15 times. It went from about a thousand lines per second to fifteen thousand, and it didn’t change ingestion latency at all. It just kept shipping as normal. That’s what we want.

— Jake Champion, Staff Software Engineer, Netlify

Owning the runtime

Unikraft provides everything up to the microVM; what runs inside it now belongs to Netlify.

We now own the runtime. Unikraft provides everything up to the microVM, and what’s inside, we get to decide. With our previous implementation that was fixed. Having the ability to control that and make our own decisions unlocks so much for us.

— Jake Champion, Staff Software Engineer, Netlify

Runtime ownership is also where the new product surface comes from. Edge Functions on Unikraft now have the potential to support what customers had been asking for and the old architecture could not deliver: Native NPM modules and filesystem access. Beyond that, the platform can also run Node at the edge, which customers had also requested, and non-JavaScript runtimes too.

Isolation that came along for free

Security was not on the list of migration drivers, but the team counts it as a rather welcome side effect: Every customer’s code runs behind its own hardware-backed microVM boundary with VM-level network policies. Performance and isolation strength usually pull in opposite directions, but here both improved at once.

Having the microVM boundary between different customers’ code is really nice. We’re in control of it and we have more insight into it.

— Jake Champion, Staff Software Engineer, Netlify

Working with the team

A year on from the first conversations, the design partnership is still how the two teams operate: Co-designed features like on-demand image loading shipped because Netlify’s constraints dictate them, and the collaboration continues as Edge Functions expands on the new foundation.