Self-Hosting an AI Agent Code Execution Sandbox on Bare Metal

If your product lets an AI agent write and run its own code, you have a problem most teams haven’t had to think about before: how do you run code you didn’t write and don’t trust, fast, repeatedly, and without one bad execution taking down your infrastructure?

That’s the sandbox problem, and it’s become one of the fastest-growing infrastructure categories nobody outside of it is talking about yet.

Why Agent Sandboxes Became a Real Infrastructure Category

Standard containers share the host kernel. That’s fine when you control what runs inside them. It’s a real problem when an LLM is generating the code that runs inside them, because a container escape becomes a path to your actual infrastructure, not just a demo environment.

The market response has converged on microVMs, primarily AWS’s open-source Firecracker and Kata Containers, as the isolation layer of choice. A microVM gets its own kernel and its own hardware-virtualized boundary, closing the container-escape risk that standard Docker or containerd can’t.

We’ve covered the general mechanics of microVMs, their sub-second boot times, and why they favor horizontal scaling in depth elsewhere; see MicroVMs: Scaling Out Over Scaling Up for the full technical background. What’s specific to agents is the workload shape sitting on top of that isolation layer: code the system itself didn’t write, running unsupervised, at a volume and unpredictability that serverless functions and API workloads were never designed around.

The workloads driving this fall into three related but distinct categories: code-execution sandboxes that run agent-generated scripts, browser-agent fleets that run headless Chrome sessions for computer-use agents, and persistent agent memory that needs to survive across sessions rather than disappearing when a sandbox spins down. Each has real infrastructure requirements that don’t map cleanly onto how most teams already run compute.

Why This Needs Bare Metal, Not a Public Cloud VM

Firecracker’s own documentation is direct about this: it requires read and write access to /dev/kvm, the Linux kernel’s virtualization interface. On public cloud, that access typically only exists on bare-metal instance types, not standard virtual machines, because a standard VM is already running on top of someone else’s hypervisor. Nesting a microVM inside a virtual machine means nested virtualization, which works, but comes with real costs: added latency at every VM operation, weaker isolation guarantees than a direct hardware boundary, and in many configurations, no path to PCIe passthrough at all.

That last point matters more than it sounds like. Agent sandboxes doing GPU-accelerated work, code interpretation with local model inference, rendering, or any workload that benefits from binding a physical GPU straight into the microVM, need PCIe passthrough to do it. Nested virtualization on a shared cloud VM frequently blocks this outright. OpenMetal’s GPU servers, including the RTX PRO 6000 and H200 lines, are dedicated hardware for exactly this reason, and our sizing guides can help match a model to the right card if your sandbox needs to run local inference alongside code execution.

Dedicated bare metal sidesteps the whole problem. There’s no host-level hypervisor in the way. You get direct /dev/kvm access and the ability to bind PCIe devices, including GPUs, straight into your Firecracker or Kata microVMs, because you’re not sharing the physical machine with anyone else’s workload in the first place.

The Cost Math Changes Once You’re Running at Scale

It’s worth being precise about which cost this section is about, because agent workloads actually carry two separate bills that get conflated. One is the cost of running the model itself, billed by the token if you’re calling a hosted API. We’ve broken down that side of the economics separately, including where the crossover to dedicated GPU inference lands for coding agents specifically; see Per-Token vs. Dedicated GPU for Coding Agents.

This section is about the other bill: the cost of the sandboxed execution environment itself, the compute that runs the code an agent decides to execute, separate from whatever produced that code in the first place.

Managed sandbox platforms like E2B bill per-second per vCPU for that execution environment, commonly cited around $0.05 per vCPU-hour, with paid tiers layering a monthly floor on top. That model makes sense for a team running a handful of sandboxes occasionally. It stops making sense once agent usage becomes a meaningful, ongoing part of your product, because agent workloads are inherently bursty and unbounded. There’s no natural ceiling on how much code an agent might decide to run, and metered billing means every burst shows up as a bigger bill, not just more usage.

Third-party cost analyses comparing self-hosted Firecracker against managed platforms put the break-even point at roughly a couple thousand sandbox-hours per month, with self-hosted setups landing meaningfully below equivalent managed spend above that volume. The specific numbers vary by workload and shift as pricing changes on both sides, so treat any exact figure as directional rather than a quote you can rely on.

What doesn’t change is the shape of the comparison, and it’s the same shape our coding-agent cost breakdown found on the inference side: a workload that runs continuously and saturates its allocated capacity is exactly the profile where a flat monthly rate beats a linear meter, whether the meter is counting tokens or vCPU-seconds.

