Pimp My IDE / garage dispatch
Back to garage
September 30, 2026 | edge runtimes / placement / measurement

The engine changed. So did the road.

Netlify moved Edge Functions from a hosted V8 service to Firecracker MicroVMs inside its own edge network. The speedup belongs to the whole route.

Do not turn one platform migration into "MicroVMs beat isolates." Pin the network path, runtime boundary, cache state, workload, and percentile before using the number.

The headline hides a platform move.

Netlify reports that warm Edge Function invocations now cost about 5 to 6 milliseconds at the median. The previous system took 25 to 40 milliseconds. Netlify also reports 47.4 percent faster p99 invocations, 99.998 percent availability, and edge-function logs delivered five times faster.[1]

The old request crossed the internet to a hosted execution service. The new request stays inside Netlify's network and reaches a compute node in the same edge system. That placement change sits beside the runtime change. The published result does not isolate either variable.

A faster route is not proof that one sandbox type is faster in general.

The new route does more work locally.

An edge node terminates TLS, matches the route, and writes a machine specification. The specification names runtime, platform, and function images. It also carries CPU, memory, and connection limits. A hash plus site-specific data becomes the service ID.

Rendezvous hashing sends the service back to a familiar compute node when possible. That keeps code and images nearby. Netlify says it relaxes that stickiness when a busy service could form a hot spot. Local DNS resolvers and circuit breakers cover two more parts of the request path.[1]

The cold path needs its own line.

Netlify says a function's MicroVM is created in under one millisecond and starts in about 2 milliseconds at p99. After the JavaScript server listens, the platform takes a snapshot. A restored instance can begin before the entire memory image has been read.

A region that has not seen the service must fetch missing images. Netlify reports that this cold case occurs on about 1.2 percent of invocations and takes about 9 milliseconds on average. Those values describe Netlify's observed fleet. Firecracker's project page gives broader VMM targets, but it does not verify Netlify's production measurements.[2]

Compatibility is a separate claim.

Netlify says the migration keeps URL imports, npm packages, Node built-ins, netlify.toml declarations, and local development unchanged. Its docs still describe a Deno-based runtime for JavaScript and TypeScript at the edge.[3]

That is a useful provider promise. A team with native packages, runtime file access, latency budgets, or strict failure behavior should still run its own canary. The component below creates that measurement plan. It does not benchmark either runtime.

Interactive makeover / runtime route dyno

Put every number on its lane

Traditional purpose replaced: a benchmark summary table. Better version: one native selector changes the shared scale, claim boundary, and copyable test card without mixing unlike measurements.

Inspect one claim

These positions summarize the cited report. They are not live telemetry.

Dyno channel
Vendor measurementWarm p50 / milliseconds
Shared comparison scale

Runtime route dyno

The result belongs to the full migration.

The old hosted path and the new in-network MicroVM path differ in placement, routing, cache behavior, and execution boundary.

The completed card still requires your host, revision, workload, samples, and failure result. Selecting a channel does not create evidence.

Migration review / four lanes

Keep each change attached to its test.

01 / ROUTE

Draw every hop

Record TLS termination, edge matching, external hops, compute placement, and response return.

02 / STATE

Split warm and cold

Define cache state, image presence, snapshot state, region history, and sample counts.

03 / BOUNDARY

Name the sandbox

Record process, kernel, virtual-machine, tenancy, resource, and network boundaries.

04 / PROOF

Replay your workload

Measure median, tail, failures, logs, and rollback on the exact function revision.

Sources read

Source log and evidence boundary
  1. Netlify, "5x faster Edge Functions: v8 isolates to Firecracker MicroVMs", published September 29, 2026 and read September 30, 2026. This first-party report supplies the old and new architecture, warm median range, relative p99 change, availability, cold-path rate and average, request route, image handling, snapshot behavior, and compatibility claim.
  2. Firecracker project overview and FAQ, read September 30, 2026. This first-party project page documents KVM-based isolation, the reduced device model, supported processors, REST control API, rate limiters, startup target, and memory-overhead target. It does not verify Netlify's fleet measurements.
  3. Netlify Edge Functions overview, last updated April 16, 2026 and read September 30, 2026. The product docs describe supported languages, Deno-based runtime, deployment workflow, request uses, caching option, and linked limits.
  4. Unikraft, "How Netlify Runs all of Edge Functions on Unikraft microVMs", published September 29, 2026 and read September 30, 2026. This implementation partner account confirms its role in the migration. It is not an independent benchmark.
  5. Hacker News discussion, exact item 49912444, checked September 30, 2026. It raised the key attribution question about runtime type versus network placement. Comments are not used as proof of performance or security.

Evidence boundary: this dispatch reports vendor measurements and architecture descriptions. It does not claim that Firecracker MicroVMs are always faster than V8 isolates. It does not independently verify Netlify's latency, availability, isolation, or compatibility results.