Firecracker Is the Easy 5%: What Self-Hosting an E2B-Style Agent Sandbox Really Operates

Firecracker boots a stripped Linux guest in about 125 milliseconds with under 5 MiB of memory overhead per microVM. Read that number once and a tempting conclusion follows: agent sandboxes are a solved problem, just stand up Firecracker and hand each AI agent its own microVM.

E2B proves the opposite. The company behind the best-known agent sandbox platform runs Firecracker too, and its enterprise pitch is refreshingly honest: the code is open, but at scale you operate E2B's own control plane yourself. The microVM is the easy 5%. This post inventories the other 95% — the eight control-plane pieces E2B's hosted product abstracts away — puts hosted-vs-self-hosted dollars against a typical agent workload, and ends with what a self-hosted PaaS needs before it can offer sandboxes as a tenant-facing feature. The short version is the table below; the rest of the post substantiates every row.

What E2B actually sells, and what "open source" actually covers​

E2B sells isolated Linux sandboxes for AI agents that execute untrusted code: a full VM with its own kernel per sandbox, started on demand, pausable and resumable across agent turns. The public pricing and docs reduce to the numbers that matter, summarized below.

Metered rates are public and worth memorizing because every build-vs-buy comparison below reuses them: about 5.04 cents per vCPU-hour and about 1.62 cents per GiB-hour. At the default sandbox size of 2 vCPU and 512 MiB of RAM, that multiplies out to roughly 10.9 cents per sandbox-hour — which is why the 100-dollar credit works out to around 920 sandbox-hours of default compute. Pause is first-class: pausing captures filesystem plus memory plus processes, resume lands in about a second, and billing stops while paused.

The open-source boundary is narrower than the marketing implies, and this is the box the title promised. The SDKs are Apache-2.0. The infrastructure repository containing the backend — control-plane REST API, data-plane VM orchestration on Firecracker, the in-VM agent, edge routing, and template building — is public and clonable.

What stays on E2B's side in the hosted model is operations: the warm pool, the snapshot store, the network fabric, and the abuse and billing enforcement. Bring-Your-Own-Cloud and on-premises flip that boundary: only anonymized system metrics flow back to E2B Cloud over TLS, while the orchestrator, edge controller, monitoring, and storage components run in your account — operated by you. Self-hosting here never meant downloading a binary. It means adopting somebody else's distributed system and staffing it.

Firecracker ends where the control plane begins​

Firecracker's design document is explicit about scope, and that scope is deliberately small. You get a Rust virtual-machine monitor with a minimal device model, no emulated BIOS, VirtIO block and network devices, an in-process rate limiter for sharing network and storage across thousands of microVMs, and a jailer process for production hardening.

You do not get a scheduler, a network fabric, a snapshot catalog, a template registry, or any API above "start this microVM with this kernel and rootfs."

Three gaps between that primitive and a sandbox product deserve names, because each one becomes a service you operate.

First, templates. Nobody boots a bare kernel for an agent. E2B boots a template: Ubuntu plus toolchains plus the in-VM daemon, snapshotted after provisioning so the next thousand sandboxes resume instead of booting. The pipeline from an OCI image to an ext4 filesystem to a provision script run to a versioned snapshot is its own build system, with its own cache invalidation and rollback story. Community reimplementations that tried to reuse E2B's stack kept exactly one piece — the in-VM agent — and threw away the cloud-infra concerns around it precisely because the pipeline is where the undifferentiated work lives.

Second, networking. A microVM gets a TAP device. A sandbox gets an identity: a slot on a bridge, iptables programming per sandbox, an egress proxy with policy, and an edge-routed endpoint the agent's caller can reach without learning your internal topology. Third-party teardowns of the stack call out network-slot allocation, veth and TAP creation, and iptables management as a discrete subsystem for a reason — it is the piece that turns "isolated compute" into "addressable, policy-enforced compute," and it fails in ways Firecracker's own logs never mention.

Third, the in-VM agent. E2B's envd daemon speaks protobuf-defined gRPC to the control plane and exposes the filesystem, process, and terminal APIs the SDK sells. Firecracker knows nothing about it. When you pin a kernel version, a rootfs, and an envd build, you own the three-way compatibility matrix and the rollout that upgrades it without stranding paused sandboxes on the old protocol.

None of this diminishes Firecracker. It explains why "we already run Firecracker" predicts so little about whether you can run sandboxes. The VMM answers how one sandbox is isolated. Everything about how ten thousand sandboxes are scheduled, snapshotted, networked, observed, and billed lives above it.

The math: hosted vs self-hosted for a typical agent workload​

Take a concrete, unflattering reference workload instead of a flattering one: a 12-engineer team running coding agents, averaging 200 agent sessions a day, 5 minutes of active sandbox each, at the default 2 vCPU plus 512 MiB size.

