Netlify troca V8 isolates por microVMs Firecracker e deixa Edge Functions 5x mais rápidas
A infraestrutura que roda cerca de 1 bilhão de invocações por dia na Netlify deixou de depender de isolates V8 hospedados fora da rede própria e passou a rodar em microVMs Firecracker, construídas com a Unikraft, dentro da própria borda.
A Netlify troca V8 isolates por microVMs Firecracker e deixa Edge Functions 5x mais rápidas
A infraestrutura que roda cerca de 1 bilhão de invocações por dia na Netlify deixou de depender de isolates V8 hospedados fora da rede própria e passou a rodar em microVMs Firecracker, construídas com a Unikraft, dentro da própria borda.
Over the past few months, Netlify rebuilt its entire Edge Functions execution infrastructure. The company detailed the change in a technical post on its official blog: the engine that processes about 1 billion invocations a day (cases like Sunweb's page personalization or Loto-Québec's cookie-based routing) stopped using V8 isolates hosted outside Netlify's network and started running on Firecracker microVMs, inside its own edge network. The work was done in partnership with Unikraft, which also published its own version of the story.
What changes under the hood
Before, every request hitting an edge function left Netlify's network, went to a hosted execution service, ran the code, and came back. That meant a trip over the public internet on every invocation. Now, the request is routed to a compute node inside the network itself, which spins up a Firecracker microVM (the same technology used by AWS Lambda) to run the customer's code.
The lifecycle of this microVM (boot, snapshot, restore, and scale-to-zero) is Unikraft's product, Netlify's infrastructure partner on the project. Each function runs in its own microVM, and each combination of deploy and environment variables becomes an isolated service, identified by a hash. Two versions of the same site never share the same microVM.
The numbers behind the "5x"
The latency gains show up mainly on warm invocations, when the microVM already exists and only needs to process the request:
| Metric | Before | After |
|---|---|---|
| Warm invocation (median, p50) | 25 to 40 ms | 5 to 6 ms |
| p99 invocation | previous baseline | 47.4% faster |
| Availability | not disclosed | 99.998% |
| Function log delivery | previous baseline | 5x faster |
Cold invocations, when the region doesn't yet have the function's images cached, happen in about 1.2% of cases and take an average of 9 ms. The microVM itself is created in under 1 millisecond and boots in about 2 ms at p99, because it brings up a lean Linux instead of a full operating system.
How the request travels through the network
The flow described by Netlify follows a fixed sequence on every call:
- The request reaches the edge node closest to the client, which terminates the TLS connection and checks whether the route matches any edge function in the deploy.
- The edge node writes a machine specification: the runtime, platform, and function images, plus CPU, memory, and connection limits.
- A rendezvous hashing algorithm picks the compute node for that service, always the same node for the same service, which keeps code and cache already warmed up.
- The compute node triggers (or creates) the corresponding Firecracker microVM and returns the response over Netlify's own network, without going out to the public internet.
The function's files are mounted as an uncompressed EROFS image and memory-mapped, so the microVM only reads the parts of the package it actually uses. When a function sits idle, microVMs scale to zero instead of waiting around; on the next call, a new instance boots up from the already-saved snapshot.
Isolation as a side effect (and the real motivation)
Netlify is direct on one point: V8 isolates, however much the name suggests isolation, don't guarantee the same level of containment as a real virtual machine. A compromised deploy runs in its own microVM and, even if it escapes the runtime, it doesn't reach other customers or Netlify's own compute layer.
This detail matters for anyone evaluating edge computing platforms: Netlify's choice of microVMs is an explicit architectural break from the isolate model the company itself used before, made precisely to reduce the risk surface among tenants sharing the same edge infrastructure.
What's already available without changing anything
According to Netlify, the change is transparent for anyone already using Edge Functions: URL imports, npm packages, native Node modules, declarations in netlify.toml, and the local development workflow all keep working exactly as before. There's no migration step, and pricing hasn't changed.
For anyone deciding whether it's worth moving application logic to the edge (routing, personalization, authentication, cookie checks), here's the practical takeaway: the same cost now delivers a median latency of 5 to 6 ms instead of 25 to 40 ms, which changes the calculation of where it's worth placing code that used to live only in the central backend.
What this new foundation unlocks
Netlify lists three fronts that the new infrastructure makes viable:
- npm package support moving out of beta: today it works with caveats around native binaries and runtime file reads, limitations that existed because of the isolate model.
- A review of operating limits: the current 50 ms of CPU per request, 512 MB of memory, and 20 MB of compressed code come precisely from the isolate-based model, and the company signals it intends to reassess them.
- Computing inside the network itself: any feature that depends on controlling the network path, rather than reaching a third-party service over the public internet, becomes possible to build.
None of these three points shipped along with the announcement: they're possibilities opened up by the new architecture, not features already delivered. Netlify gave no timeline for them, and the post itself treats the migration as a foundation for future work, not as a closed chapter.
What remains open
The company didn't detail how the microVM model behaves under extreme traffic spikes from a single customer, beyond mentioning that, above a certain threshold, a service's affinity to a specific node is relaxed to spread the load. There's also no public data on how the new pricing model (if any) would track higher CPU and memory limits, should the announced review actually happen. For anyone running edge functions in production on Vercel, Cloudflare, or Netlify itself, the practical thing to watch is whether this slack in limits and packages turns into a concrete contract change in the coming months.
Translated from the Brazilian Portuguese original · Read the original
Survey shows Rust's SIMD ecosystem more mature, but fragmented, in 2026
An independent survey on the state of SIMD in Rust in 2026 compares five vectorization libraries and shows what changes for those who need performance in databases, vector search, and AI inference.