MicroVM vs Docker for AI agent isolation: which is faster

Your agent generates Python at runtime, executes it in a sandbox, and returns the result. After meeting the required isolation boundary, speed is the first operational concern because users notice latency. Isolation is non-negotiable because the code inside is untrusted. Cost also matters when you're running executions at high volume.

Docker gives you speed and a toolchain every engineer on your team already knows. MicroVMs give you a hardware-enforced isolation boundary. Measured boot and resume differences depend heavily on what you count. The gap runs in both directions depending on measurement scope. The isolation boundary usually decides the architecture. Boot and resume measurements rarely do.

Which one you need depends on what code is running and who wrote it. Measured benchmarks, published CVE mechanisms, and standards guidance support a comparison of performance, isolation strength, and operational tradeoffs.

TL;DR:

• Isolation decides the architecture: Docker shares the host kernel. MicroVMs give each workload its own kernel behind hardware virtualization. That boundary matters more than boot time.
• Performance gap is narrow: Firecracker boots to userspace in under 125ms. Docker warm starts land in a similar range. The gap disappears within agent sessions lasting minutes.
• Resume is the real advantage: Docker has no production-grade resume primitive. MicroVM hypervisor snapshots restore memory and processes in milliseconds.
• Container escapes keep shipping: CVE-2024-21626 and CVE-2022-0185 both produced real host access from inside containers. AI-generated code compounds this risk on every request.
• Choose by code authorship: Containers fit trusted, team-written code. MicroVMs fit untrusted, AI-generated code that no human reviewed before execution.

Performance comparison: boot time, runtime, and overhead

Traditional VMs emulate full hardware and legacy devices. This creates an expectation that Docker will be faster than anything with "VM" in the name. That instinct does not hold for microVMs built for fast boot and low overhead. Published figures vary widely depending on what gets measured. Scope matters more than any single number.

The isolation boundary is the real difference

Docker containers isolate with Linux namespaces for PID, network, mount, and users. They use cgroups for resource limits.

Every container on a host shares that host's kernel. The shared kernel is therefore a shared attack surface. A kernel vulnerability exploitable inside one container exposes the host and every neighboring container. Under NIST SP 800-190, containers "do not offer as clear and concrete of a security boundary as a VM."

MicroVMs include Firecracker and Cloud Hypervisor; QEMU also has a microvm machine type. They boot a dedicated kernel per workload inside a lightweight virtual machine. Hardware virtualization draws the boundary through the Kernel-based Virtual Machine (KVM) interface. It uses Intel VT-x or AMD-V.

An exploit inside the microVM reaches the guest kernel, not the host. Escaping generally requires exploiting a vulnerability in the hypervisor, VMM, or virtualized-device/emulation layer. That is a far smaller target than the Linux syscall interface. Its x86-64 table now reaches entry number 471. That breadth gives attackers more host-facing behavior to probe than a purpose-built microVM device model.

For conventional containers, the trusted computing base typically includes the shared host OS/kernel, though confidential-container designs aim to remove the host OS and hypervisor from the TCB. It also includes the runtime configuring namespaces and cgroups. One reachable bug anywhere in that surface is enough. Without a hypervisor bug, the guest kernel can fall entirely while the host stays intact.

For trusted code your platform wrote, reviewed, and deployed, use containers. AI-generated code is neither written nor reviewed by your platform. For that workload, the shared kernel is the risk.

Cold boot time

What counts as a Docker "cold start" depends on measurement scope. Direct runc instrumentation found that container start averaged 259ms and reached 329ms at worst. The measured path excluded image pulls in a 2022 Georgia Tech study.

Full Docker warm starts run higher. With pre-pulled images and warm caches on Azure Premium SSD, Alpine and Python starts reached 568ms and 554ms. Once image pulls enter the picture, everything else is noise. Image pulling accounts for 76% of container startup time in a USENIX FAST study. Image distribution rather than the isolation primitive sets real container start latency.

Firecracker boots to userspace in 125ms or less under its official specification. That figure assumes a minimal kernel with the serial console disabled. Under load, the NSDI 2020 paper measured a 99th-percentile boot of 146ms. In that concurrency test, the system launched 1,000 microVMs, 50 at a time. That result demonstrates tight tail behavior under the tested concurrency pattern.

At the runc level, Docker's start path does less work. That path excludes an image pull, guest kernel, and VMM process. The published numbers also use different measurement boundaries. Runc-only and full Docker warm starts are not directly comparable with a minimal-kernel Firecracker specification.

Measured times depend on image size and snapshotter choice, with cache state adding further variation. Take the narrowest Docker measurement: runc process start with no image pull. The gap against Firecracker's minimal-kernel figure is about 134ms. Firecracker leads a full Docker warm start on SSD by several hundred milliseconds. Either number disappears within an agent session lasting minutes or hours.

