Container or microVM cold start is the time between requesting an instance and it being ready to serve traffic. Among technologies with an unambiguously documented, citable measurement, the shortest cold starts belong to microVMs: Firecracker (under 125 ms, official project documentation) and gVisor (50–100 ms, official Google documentation) — significantly faster than fully isolated VMs like Kata Containers.
Quick Overview
What you’ll learn:
- What container/microVM cold start actually is and why it’s measured differently across runtimes
- Firecracker: under 125 ms — why it’s this fast and where it’s used (AWS Lambda, Fargate)
- gVisor: 50–100 ms with under 1% CPU overhead for most applications
- Kata Containers: 150–300 ms — the price of full guest-kernel isolation
- Docker vs Podman vs containerd — why we deliberately do NOT publish hard numbers (conflicting sources)
- AWS Lambda: how container-image cold start compares to a classic ZIP package
- A comparison table for every technology, with links to sources
Who this article is for:
- Platform Engineers/DevOps designing serverless and sandboxing architecture
- Tech Leads weighing the security-vs-startup-speed trade-off
- Teams migrating workloads to multi-tenant environments (Cloud Run, Fargate, Kubernetes)
Reading time: 6 minutes
What is container/microVM cold start
Cold start is the delay incurred when a new instance (container, microVM, serverless function) has to be started from scratch — as opposed to a “warm start”, where an existing, already-initialized instance is reused. In serverless and multi-tenant environments (AWS Lambda, Google Cloud Run, Kubernetes with autoscaling), cold start directly affects the latency of the first request after scaling from zero or scaling up.
How long it takes depends on exactly what has to be started: a plain container process (sharing the host kernel) is usually faster to start than a full virtual machine with its own minimal guest kernel (a microVM). That’s the fundamental trade-off between speed and security isolation.
Comparison table: container and microVM cold start times (2024–2026)
| Technology | Isolation type | Cold start | Source |
|---|---|---|---|
| Firecracker (microVM, AWS Lambda/Fargate) | microVM (dedicated guest kernel) | <125 ms | Firecracker — official AWS/CNCF repo (2024) |
| gVisor (sandboxed runtime, Google Cloud Run/GKE) | userspace kernel (syscall interception) | 50–100 ms typical | gVisor Performance Guide (2024) |
| Kata Containers (VM-based, full isolation) | microVM with full guest kernel | 150–300 ms (depends on VMM/configuration) | Kata Containers 2.0 — Design & Metrics (2024) |
| containerd / CRI-O / runc (standard Linux containers) | shared host kernel | qualitative: on the order of hundreds of milliseconds in synthetic tests, heavily dependent on host/load | no single credible, repeatable measurement — we don’t publish a specific number |
| Docker vs Podman (rootless/rootful) | shared host kernel | qualitative: both technologies land in the same performance class for typical workloads | publicly available sources contradict each other (sometimes Docker faster, sometimes Podman, depending on configuration) — deliberately no numbers, per EITT’s “zero fabricated metrics” policy |
Methodology note: the numbers in this table come exclusively from official project documentation (Firecracker, gVisor) or an aggregation of the official repository (Kata Containers — flagged as medium confidence, since the exact value depends on VMM configuration). Where publicly available benchmarks conflict (Docker vs Podman, generic containerd/CRI-O/runc), we deliberately withhold a specific millisecond figure — consistent with EITT’s policy of never publishing our own unverified measurements or citing conflicting sources as fact.
Firecracker: under 125 ms — why it’s this fast
Firecracker is an open-source virtual machine monitor (VMM) built by AWS, and it underpins AWS Lambda and AWS Fargate. Instead of emulating full hardware (like a traditional VM), Firecracker implements a minimal, stripped-down device model — only what’s needed to boot a Linux kernel and run the application. The result: cold start under 125 ms and memory overhead under 5 MiB per microVM (official project documentation).
This lets a single host run thousands of isolated microVMs, each with its own guest kernel — giving security isolation close to a full VM, with a startup time much closer to a container’s.
gVisor: 50–100 ms with under 1% CPU overhead
gVisor is Google’s sandboxed runtime, used in Google Cloud Run and GKE Sandbox, among others. Instead of full virtualization, gVisor implements a userspace kernel (Sentry) that intercepts an application’s system calls and handles them in its own isolated implementation — without direct access to the host kernel.
Per Google’s official documentation, 70% of tested applications see under 1% CPU overhead compared to native execution, and building seccomp rules (part of the startup process) takes around 10 ms. Typical cold start falls in the 50–100 ms range — slower than a bare container process, but still an order of magnitude faster than a full virtual machine.
Kata Containers: 150–300 ms — the price of full isolation
Kata Containers combines a container-compatible API (OCI/Kubernetes CRI-compliant) with full virtual-machine isolation — each container runs in its own lightweight VM with a dedicated guest kernel. This is the strongest isolation among the compared technologies, but it comes at the cost of startup time: 150–300 ms depending on the VMM used (QEMU, Cloud Hypervisor, Firecracker as a backend) and configuration.
Kata is a fit for multi-tenant environments with elevated security requirements (e.g. running untrusted customer code in the same Kubernetes cluster), where the extra tens-to-hundreds of milliseconds of cold start is an acceptable price for a hard kernel-level isolation boundary.
Docker vs Podman vs containerd — why no hard numbers
We deliberately do NOT publish a table with specific milliseconds for Docker vs Podman vs containerd/CRI-O/runc. Reason: publicly available benchmarks on this topic contradict each other — some sources show Docker faster, others show Podman faster, with discrepancies reaching several-fold depending on mode (rootless vs rootful), host configuration, and tool version. None of these sources clears the credibility bar we apply to numbers in this article (official project documentation, or an unambiguously confirmed, repeatable benchmark).
Practical takeaway: for typical production workloads, cold-start differences between Docker, Podman, and containerd are usually less significant than the architecture choice (container vs microVM) described in the sections above. For a full architectural comparison of these three runtimes (security, licensing, Kubernetes integration), see the link in the “Read Also” section below.
AWS Lambda: container-image cold start vs a ZIP package
The serverless context deserves a separate mention. Per AWS’s official blog post Understanding and remediating cold starts: an AWS Lambda perspective (2024), AWS introduced improvements that reduced cold start for functions packaged as container images by up to 15x compared to earlier versions of that mechanism. This shows cold start isn’t a fixed property of a technology — it’s also a function of the hosting platform’s own optimization work, with the same container images starting significantly faster today than a few years ago.
Read Also
- Docker vs Podman vs containerd — which container runtime to choose in 2026 — a full comparison of architecture, security, and licensing across the three main container runtimes
- Kubernetes and Docker: Automating Cloud Application Management - A Guide — how the container runtime fits into a broader Kubernetes cluster architecture
Build Your Skills
This topic connects to the Docker and Kubernetes: Building and Scaling Container Applications course. Check the program and sign up to build your skills with EITT’s experts.
Frequently Asked Questions (FAQ)
Which runtime has the shortest cold start?
Among technologies with a credible, officially documented measurement, Firecracker (under 125 ms) and gVisor (50–100 ms) have the shortest, fully citable start times. Kata Containers, despite offering full VM-level isolation, typically needs 150–300 ms.
What’s the difference between a microVM and a container when it comes to startup?
A container shares the host’s kernel, so starting it mostly means starting a process — which is typically fast. A microVM (Firecracker, Kata Containers) boots a separate, minimal guest kernel inside an isolated virtual machine, giving stronger security isolation at the cost of extra startup overhead.
Is Docker slower than Podman at container startup?
Publicly available Docker vs Podman benchmarks contradict each other — some show Docker faster, others show Podman faster, depending on configuration (rootless vs rootful) and host. Without one credible, repeatable source, we don’t publish specific numbers here — we treat this comparison as qualitative.
Can AWS Lambda container-image cold start be improved?
Yes — per AWS’s official blog, the platform introduced optimizations that cut container-image cold start by up to 15x compared to earlier versions of the mechanism. That’s a result of optimizations to the hosting platform itself, not application-side changes.