MicroVM Cold Start: Where the Milliseconds Go

MicroVM Cold Start: Where the Milliseconds Go

Microvm cold start gets quoted as a single number, but it is four phases with different owners. When a team says their sandbox boots in 150 milliseconds, only part of that is the virtual machine manager. The rest is your kernel, your init, and your application.

Separating the phases tells you which team can actually make the number smaller. It also ends the argument between platform and application engineers, because each phase has exactly one owner. Budgets per phase beat a single latency target every time.

The four phases

First, VMM and KVM setup: allocate memory, create vCPUs, attach devices. The Firecracker paper from NSDI 2020 reports microVM initiation in as little as 125 ms and creation rates up to 150 per second per host, with memory overhead under 5 MiB per VM. Second, guest kernel boot: a minimal kernel reaches userspace in tens of milliseconds; a distro kernel with drivers takes far longer. Third, userspace init: your init system, mounts, agents and service startup. Fourth, application readiness: language runtime warmup, dependency loads, connection pools.

Which phase dominates

In our reading of vendor disclosures and the paper, phases one and two are already small and barely move. Phase three and four are where real workloads spend their time, and they scale with your image, not with the VMM. That is why vendor cold-start claims differ so much from user experience: E2B claims millisecond-ready boots and Daytona claims sub-90ms creation, as compiled by MarkTechPost, while a Node app with a cold require cache adds hundreds of milliseconds nobody advertises.

Snapshot restore changes the curve

Restoring a memory snapshot skips kernel boot and most of userspace init, resuming at a frozen point instead.

The cost moves to snapshot storage and the first touch of restored pages. For agent fleets that boot the same image thousands of times, snapshots plus a warm pool turn cold start into a scheduling problem. Snapshots also change failure semantics in a useful way: a bad restore is discarded and retried, not debugged at 3am. That turns the rarest and worst class of boot bug into an ordinary retry, which on-call engineers forgive far more easily. We covered the fleet-side version of this in microVM benchmarks and in how microVMs speed up CI.

Optimisation order that works

1. Trim userspace: smaller init, fewer services, static binaries where possible.
2. Warm what repeats: dependency caches, language runtime snapshots, connection preconnect.
3. Snapshot and pool: restore instead of boot for hot images.
4. Only then tune the VMM: vCPU count, memory balloon, device model.

Teams that start at step four optimise the smallest slice first and wonder why nothing moved. The same logic applies when choosing isolation in the first place, as we explain in what a microVM is.

A budget template that survives contact

Write the cold-start budget as four numbers with four owners: VMM setup, kernel boot, userspace init, application ready. Measure them once per image in CI and publish the trend next to the build. Regressions then arrive as a diff, not as a complaint from an agent fleet at 3am.

Teams that track only the total lose the ability to assign blame kindly, and latency work stalls without an owner. Four numbers, four names, one chart. That is the whole overhead, and it is smaller than the argument it prevents.

Verdict

Treat cold start as a budget with four line items. The VMM line is already spent well by Firecracker-class managers; your image and init hold almost all the remaining savings, and snapshots convert the rest into an operations problem with known answers.

Limitations

• The 125 ms and 150-per-second figures are the 2020 paper's measurements on their hardware, but not on ours.
• Vendor cold-start claims are marketing measurements with undefined images; however, we cite them as claims.
• We cannot reproduce the phases here; the split comes from the paper and vendor docs.
• Snapshot restore costs depend on storage backend, which we do not model here.

FAQ

Is microVM cold start slower than container start?

Fresh boot is usually slower by tens of milliseconds of kernel work; with snapshot restore the gap largely closes or inverts.

What is the single biggest win for agent fleets?

Snapshot restore plus warm pools, because agent images repeat constantly and boot the same way every time.

Does more RAM make cold start worse?

Yes for fresh boots and snapshot restore, since both touch more memory; right-size instead of headroom-budgeting.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "BlogPosting",
      "headline": "MicroVM Cold Start: Where the Milliseconds Go",
      "datePublished": "2026-10-23",
      "dateModified": "2026-10-23",
      "author": {"@type": "Organization", "name": "Krova Cloud Engineering"},
      "publisher": {"@type": "Organization", "name": "Krova Cloud"},
      "mainEntityOfPage": "https://krova.cloud/blog/microvm-cold-start-where-milliseconds-go"
    },
    {
      "@type": "FAQPage",
      "mainEntity": [
        {
          "@type": "Question",
          "name": "Is microVM cold start slower than container start?",
          "acceptedAnswer": {"@type": "Answer", "text": "Fresh boot is usually slower by tens of milliseconds of kernel work; with snapshot restore the gap largely closes or inverts."}
        },
        {
          "@type": "Question",
          "name": "What is the single biggest win for agent fleets?",
          "acceptedAnswer": {"@type": "Answer", "text": "Snapshot restore plus warm pools, because agent images repeat constantly and boot the same way every time."}
        },
        {
          "@type": "Question",
          "name": "Does more RAM make cold start worse?",
          "acceptedAnswer": {"@type": "Answer", "text": "Yes for fresh boots and snapshot restore, since both touch more memory; right-size instead of headroom-budgeting."}
        }
      ]
    }
  ]
}