Resume from standby

Resume time matters more than cold boot for agents that persist between sessions. Docker has no production-grade resume primitive. docker stop followed by docker start is functionally a cold boot because it relaunches the configured process without preserving RAM contents or CPU registers; open file descriptors also do not survive.

docker pause freezes processes in memory but persists nothing to disk. The docker checkpoint command uses Checkpoint/Restore in Userspace (CRIU). It remains experimental. Docker's reference warns that it "can be removed entirely in a future release."

MicroVMs snapshot at the hypervisor level. Firecracker saves guest memory and device state. It then restores by mapping the memory file copy-on-write. Pages fault in on demand rather than all at once.

Firecracker achieved a three-millisecond restore on aarch64 before console logging was turned on. Turning console logging on raises that to eight and a half milliseconds. Pages keep faulting in after the guest resumes. End-to-end resume therefore runs longer than the VMM-state restoration number.

Guest network connectivity is not guaranteed to survive a resume. A snapshot must also be restored on a host with the same CPU model. The same snapshot-and-restore mechanism powers AWS Lambda SnapStart for initialized functions.

One implementation of this perpetual-sandbox pattern is Blaxel. It holds microVM-isolated sandboxes in warm standby with memory and process state intact. Its published figures put resume from standby below 25ms. Sandboxes can remain in standby indefinitely with zero compute cost.

A PR review agent resuming this way keeps its cloned repository and installed dependencies across invocations. For persistent agents, hypervisor snapshot resume beats any Docker restart path.

Runtime overhead

Containers share the host kernel, so system calls run directly on it. Memory cost tracks the process footprint. Containers lose less to their isolation layer than full virtual machines. That advantage helped them win the trusted-workload market.

MicroVMs pay a small, measurable memory tax. VMM overhead is five MiB or less for a one vCPU, 128 MiB microVM (Firecracker specification). Measured resident memory for a 128 MB guest, including mapped guest pages, reached 50.5 MB in 2026. The memory delta matters when packing many concurrent instances onto fixed hardware.

CPU overhead is close to free. Guest CPU performance exceeds 95% of bare metal, with an average six-hundredths of a millisecond of added network latency (Firecracker specification). Compute-bound agent work runs at container speed.

Disk I/O also holds up. Firecracker delivered 3.6% higher read throughput than runc in a 2023 peer-reviewed comparison. Write throughput ran 21% higher on average in the same peer-reviewed comparison. Block I/O is not the microVM tax teams expect.

Security comparison: what each model protects against

Performance tells you how fast the sandbox starts. Security tells you what happens when the code inside tries to escape. For AI agent workloads, code is written at runtime. The platform cannot predict or audit what it does.

Container escape risk with untrusted code

Container escapes exploit the shared kernel or the runtime configuring it. They keep shipping. CVE-2024-21626 affected runc through version 1.1.11. The mechanism appears in the runc advisory.

The runtime leaked a file descriptor pointing at the host's /sys/fs/cgroup. Setting a container's process.cwd to /proc/self/fd/7/ placed the process inside the host mount namespace. The result was full host filesystem access. The National Vulnerability Database rates it 8.6 HIGH. That host access can expose every colocated workload, not only the compromised container.

CVE-2022-0185 was worse in kind. The NVD entry rates the kernel filesystem integer underflow at eight-point-four HIGH. An unprivileged process could obtain CAP_SYS_ADMIN through unshare. It could then overflow kernel heap to reach host root.

The bug appears in the CISA Known Exploited Vulnerabilities catalog. For AI agents, the risk compounds. The agent writes code at runtime that no human reviewed. A triggered kernel bug reaches every container on the host.

Hardening narrows the window without closing it. Docker's default seccomp profile blocks around 44 syscalls out of more than 300. In testing, 50 of 88 exploits still succeeded from a default-configured container. That result means default filtering reduces exposure but cannot establish a complete boundary for adversarial code.

Mandatory access control profiles key on file paths. An exploit writing through a pipe rather than a path can bypass them. Coverage is mechanism-specific, and each documented escape found a different gap.

Hardened containers are appropriate for trusted code in multi-tenant environments. Profile tuning narrows exposure but leaves workload trust as the deciding factor.

MicroVM isolation and the hypervisor boundary

Each microVM has a dedicated kernel and memory address space behind its own device model. The attack surface is the hypervisor's virtual machine interface. Purpose-built VMMs keep that interface small.

Firecracker emulates six devices total. They are virtio-net, virtio-balloon, virtio-block, virtio-vsock, a serial console, and a minimal keyboard controller. Firecracker's VMM contains roughly 50,000 lines of Rust. QEMU is far larger.

Firecracker is the open-source microVM technology built for this threat model. AWS built and open sourced Firecracker because shared-kernel container boundaries were insufficient for application isolation in AWS customer workloads.

