Bare Metal vs Virtualized Hosts for Agent Fleet Density

Firecracker micro-VM isolation for AI agents replaces a shared container kernel with each agent’s own guest kernel and hardware-virtualized boundary. For fleet density, the decisive choice is not bare metal versus virtualization, but virtualization designed for agents. Firecracker on bare-metal hosts combines direct hardware virtualization access with snapshot-restore scheduling, so persistent agents can release compute and consume storage while idle.

Why the bare metal vs. virtualized framing misses the real question for agent fleets

A developer operating an agent fleet must account for agents that wait far more often than they work. Keeping every environment running preserves responsiveness, but reserves capacity during long periods of silence. Removing those environments saves compute, but leaves users who come back expecting their agents to resume with no environment to return to.

The usual bare metal comparison starts with GPU-bound workloads that run all the time and need sustained hardware access to perform well. That comparison matters for training and sustained inference, but it does not settle the economics of persistent agents. An agent fleet needs short bursts, per-tenant isolation, a high idle fraction, and fast wake to coexist. These needs set agent-oriented virtualization apart from general compute virtualization, whether the infrastructure beneath it is called bare metal or cloud.

What bare metal actually contributes to agent infrastructure — and what it does not solve alone

Bare metal provides a direct foundation for virtualization without placing another hypervisor beneath the agent runtime. That distinction matters concretely for Firecracker, whose documentation requires read and write access to /dev/kvm, the Linux kernel’s virtualization interface. On a bare-metal host, Firecracker can use that interface directly. A micro-VM inside a cloud VM instead depends on the outer platform exposing hardware virtualization through nesting. The physical host is therefore not an alternative to Firecracker, but the foundation on which Firecracker runs.

Cloud support makes nested virtualization a configuration question. Azure and GCP have long supported nested virtualization on standard VMs, and AWS added it for standard C8i, M8i, and R8i instances in February 2026. Nesting works, but adds latency to VM operations and, in many configurations, blocks PCIe passthrough, which matters for GPU-accelerated sandbox work. Maritime deploys Firecracker micro-VMs directly on bare-metal hosts, avoiding that extra virtualization layer while giving each agent its own kernel boundary.

With dedicated physical hardware, the host also has no unrelated physical tenants, which matters when agents handle credentials or regulated data. That separation does not, however, isolate the agents sharing the host from one another. Direct hardware access also leaves open how memory is divided and what happens when an agent sleeps.

How agent workload shape breaks the assumptions built into conventional virtualization

Putting a conventional hypervisor on that foundation does not resolve the mismatch. Conventional cloud VMs reserve and bill for an execution environment while it runs, whether or not its application is doing useful work. That arrangement fits workloads that remain active. An agent, by contrast, repeatedly stops to wait for something outside its own execution environment. Faster hardware does not shorten a wait for human input.

Even during an active session, the agent has to wait for model responses and tool latency. Between sessions, a user-facing agent may receive only a handful of interactions a day, separated by hours or days of silence. Its environment is long-lived, but its demand for compute is intermittent. Infrastructure, orchestration, tooling, and governance consequently remain first-class costs rather than incidental expenses beside model inference. The execution environment has to be evaluated over its waiting time as well as its working time.

A conventional VM keeps its compute allocation through both periods. Scaling to zero removes idle compute cost, but trades that saving for a cold start that a user can notice. Sizing every running VM for peak memory demand also makes the host carry allocations that idle agents do not use. Keeping a VM continuously allocated treats persistence and execution as though they were the same requirement.

How Firecracker micro-VMs give AI agents their own isolated kernels

Firecracker separates a strong isolation boundary from the overhead of a conventional VM. Each Firecracker micro-VM has its own guest kernel and a minimal device model, with sub-second boot. These features suit agents that run untrusted code, change their environments, and need to start quickly. The hardware-virtualized boundary separates an agent’s guest kernel from the host kernel. This is the concrete answer for developers who need each AI agent to have its own isolated kernel without relying on containers.

Standard containers share the host kernel, so a container escape can put the infrastructure beneath the agent at risk. With Firecracker, tenants have their own kernels, though a VM boundary can still have vulnerabilities. Within that boundary, an agent can install packages, modify its environment, and break its own workspace without making those changes in a neighbor’s kernel. Firecracker’s minimal device model also reduces the attack surface exposed to guest code, which matters when the code comes from an LLM.

The runtime’s memory behavior supports density as well as isolation. Firecracker backs used memory pages as they are needed instead of backing the full declared allocation at once, and a bare-metal host with enough capacity can create many micro-VMs per second. This favors agents with large memory ceilings but smaller working sets. The fit is nevertheless workload-specific. gVisor suits short, container-shaped tool calls at high density, while Firecracker suits long, complex, untrusted sessions that pay the boot cost once and stay warm across many steps.

How snapshot-restore scheduling changes the density economics of idle-heavy fleets

