Skip to content
Today
Sections

Build Independently confirmed2 publishers 2 min read Published Updated

Firecracker MicroVMs inside Netlify's own network cut Edge Function overhead to 5-6 ms

Netlify moved Edge Functions off hosted V8 isolates onto Firecracker MicroVMs in its own network, cutting warm overhead from 25-40 ms to a 5-6 ms median. A dev.to analysis argues that for other edge teams, removing an external network hop can matter as much as a faster runtime.

The Engineer · Build desk

Send a correction

Illustration accompanying Firecracker MicroVMs inside Netlify's own network cut Edge Function overhead to 5-6 ms
Generated illustration

What happened

  • Netlify also reports 47.4 percent faster p99 invocations, 99.998 percent availability and log delivery about five times faster than before.
  • Unikraft, which worked with Netlify on the execution layer, reports a 2 ms p99 for MicroVM startup across Netlify's fleet.
  • Netlify says its Edge Functions handle about a billion invocations a day, so any per-request overhead is paid at very large volume.
  • About 1.2 percent of invocations hit a node that has never served the function and must fetch its images before running anything.

Why it matters

  • What it limits constraint Netlify measured its warm figure after the outside hop was gone. A team that moves to MicroVMs but keeps an external execution provider in the path should budget for that hop on its own.
  • What it costs cost Owning the path moves work the hosted provider used to absorb, including provisioning, image distribution, placement and logging, onto Netlify's own operations staff and fleet.
  • What's now possible capability Because the service ID comes from the spec plus site data, a platform can give every deploy its own MicroVM and still send that deploy's traffic to nodes that already hold its image.

The two speed figures measure different events. Unikraft's startup number is the time to boot a MicroVM [12]. Netlify's headline number is median overhead on a warm invocation [2]. On each matching request, the platform has to pick compute, start or reuse an execution environment, run the customer's code and return the result [13]. In the usual serverless sense, warm means the reuse branch. Boot time should therefore sit mostly outside both the old and new warm figures. The warm saving still works out to roughly 19 to 35 ms per request [15].

The route is the likelier source. Before the move, a matching request left Netlify's network for a hosted V8-isolate service. That service ran the code and handled provisioning and much of the runtime environment [3]. Now the edge node that terminates TLS checks the deployment's routes and hands a match to a regional compute node inside Netlify's network [4]. The dev.to analysis puts placement, network hops, image availability, service lookup, logging and failure recovery on the critical path next to runtime startup [17]. Netlify's reported figures do not break the overhead down by component. They show stronger per-deploy separation and lower latency arriving in the same move, and they do not show which change saved the milliseconds.