There’s also an architectural point worth making plainly: the sandbox layer itself is largely open source. Firecracker is open source, and platforms like E2B’s underlying infrastructure are built on open components that are self-hostable if you’re willing to run them yourself. That’s a real option, not a workaround, for teams with the engineering capacity to operate it.

What Self-Hosting Actually Looks Like

A self-hosted agent sandbox stack on bare metal generally has three layers. The isolation layer is Firecracker or Kata Containers running microVMs directly on the host, using KVM for hardware virtualization. The orchestration layer manages sandbox lifecycle, spinning microVMs up and down, routing agent requests to available capacity, and enforcing whatever resource limits your product needs per session. The state layer handles anything that needs to persist past a single sandbox’s lifetime, which is where most managed platforms are weakest, since ephemeral-by-default is the easy default to build and persistent memory is the harder problem.

For that state layer, Ceph fits naturally. Object storage handles artifacts and file outputs an agent produces, block storage backs persistent volumes for state that needs to survive a sandbox restart, and the combination scales the way agent memory needs to scale, which is unpredictably and without a clean upper bound you can plan around in advance. Pairing that with fast local NVMe for the hot path (checkpoint and restore operations on the microVM state itself) keeps latency low on the operations that actually need it.

None of this is exotic. It’s the same building blocks that already run Kubernetes, CI/CD, and other cluster workloads on bare metal. The difference is architectural intent: designing for untrusted, agent-generated code from the start rather than retrofitting isolation onto infrastructure that assumed trusted workloads. For the fuller build, including the orchestration layer, event-queue design, and auto-scaling approach that a self-hosted microVM platform needs end to end, see From Serverless to Private Cloud, which walks through the same architecture for general serverless workloads. The core build is nearly identical; what changes for agents is treating every execution as untrusted by default.

Where Browser-Agent Fleets Fit

Computer-use agents that operate a browser directly add a related but separate demand: running large numbers of real headless-Chrome sessions concurrently. This is explicitly a fleet-management problem rather than a single-browser problem, since a production computer-use product might need hundreds or thousands of concurrent sessions, each isolated from the others.

The same bare-metal advantages apply. Direct hardware access avoids the overhead of running headless Chrome inside nested virtualization, and dedicated capacity avoids the noisy-neighbor variability that comes with shared cloud instances at the density this workload requires.

What This Doesn’t Solve

Self-hosting a sandbox stack is an infrastructure decision, not a finished product. You’re taking on the orchestration layer, the scaling logic, and the operational responsibility that a managed platform otherwise absorbs. That’s a real tradeoff, and it’s the right one specifically once your usage volume, GPU requirements, or persistence needs outgrow what a metered managed service handles well. Teams running occasional or low-volume agent workloads may still be better served by a managed platform, at least until their usage profile changes.

Getting Started

Dedicated bare metal servers give you the direct KVM access and PCIe passthrough that Firecracker and Kata require, without a hypervisor layer in the way. Current configurations are on our bare metal pricing page, and workloads that need persistent agent state alongside compute can pair bare metal with a Ceph storage cluster for object and block storage that scales with usage rather than against a fixed cap.

FAQ

Why can’t agent sandboxes just run in standard containers?

Standard containers share the host kernel with other workloads on the same machine. When the code running inside a container is generated by an LLM and not reviewed by a person, a container escape becomes a path to the underlying infrastructure. MicroVMs like Firecracker give each sandbox its own kernel and a hardware-virtualized boundary, closing that gap.

Does Firecracker work on a public cloud virtual machine?

Generally not directly. Firecracker requires read and write access to /dev/kvm, which is typically only exposed on bare-metal instance types rather than standard VMs, since a standard VM already runs on top of another hypervisor. Running it anyway means nested virtualization, which adds latency, weakens isolation, and often blocks PCIe passthrough.

When does self-hosting an agent sandbox make sense instead of using a managed platform?

Third-party cost comparisons generally put the crossover around a couple thousand sandbox-hours of usage per month, though the exact number depends on your specific workload and both platforms’ current pricing. Below that volume, a managed platform’s per-second billing is often simpler. Above it, fixed infrastructure costs typically come out ahead.

What’s the hardest part of self-hosting an agent sandbox stack?

Persistent state. Spinning up ephemeral, isolated microVMs is the well-solved part of the problem. Making agent memory and state survive across sessions, at a scale that doesn’t have a predictable upper bound, is where most of the real engineering work is.