Small VM overhead helps, but snapshot-restore cuts the larger cost of keeping idle agents in memory. When an agent can pause, the harness snapshots its execution state to durable storage, including memory, the call stack, and pending continuations. The running process then terminates and releases its compute allocation. On wake, restoration resumes the saved environment. Snapshot-restore scheduling can restore an agent in under a second while retaining its context.

The economic change is from idle memory to idle storage, which is orders of magnitude cheaper than compute. Copy-on-write storage reduces the amount that each snapshot adds. Only dirty chunks are hashed and uploaded, while untouched offsets refer to shared base chunks. A session that changes a small portion of a large disk therefore need not store a new copy of the whole disk.

Freeing idle memory through snapshotting can more than triple the fleet a host supports, although the result depends on workload shape. The supported population can exceed the number of agents able to perform peak work simultaneously. At standard storage rates, a small dormant snapshot can cost a fraction of a cent per agent per month. Compared with always-on execution, savings can exceed ninety percent when the idle fraction and suspension strategy support them. Those storage economics are distinct from a managed platform’s full per-agent price.

For infrastructure such as Maritime, the snapshot-restore scheduler operationalizes this distinction between persistence and execution. An idle agent is kept as a stored environment, so it is available without being billed as compute the whole time. This makes it affordable to give each user a dedicated agent even when they go a long time between interactions.

What dense multi-tenant agent fleets require from the host architecture beyond raw performance

Production density requires trust boundaries, controlled memory overcommit, fast burst provisioning, and host automation. The trust boundary exists because one user’s generated code must not become another user’s infrastructure problem. Firecracker supplies a guest kernel and hardware-virtualized boundary for each agent, tenant, or tool group. Bare metal alone cannot keep workloads on the same server apart in that way. Conventional VMs can provide VM boundaries, but isolation alone does not address the fleet’s idle-state economics.

Memory overcommit must be based on actual working sets and allow for agents to need their full declared allocations. Firecracker’s used-page allocation and snapshot-restore make that packing practical by avoiding unused backing memory and removing suspended workloads from active memory. Memory hotplugging, where supported by the host architecture, lets an agent begin with a smaller allocation and expand when a task needs it. A dense host still has to accommodate the agents that are genuinely active.

Burst provisioning matters because many agents can wake together, even when average activity is low. Firecracker’s rapid creation and restoration address that demand at the runtime layer. The host layer must also be programmable, or the economics disappear into manual work. Teams still need bare metal automation that handles firmware updates across hardware from different vendors, network fabric configuration, and lifecycle management. Self-service APIs, Infrastructure as Code, and automated replacement on node failure are therefore requirements for operating the architecture.

Where the architecture breaks down and what honest trade-offs developers should plan for

The break-even point depends on aggregate utilization, fleet size, and operational burden. A continuously busy workload that saturates its allocated capacity can benefit from a flat monthly hardware rate. An idle-heavy agent fleet reaches useful host utilization differently, by sharing capacity among many agents whose work is intermittent. The economics depend on enough aggregate activity to justify the hosts without reserving peak resources for every tenant. A handful of sandboxes used now and then is too little work to make a dedicated bare metal fleet pay off.

Below that threshold, managed cloud or simpler infrastructure often wins on total cost. Above it, teams that buy hardware still have to do the work described earlier to run it. Teams need tooling that closes the gap between hardware arriving and hardware producing useful capacity. Otherwise, manual provisioning, configuration, and replacement can consume the savings that motivated the move.

Firecracker also earns its overhead only where its isolation and lifecycle properties match the task. A research agent that installs packages, changes its environment, and writes artifacts over a long session has a strong reason to retain a VM boundary across many steps. Short, container-shaped tool calls may fit gVisor better, while controlled workloads may be able to share a kernel across runs. The deciding criteria are trust, session length, persistence, idle fraction, and scale. A fleet that is large enough, idle enough, and multi-tenant enough is precisely where Firecracker on bare metal pays off substantially.

What this architecture looks like in practice: from a single agent to a per-user fleet on Maritime

Maritime brings these layers together as a managed stack rather than requiring a developer to assemble the host, runtime, and scheduler separately. A developer can push code or make one SDK call to provision an isolated micro-VM and receive a live API endpoint. Its CLI workflow uses maritime create … && maritime deploy, which is a two-step command sequence. The deployment path is short because the underlying Firecracker, bare metal, sleep and wake behavior, and billing are managed.

Each agent receives a persistent disk and a real kernel, with package installation privileges and browser session support. That gives the agent a workspace it can change without changing a neighboring agent’s environment. Wake from sleep takes about a second, connecting the saved workspace to a responsive user experience. The monthly price is for persistent machines and does not assume that every agent runs all the time. Maritime’s tiered plans work out to approximately one dollar per agent per month, with the Starter plan priced at $20 per month, rather than deriving that price from an assumed idle fraction.

The resulting product model is one agent per user, each with its own credentials, memory, installed tools, and in-progress work. Those resources survive across sessions as a workspace rather than being reconstructed for every interaction. As the product gains users, the infrastructure must support many persistent environments without treating them all as active compute. Firecracker isolation and snapshot-restore scheduling make those requirements compatible.