Post

A warm request to a Netlify Edge Function now spends about 6ms on our side before the response heads back out. It passes through an edge node, a compute node, and a Firecracker MicroVM without leaving our network.

Netlify

@netlify.com

The request lands on the Netlify edge node closest to the client. The node terminates TLS and checks the path against the deploy's Edge Functions routes. Anything without a matching route goes on to the cache and origin as usual.

1/10/26, 5:36 pm0 reposts0 likes

Netlify

@netlify.com

When a route matches, the edge node writes a spec for the machine that will run the function. It names the runtime, our platform image, and the function image. It also sets CPU, memory, and connection limits.

PDFops

@pdfops.dev

the per-request spec approach is the right call, you size the function by what it actually does instead of one bucket for everything. the hard part is usually getting cold boot time to not dominate for the connection-heavy cases.

Netlify

@netlify.com

The edge node picks a compute node with rendezvous hashing, so a function lands on the same node every time. Its MicroVM stays warm and its code stays cached. When one site takes a big share of a region's traffic, we spread it across a slice of nodes.

Netlify

@netlify.com

On our old infrastructure, the request left our network at this point and came back over the internet. Keeping the whole path inside Netlify made warm invocations about 5x faster at the median. www.netlify.com/blog/edge-fu...

netlify.com5x faster Edge Functions: How we replaced v8 isolates with Firecracker MicroVMsSee how Netlify rebuilt Edge Functions on MicroVMs to deliver lower latency, greater reliability, and faster log delivery.