That is 200 times 5 minutes, or about 16.7 sandbox-hours a day — roughly 500 sandbox-hours a month before retries, long-tail debugging sessions, and eval harnesses. Round to 600 sandbox-hours a month to include the waste every real team has.

Hosted, the arithmetic is short. At 10.9 cents per sandbox-hour, 600 hours cost about 65 dollars in usage. On Hobby that fits inside the credit until it does not; on Pro the honest monthly total is the 150-dollar base plus roughly 65 dollars of usage, or about 215 dollars — before concurrency add-ons, support, or the annual commit an Enterprise plan trades for lower unit prices. Double the team or the session length and usage doubles while the base stays flat, so the hosted curve is nearly linear in sandbox-hours.

Self-hosted, the same workload has four cost lines, and only the first looks like the hosted bill.

Sensitivity is the point the pricing page cannot show. Concurrency, not total hours, sizes the fleet: 20 sandboxes peaking at once fits a fraction of the iron that 100 concurrent sandboxes needs, even at identical monthly hours, because the warm pool that delivers sub-200 ms starts is provisioned for the peak.

Session duration cuts the other way under pause-resume: short bursty sessions with pauses between agent turns bill almost nothing hosted while paused, but self-hosted they still occupy snapshot storage and control-plane bookkeeping. Retention is the silent multiplier — keep every paused sandbox for 30 days and the snapshot store becomes the bill; kill aggressively and you reintroduce the cold starts you self-hosted to avoid.

The breakeven moral is boring and therefore trustworthy. Below roughly low-thousands of sandbox-hours a month with bursty peaks, hosted wins because the control plane, warm pool, and on-call rotation amortize across E2B's fleet instead of yours. Past sustained high concurrency with predictable placement and a retention policy you actually enforce, self-hosting on owned iron starts to close — exactly the shape one operator's public estimate reached when it priced SaaS sandboxes near 73,000 dollars a month at its scale and chose bare metal instead. The crossover is a function of your concurrency profile, not your total hours.

What breaks first when you run it yourself​

Ask operators who tried, and the failure order is consistent. Placement breaks first: a single host works — upstream even ships a single-host path with Postgres, ClickHouse, and Redis on Compose and the API, orchestrator, and client-proxy as bare processes — but the second host demands real scheduling, and the tenth demands bin-packing discipline the dev path never taught you.

Snapshot storage breaks second: template versions accumulate, paused sandboxes linger past their usefulness, and restore latency creeps until someone writes the GC policy that should have shipped on day one. Network slots break third: bridge capacity, stale iptables rules after unclean sandbox deaths, and egress-proxy contention produce the class of bug that looks like agent flakiness and is actually fabric exhaustion.

Upgrades break last and loudest: five Go services plus Nomad job specs plus kernel plus rootfs plus in-VM daemon means every CVE touches a matrix, and the environment variables that require purging and re-applying a Nomad job to take effect are exactly the kind of sharp edge a hosted product files down before you ever see it.

There is also a platform dependency to price honestly. The production self-host path assumes GCP, Nomad, and Consul, with Terraform and Nomad job definitions as the deployment interface. Teams standardizing on Kubernetes-native fleet management or on Hetzner-owned iron inherit a translation layer — different substrate, same control-plane concepts — that the hosted product never asks them to think about.

Build, buy, or borrow: the PaaS decision​

For a self-hosted PaaS deciding whether sandboxes become a tenant-facing feature, the market in mid-2026 sorts into four shapes, not two.

Two borrow options sit underneath all four. The Kubernetes SIGs maintain an agent-sandbox project for teams that want sandbox lifecycle as Kubernetes objects, and the single-host Firecracker wrappers cover the private-one-box case with stronger isolation than containers and none of the fleet machinery. Both are honest answers to smaller questions than "run E2B yourself."

A Cluster API fleet on Hetzner-owned machines should read the table from the bottom up. If sandboxes are an experiment, borrow: single-host Firecracker or the Kubernetes-native sandbox with your existing observability. If they are a feature with SLAs, buy before you build: hosted E2B or an equivalent until concurrency, retention, and margin prove the crossover from the previous section. Only build — full E2B self-host or a bespoke control plane — when sandbox execution is load-bearing product surface with GPU or compliance requirements the hosted boundary cannot satisfy, and when the team signing up understands it is adopting scheduling, storage, networking, and lifecycle APIs as permanent scope, not standing up a fast VM.

Firecracker made the sandbox cheap. E2B's control plane is what made it a product. Self-hosting the first without staffing the second is how teams end up with fast microVMs and no sandbox platform — and now you know exactly which eight services stand between those two outcomes.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.