Customers write Edge Functions largely as before [1]. The new work sits underneath. Before forwarding, the edge node writes a machine spec with three image layers (the runtime, a platform image and the customer's function image) plus CPU, memory and connection limits [14]. Netlify hashes that spec with site-specific information into a service ID. Different deploys or environment-variable sets get different services and do not share a MicroVM [5]. The analysis describes this as making deployment identity part of the isolation boundary instead of a convention on a shared process [7]. I think it is the strongest part of the design. The service ID that decides which MicroVM a request may share is also the key that rendezvous hashing uses to choose a node [8].

Sticky placement helps on repeat traffic. The same service normally lands on the same node in a region. An image fetched once stays on disk, and a running MicroVM or snapshot stays useful [8]. Sticky placement works well until one tenant has a very good day. Above a threshold, Netlify spreads a hot service across a slice of nodes and gives up some cache warmth for capacity [9].

The slow path that remains is image distribution. Applied to Netlify's daily volume [6], the cold-path share [11] comes to roughly 12 million requests a day that wait for image layers before any customer code runs [16].

What to watch

  • Whether Netlify publishes a breakdown of the warm-overhead drop that separates the removed network hop from runtime and placement changes.
  • Latency on the cold image-fetch path, and whether its roughly 1.2 percent share shrinks as images spread across regional nodes.
  • Whether the threshold at which Netlify spreads a hot service across several nodes becomes documented or configurable per site.

Clarity's read

What the record supports and how the coverage leans. The claims behind it follow.

Reality

Evidence45
Adoption75
Hype gap+15
Incentives65
Confidence55
Why these scores

Claim ledger

Ranked by verification strength, evidence, and original report placement.

  1. [1]

    Netlify moved from a hosted V8-isolate execution service to Firecracker MicroVMs running inside its own edge network, while keeping the programming model for customers largely unchanged.

    Reported Supported Source: dev.to analysis of Netlify's migrationView cited source
  2. [2]

    According to Netlify's engineering write-up, warm invocation overhead fell from roughly 25-40 ms on the previous infrastructure to about 5-6 ms at the median.

    Reported Supported Source: Netlify engineering write-up, as reported by dev.toView cited source
  3. [3]

    On Netlify's previous architecture, a matching request left Netlify's network for a hosted execution service based on V8 isolates; that provider handled execution, provisioning and much of the runtime environment, creating a network boundary Netlify did not control.

    Reported SupportedView cited source
  4. [4]

    In the new path, the edge node that terminates TLS checks the deployment's Edge Function routes and, if a route matches, forwards the request to a regional compute node inside Netlify's network rather than to an external execution provider.

    Reported SupportedView cited source
  5. [5]

    Netlify hashes the machine specification together with site-specific information to derive a service ID; different deploys or environment-variable sets map to different services and do not share a MicroVM.

    Reported SupportedView cited source
  6. [6]

    Netlify says its Edge Functions now handle about a billion invocations each day.

    Reported Supported Source: Netlify, as reported by dev.toView cited source
  7. [7]

    The dev.to analysis says the service-ID design makes deployment identity part of the isolation boundary instead of a convention layered on top of a shared process.

    Reported Supported Source: dev.to analysisView cited source
  8. [8]

    Netlify uses rendezvous hashing on the service ID so the same service normally lands on the same compute node in a region; later requests can reuse an Edge Function image already on disk, and an existing MicroVM or snapshot can stay useful for that service.

    Reported SupportedView cited source
  9. [9]

    Because pure stickiness can make a busy service saturate its node, Netlify relaxes placement above a threshold and spreads a hot service across a slice of nodes, trading some cache warmth for capacity.

    Reported SupportedView cited source
  10. [10]

    Netlify reports 47.4 percent faster p99 invocations, 99.998 percent availability, and log delivery that is about five times faster.

    Reported Supported Source: Netlify, as reported by dev.toView cited source
  11. [11]

    Netlify reports that the cold path, where a node that has never served a function must obtain the relevant images before it can run anything, occurs on about 1.2 percent of invocations.

    Reported Supported Source: Netlify, as reported by dev.toView cited source
  12. [12]

    Unikraft, which worked with Netlify on the execution layer, reports a 2 ms p99 for MicroVM startup in Netlify's fleet.

    Reported Supported Source: Unikraft, as reported by dev.toView cited source
  13. [13]

    If a request matches a configured route, the platform must select compute, start or reuse an execution environment, run customer code, and return the result before the request can continue.

    Reported SupportedView cited source
  14. [14]

    Before forwarding the request, the edge node writes a specification for the machine that should execute the function, with three image layers (the runtime, a platform image and the customer's Edge Function image) plus CPU, memory and connection limits.

    Reported SupportedView cited source
  15. [15]

    The warm invocation overhead reduction is roughly 19 to 35 ms per request.

    Derived Supported
  16. [16]

    About 12 million Edge Function invocations a day take the cold path that requires an image fetch.

    Derived Supported
  17. [17]

    The dev.to analysis says runtime startup time is only one term in request latency, and that placement, network hops, image availability, service lookup, logging and failure recovery all sit on the critical path too.

    Reported Insufficient Source: dev.to analysisView cited source
  18. [18]

    The dev.to analysis argues that removing an external hop can matter as much as making the runtime itself faster.

    Reported Insufficient Source: dev.to analysisView cited source

Sources

2 independent publishers whose own reporting we read for this story.

  1. dev.to

    2 articles · October 8, 2026

    MicroVMs at the Edge: What Netlify's Firecracker Migration Actually Changed

  2. netlify.com

    1 article · October 3, 2026

    5x faster Edge Functions: How we replaced v8 isolates with Firecracker MicroVMs

Topics and entities

Topics

Entities