Why we picked E2B sandboxes over containers

Every AI app builder runs user code somewhere. The choice of where shapes everything else: cold-start time, security model, cost, and what kinds of bugs your users will hit. We tried containers, microVMs, and WebContainers before settling on E2B. Here is what tipped it.

The contenders

• Docker containers on a shared host. Cheap, slow to start, hard to isolate properly.
• Firecracker microVMs. Fast, properly isolated, but operational overhead is real.
• WebContainers in the browser. Magical for demos, but Node compatibility limits bite quickly on real apps.
• E2B — managed Firecracker, stateful sandboxes, sub-second resume.

The thing that mattered

Resume time. Most user sessions go cold for a few minutes between turns. With containers, resuming a session means rebuilding state, re-installing deps, and re-warming the dev server — sometimes 30+ seconds of "where did my preview go?" With E2B, resuming a paused sandbox is well under a second. That single number is responsible for most of how "instant" Vibely feels.

What we gave up

Some control over the host environment, and a real bill that scales with usage. Both are worth it. The team we would have needed to operate Firecracker ourselves would have cost more than E2B by an order of magnitude — and we would still be debugging it instead of shipping product.

What we kept

The agent loop is a single while in our process, and the sandbox is a side effect of it. If E2B ever becomes the wrong answer, we can swap the implementation behind one interface (src/sandbox/e2b-sandbox.ts) without touching the agent.