Agents now write files and run commands faster than any review process can keep up with, making the isolation boundary a design decision rather than an ops detail. Containers partition host processes using Linux primitives and share a single kernel, whereas microVMs provide each workload with its own guest kernel via hardware virtualization.
This guide covers where each boundary sits, what each costs to operate, and how to choose.
Key takeaways:
Containers share the host kernel, while microVMs give each workload its own; all other differences in startup, density, and blast radius follow from that split.
Code provenance determines which boundary applies: reviewed first-party code runs well in hardened containers, whereas agent-generated or tenant-supplied code requires a per-workload kernel.
Startup comparisons usually measure different layers, since a warm container skips the guest boot entirely, whereas a microVM either boots a kernel or restores a snapshot.
Docker Sandboxes give every agent session a dedicated microVM because building containers inside a container requires privileges that undo the isolation the setup provides.
A managed sandbox is an operating model rather than an isolation boundary, since these services run on a container or a microVM underneath and the choice varies by vendor.
Copy link to headingWhat are the key differences between microVMs and containers?
The clearest split is where a hostile workload gets stopped. A container's boundary is enforced by the same kernel that serves the host, while a microVM's first boundary is enforced by the CPU, so the guest kernel absorbs the workload before the host kernel is reachable.
Here is how the split plays out across the dimensions that change an architecture decision:
Every row traces back to the kernel question, and five change a design decision rather than a spec sheet.
Copy link to headingWhere the security boundary lives
Containers draw their boundary in software. Namespaces partition what a process can see, cgroups cap what it consumes, capabilities split privileged operations into smaller units, and seccomp-bpf filters the syscalls it can issue.
MicroVMs draw the first boundary in hardware. The Firecracker design paper describes moving the security-critical interface from the OS boundary to one supported by hardware and comparatively simpler software, thereby keeping the VMM inside the trust base. At the same time, the guest kernel first absorbs the workload.
Copy link to headingOne shared kernel against one kernel per workload
Every container executes against the same kernel instance as the host and as every other container on that machine. Namespaces change what a process sees, and they do not create a second kernel.
Each microVM boots its own guest kernel, which gives platform teams a per-workload boundary and lets them strip the guest OS down to what the workload needs. Firecracker deliberately keeps its virtual device model narrow, so the host-facing surface remains smaller than that of a general-purpose virtual machine stack.
Copy link to headingStartup time depends on which layer you measure
A warm container path skips a guest kernel boot when the image is present, and a fresh microVM launch includes both the VMM and the guest boot path. Benchmarks that fold in scheduling, image pulls, and orchestration measure the platform rather than the runtime, which is why published comparisons disagree.
Snapshot restore changes the arithmetic by resuming a pre-initialized memory image instead of booting. The honest comparison is a warm container against a restored microVM, measured from request to runnable environment.
Copy link to headingMemory overhead and density
Containers keep the per-instance footprint low because kernel memory is shared, so reviewed services pack densely while operational patterns stay aligned with Docker and Kubernetes.
MicroVMs add a VMM process and configured guest RAM for every instance. The number worth comparing is how many isolated executions a host sustains at the trust boundary the product requires, rather than how many processes it holds.
Copy link to headingBlast radius when the workload is hostile
A container boundary works best when the code is already trusted, and the platform applies a hardened runtime profile. A permitted syscall that exercises a kernel bug reaches a kernel shared with the host and every neighbor.
A microVM places a guest OS and CPU-enforced privilege separation in front of the host kernel, and the VMM exposes a smaller device surface than a full machine model does. That structure suits multi-tenant code execution and agent workloads whose behavior cannot be known in advance.
Each model now deserves a closer look on its own terms.
Copy link to headingExploring microVMs for engineering teams
A microVM is a virtual machine stripped down to what a single workload needs, running its own guest kernel behind hardware virtualization with a device model small enough to audit. It keeps the isolation properties of a virtual machine while shedding the boot time and memory footprint that make general-purpose VMs impractical for ephemeral work.
Firecracker is the reference implementation throughout this comparison, an open-source VMM written in Rust and built on Linux KVM (Kernel-based Virtual Machine). This module turns Linux into a hypervisor.
AWS Lambda has run on Firecracker since 2018, serving trillions of events per month at the time of the paper, which makes it the largest documented deployment of the model.
Copy link to headingKey components that make microVMs work
A microVM stack is smaller than a general-purpose hypervisor because it removes devices and machine features that server workloads never touch. Four pieces carry the isolation:
Minimal device model: Firecracker exposes only the block, network, and control paths its target workloads need, keeping the host-facing surface narrow.
Purpose-built VMM: One monitor process runs per microVM, so the relationship between workload, monitor, and boundary stays direct and auditable.
Dedicated guest kernel: Each instance boots its own kernel, limited to the drivers and subsystems the workload requires.
Host-side jailer: The VMM process runs under cgroups, namespaces, a minimal chroot, dropped privileges, and per-thread seccomp filters.
Those layers compound rather than substitute for each other. Where a typical Ubuntu 15.04 installation needed 224 syscalls and 52 unique ioctl calls, Firecracker's jailer profile permits 24 syscalls and 30 ioctl calls, 22 of which are required by the KVM API.
Copy link to headingAdvantages and limitations of microVMs
For code that arrived from outside the team, microVMs provide security reviewers with a boundary they can describe without relying on syscall filtering.
The advantages concentrate on workloads whose behavior cannot be predicted:
Per-workload kernel: A guest kernel per execution means the boundary no longer rests solely on the host kernel's process isolation.
Auditable containment story: Hardware virtualization, a minimal VMM, and jailer controls map to mechanisms security reviewers already recognize.
Tenant fault isolation: A kernel panic or runaway resource spike stays inside that guest instead of becoming a shared-host incident.
Serverless-shaped footprint: Firecracker targets ephemeral workloads rather than general-purpose virtualization, so the boundary arrives without a full hypervisor stack.
Operating that boundary is a platform project, and the costs fall on the team running it rather than on the workload.
The limitations are mostly operational:
Virtualization expertise required: KVM hosts, guest kernel images, network setup, and snapshot management need an on-call owner.
Observability across a VM boundary: Debugging inside a microVM differs from attaching to a container, and container-native tracing often needs adaptation.
Per-instance memory floor: Configured guest RAM is allocated per execution, which caps density against processes sharing a kernel.
Narrower workload fit: Firecracker stacks are Linux-guest environments, and accelerator-heavy workloads can call for a different approach.
Snapshot restore is the feature most often cited to close the startup gap, and it comes with a caveat worth noting.
Copy link to headingWhat snapshot restore does and does not give you
Snapshots allow a platform to skip repeated boot and dependency work by restoring the initialized state. Restores require an identical host configuration, and vsock connections reset when a microVM resumes.
Firecracker's snapshot documentation states that resuming the same snapshot state more than once is insecure, because identifiers, entropy, and credentials get reused across those clones, and diff snapshots remain in developer preview. A snapshot is a warm-start optimization for a single resume, rather than a template to be fanned out across tenants.
Copy link to headingWhen to use microVMs
MicroVMs earn their overhead when the trust boundary matters more than the last increment of per-instance density.
Copy link to headingThe code came from outside your team
AI-generated code, user submissions, and external CI scripts sit outside the review that makes first-party code trustworthy. A dedicated kernel per workload means the boundary holds when the code does something nobody anticipated.
Copy link to headingOne tenant must never affect another
Multi-tenant platforms need a boundary their engineers and tenants can both reason about. With a microVM per tenant, a kernel panic or resource spike stays inside that guest environment.
Copy link to headingThe isolation model has to survive an audit
Regulated environments need an isolation story that maps to mechanisms auditors recognize. Hardware virtualization, a minimal VMM, a dedicated guest kernel, and jailer controls form a clear chain of responsibility.
Copy link to headingExploring containers for engineering teams
A container is a group of host processes that the Linux kernel partitions with namespaces and constrains with cgroups. Nothing boots inside a container, because a container is not a separate machine, and every process inside it calls into the same kernel the host runs.
The OCI runtime and image specifications made the model portable in 2017, and Docker, containerd, and other OCI-compatible runtimes assembled those kernel features into the workflow most teams already run. That ubiquity is why containers remain the default rather than a deliberate choice for most services.
Copy link to headingKey components that make containers work
Container isolation is built from Linux primitives rather than provided by a single mechanism. Four pieces do the work:
Namespaces: clone(2) and unshare(2) create separate views of process IDs, mounts, IPC, hostname, users, and networking.
Cgroups: Hierarchical groups that cap and monitor CPU, memory, and I/O consumption via
/sys/fs/cgroup.The shared kernel: Every permitted syscall executes kernel code shared with the host, which keeps overhead low and defines the boundary's limit.
Image and runtime: The OCI specifications package the filesystem and process configuration into a repeatable unit.
None of those creates a second kernel. That single fact is the source of container efficiency and the reason code provenance decides so much.
Copy link to headingAdvantages and limitations of containers
For code a team wrote, reviewed, and ships through a controlled pipeline, the shared kernel is an asset rather than a compromise.
The advantages are concrete:
No boot step: Containers start without a guest kernel boot, which suits interactive latency budgets.
Shared kernel memory: Per-instance overhead stays low, so a host packs many workloads at once.
Existing toolchain: Registries, build pipelines, logging, and orchestration already speak this model.
Runtime selection per pod: Kubernetes RuntimeClass, stable since v1.20, lets one cluster schedule hardened and virtualized handlers side by side.
The trade-off arises when behavior cannot be reviewed in advance and focuses on a single surface rather than several.
The limitations follow from the shared kernel:
A shared escape surface: A permitted syscall that reaches a kernel bug executes code shared with the host and every neighbor. Hence, a single kernel vulnerability is a multi-tenant vulnerability.
Hardening reduces without relocating: seccomp-bpf, AppArmor, and dropping capabilities such as
CAP_SYS_ADMINshrink the reachable surface, and the kernel still belongs to the host.Privileged workloads undo the boundary: Container-in-container builds need elevated privileges, which removes much of the isolation the setup provided.
Security depends on two things at once: the boundary holds only when both configuration and kernel correctness hold.
Those limits are acceptable for reviewed code and decisive for code nobody has read.
Copy link to headingWhen to use containers
Containers remain the right default when the workload and the platform share a single trust model, because a dedicated kernel would add operational overhead without changing the risk that matters.
Copy link to headingThe code is first-party and reviewed
When a team writes the code, reviews it, and controls its dependencies, the shared kernel keeps the platform efficient, and hardened runtime profiles cover the residual risk.
Copy link to headingLatency budgets rule out any boot step
Interactive budgets favor a warm container path, since there is no guest boot to absorb. The measurement that settles it covers scheduling, filesystem setup, and dependency loading.
Copy link to headingYour platform is already built on Kubernetes tooling
Delivery pipelines built on OCI registries, CRI integration, and container-native observability keep that model unchanged. Running Firecracker underneath means adopting a layer, such as Kata Containers, and owning it in production.
Copy link to headingWhere managed sandboxes sit relative to microVMs and containers
Managed sandboxes sit one layer above both models rather than beside them. They are not a third isolation mechanism; what they sell is the operating layer, including an API to create and destroy environments, snapshot and restore, an egress policy, credential injection, and metering. The boundary itself still comes from a container or a microVM underneath, chosen by the vendor rather than the team using it.
Which one to choose varies by vendor and sometimes by configuration. E2B runs each sandbox in a Firecracker microVM; Modal virtualizes with gVisor by default. It has a hardware-virtualized VM runtime in beta, and Daytona offers a namespace-isolated container class alongside a VM class with its own kernel.
Modal and Daytona each expose two boundaries behind a single unchanged API, which is the clearest evidence that the layers are orthogonal, so the question to ask a vendor is which primitive lies underneath. Vercel publishes breakdowns covering Sandbox and E2B, and Sandbox and CodeSandbox; the boundary question resolves separately from the operating one.
Copy link to headingHow to choose between microVMs and containers, and who operates them
Four conditions settle which boundary you need, and a fifth settles who runs it. The first outweighs the rest.
Copy link to headingDecide whether the code is hostile or merely untested
Code produced by a language model varies across prompts as the repository state changes, so review cannot establish a trust level that holds for the next run. Externally supplied code belongs behind a per-workload kernel until the platform deliberately narrows that trust level.
First-party code moving through review and a controlled pipeline sits on the other side of that line, where hardened containers are the efficient answer.
Copy link to headingMeasure the startup latency your workload tolerates
Interactive products cannot impose a long initialization path on every request, and a warm container avoids guest-boot work entirely. Application-kernel runtimes such as gVisor offer a middle boundary for teams wanting more separation than namespaces without a full guest VM.
MicroVMs still fit when the platform runs pre-warmed pools or single-use snapshot restores, and the metric to compare is the time from request to a runnable environment.
Copy link to headingModel density and cost per execution at your volume
Below a certain execution volume, owning a virtualization platform costs more in engineering time than it returns in unit economics. That threshold arrives later than most roadmaps assume because guest images, network policy, and cleanup controllers need an on-call owner.
Once execution volume keeps dedicated hosts busy, the arithmetic shifts. Model both paths against host capacity, staffing, security review, and the product work that would not get built.
Copy link to headingChoose whether to operate the isolation layer at all
A self-hosted microVM platform needs operators who understand virtualization, kernel images, guest networking, and observability across a VM boundary. Kata Containers and similar integrations lower the entry cost for Kubernetes teams while leaving the runtime surface in the team's ownership.
A managed sandbox removes that surface from the team's scope while keeping the boundary intact, which is the trade most product teams should take before their first agent ships.
Copy link to headingWeigh the precedent from the container ecosystem
Docker reached this decision publicly. Docker Sandboxes, launched in April 2026, runs each agent session inside a dedicated microVM with a private Docker daemon behind the VM boundary.
The stated reason is the one this comparison keeps arriving at. Coding agents routinely build and run their own containers, and doing that inside a container requires elevated privileges that undermine the isolation. Docker also wrote its own VMM rather than adopting Firecracker, because agents run on developer laptops and Firecracker targets Linux and KVM.
Copy link to headingHow Vercel supports microVM and container workloads for agent teams
Both boundaries are first-class on Vercel, split along the line this comparison keeps arriving at. Reviewed code ships as a container image and runs on Vercel Functions. In contrast, agent-generated code runs in a Firecracker microVM through Vercel Sandbox, where Docker still runs inside the guest under sudo.
Copy link to headingShipping reviewed code as a container image on Vercel Functions
Teams with an existing image rarely want to repackage an application to run on a platform. A Dockerfile.vercel at the project root is detected during deployment, built, pushed to the Vercel Container Registry, and served by Vercel Functions with autoscaling and Active CPU billing.
That keeps the container boundary around the code the team wrote and reviewed. A services block routes traffic across several containerized frontends and backends within a single project, so the shared-kernel model carries the trusted half of the stack.
Copy link to headingProvisioning isolated microVMs with the Sandbox SDK
Teams reach the execution question as soon as an agent can write files and run commands, usually before there is sufficient capacity to build guest images, provide access to virtualization, and perform cleanup.
Provisioning is one call from the JavaScript or Python SDK:
import { Sandbox } from '@vercel/sandbox';
const sandbox = await Sandbox.create();That returns a running Firecracker microVM on Amazon Linux 2023 in milliseconds, with Node.js or Python available and root access inside, currently in the iad1 region. The guest kernel, VMM, and cleanup stay with the service, and the guide to building AI agents covers wiring execution into the loop.
Copy link to headingControlling per-execution cost with Active CPU billing
At agent volumes, a tool call can need its own runnable environment, so the cost model shapes how freely a product executes code. Active CPU billing excludes time waiting on network requests, database queries, and model calls, which is most of what an agent loop does.
The published example for validating AI-generated code, five minutes on 2 vCPUs, comes to roughly $0.03, and creations run $0.60 per million. Model the workload against Sandbox pricing rather than carrying over container-hosting assumptions, where an idle process bills the same as a busy one.
Copy link to headingPreserving task state with persistent sandboxes
Coding agents rarely finish within a single request. Cloning a repository, installing dependencies, running tests, and asking the model for another step all need state that survives the turn.
Persistent sandboxes save state on stop and resume, resuming where the task left off, and persistence is the default rather than a snapshot workflow that the team assembles. The sandbox becomes part of the agent's task state rather than a disposable process per prompt.
Copy link to headingCapping runaway executions with timeouts and resource limits
Agent code consumes CPU, memory, and wall-clock time while it explores a task, making resource limits a product control as much as an infrastructure control. The default timeout is 5 minutes and can be extended in code, with a maximum of 45 minutes on Hobby and 24 hours on Pro.
Sandboxes get 2 vCPUs by default and scale to 8 on Pro or 32 on Enterprise, with 2 GB of memory per vCPU and 32 GB of ephemeral NVMe storage. Pairing those ceilings with agent observability turns a runaway loop into an alert rather than an invoice.
Copy link to headingSet the isolation boundary before agents ship to production
The isolation decision becomes harder to reverse once agent-written code is running in production, because the boundary must change while a live workload is running. Containers remain the efficient default for reviewed first-party services, and microVMs fit workloads needing a per-execution kernel boundary that holds up under audit.
Teams with the capacity to own KVM, guest images, networking, and snapshots can operate Firecracker directly. For teams that want the same boundary without that project, Vercel covers the execution layer:
Vercel Sandbox: A Firecracker microVM per workload, with its own filesystem and network.
Persistent sandboxes: State is saved on stop and resumed on the next turn by default, so multi-step agent tasks keep their filesystem.
Active CPU billing: Charges track active execution and exclude the model and network waits that dominate an agent loop.
Configurable ceilings: Timeouts, vCPU and memory limits, and concurrency caps that bound what a looping agent can consume.
Managed lifecycle: Guest kernels, the VMM, and cleanup belong to the platform rather than to an on-call rotation.
Give the boundary a real agent task to run at vercel.com/new.
Copy link to headingFrequently asked questions about microVM vs container
Copy link to headingIs a microVM a container or a virtual machine?
A microVM is a virtual machine. Firecracker uses Linux KVM to run a dedicated guest kernel with a smaller device model than a general-purpose VM. Unlike a container, a microVM does not share the host kernel with the workload it runs.
Copy link to headingDoes Docker use microVMs?
Docker Sandboxes do. Each agent session runs in a dedicated microVM with a private Docker daemon behind the VM boundary, because building containers inside a container requires privileges that weaken the isolation. Docker built its own VMM for cross-platform support rather than using Firecracker.
Copy link to headingWhat is Firecracker?
Firecracker is an open source virtual machine monitor written in Rust that uses Linux KVM to run microVMs. AWS developed it for services like Lambda and Fargate, and it exposes a minimal device model with only the block, network, and control paths serverless workloads need.
Copy link to headingAre microVMs slower to start than containers?
On a fresh boot, yes, because a microVM has a guest kernel boot path and a container does not. Snapshot restore closes part of that gap for a single resume. The comparison that matters covers the full path a team will operate, including scheduling and cleanup.
Copy link to headingDo you need a microVM to run AI-generated code safely?
Reviewed first-party code runs well in hardened containers with seccomp, AppArmor, read-only filesystems, and dropped capabilities. Code from agents or tenants fits better in a microVM or a managed sandbox because the boundary then holds without depending on the shared host kernel.