Hypervisor escapes exist. VENOM, CVE-2015-3456 was a buffer overflow in QEMU's floppy disk controller. It let a guest take over the QEMU process on QEMU, Xen, KVM, and VirtualBox hosts.

Exploitation required root or administrative privileges inside the guest. No public arbitrary-code-execution exploit existed at disclosure. CrowdStrike observed no exploitation in the wild. Firecracker does not emulate a floppy controller. That bug class is absent from its device model.

Other cases are narrower or newer. The CVE-2019-18420 entry covers a bug that crashed the Xen hypervisor. It caused denial of service only and received a six-and-a-half MEDIUM rating. This case illustrates that hypervisor vulnerabilities can affect availability without necessarily enabling guest-to-host code execution.

Eight attacks against microVM-based containers degraded victim I/O by 93.4% in a USENIX Security 2023 study. Some attacks also crashed the host. Every isolation model has vulnerabilities. The comparison concerns relative attack-surface size.

A handful of emulated devices sits against the full kernel syscall interface described earlier. For untrusted code execution, the smaller surface is the correct boundary.

How to choose a model by workload trust

Use containers for platform-controlled code, including pre-defined functions and reviewed scripts; first-party services also qualify. Docker's operational strengths are genuine. It integrates with mature CI/CD systems and orchestrators, and its workflows are familiar to many engineers. Short-lived stateless workloads also fit its start-fresh lifecycle.

Sandbox workloads assumed to be malicious, including untrusted code. Kubernetes' own guidance recommends this boundary.

MicroVMs earn their place when agents execute untrusted or AI-generated code at runtime. They also fit multi-tenant isolation requiring a hardware-enforced boundary. Workloads carrying state across sessions gain from snapshot resume.

A VM-based sandbox can protect untrusted workloads in multi-tenant environments, according to the CNCF security whitepaper. Group containers by sensitivity and keep one sensitivity level per host kernel, as NIST SP 800-190 advises.

In practice, first-party services and vetted dependencies belong on one host pool. Runtime-generated agent code belongs on another, with a dedicated kernel per sandbox. The Confidential Computing Consortium takes a stricter position: "Agents must be treated as untrusted entities."

The hybrid path works in practice. Run trusted workloads in containers and untrusted agent code in microVMs. Route between them at the orchestration layer using workload classification.

Tag workloads by code authorship: separate code from your team or a vetted dependency from code generated by a model at runtime. That tag becomes the scheduling signal. Classification happens once at deployment instead of per request. The router then reads a label rather than inspecting the payload. This keeps isolation decisions off the request path and outside the latency budget.

How to choose between microVMs and Docker for AI agent isolation

Choose the isolation architecture according to workload trust rather than headline performance. The measured performance gap points in different directions depending on scope. It should not drive the decision. Containers remain appropriate for trusted, first-party code. Nothing in this comparison changes that. For untrusted, AI-generated code, microVMs enforce a hardware boundary that containers cannot match. Hypervisor-level snapshot resume has substantially reduced the performance penalty that once made this tradeoff painful.

Teams running production agents that execute arbitrary code at runtime need the stronger boundary. Blaxel is a perpetual sandbox platform. Its microVM-isolated sandboxes run coding agents and other runtime-generated workloads on the model described above.

Talk to the team at blaxel.ai/contact or start building at app.blaxel.ai.

FAQ

Are microVMs slower than Docker containers? Benchmark the exact image and lifecycle rather than comparing headline figures. Cloud Hypervisor reports under 100ms to userspace with direct kernel boot. Record image pull, process launch, userspace readiness, and resume separately, then weight each by session frequency and duration. This prevents a fast narrow measurement from masking slower distribution or restoration work.

Can Docker containers be hardened enough for untrusted AI agent code? Treat seccomp profiles, AppArmor, user namespaces, and gVisor as controls to test individually against the workload's reachable behavior. The gVisor documentation states that "container escape is possible with a single vulnerability." Validation should therefore cover the remaining host-facing interface, patch cadence, runtime configuration, and the potential impact on neighboring workloads.

What is a microVM and how is it different from a traditional VM? A microVM is a virtual machine profile optimized by removing unnecessary legacy devices while retaining essential virtio networking, block devices, and a serial console. When evaluating one, inspect the exposed device list, boot path, guest-kernel requirements, and snapshot compatibility. Those details determine whether its reduced hardware model fits the workload better than a general-purpose traditional VM.

When should I use Docker instead of microVMs for AI agents? Use the code-authorship classification as the operational test. A team-authored service or vetted dependency that can start fresh is a Docker candidate. A model-generated or tenant-supplied workload should receive the microVM scheduling tag. Also account for lifecycle: sessions that must retain memory, processes, or open working state need a restoration model rather than a start-fresh container path.