E2B sandboxes are fast-booting virtual machines for running agent-generated code in isolation. In a 2026 workshop, E2B engineer Matt Brockman taught the operational basics: identify your sandbox, kill runaway processes, manage idle timeouts, and map users to dedicated sandboxes so work survives between sessions.
What E2B Sandboxes Are and Why AI Agents Need Them
E2B sandboxes are isolated virtual machines that let AI agents run generated code without touching your servers, your secrets, or other users. Matt Brockman, an engineer at E2B, delivered this message through a hands-on capture the flag workshop rather than slides, and the format itself teaches the core skill: knowing what is running inside a sandbox and how to shut it down.
The problem E2B targets is concrete. Tools like Claude Code, Anthropic agentic coding tool, can run with full permissions on a local machine, where a misbehaving agent can spawn processes, exhaust CPU, delete files, or read environment variables. Running agent code on a shared server introduces the same risks plus exposed secrets. A sandbox gives the agent a disposable environment with defined resource limits instead.
E2B aims to start sandboxes in under 100 milliseconds, a target Brockman stated on stage, so agents can run many environments in parallel. The E2B platform exposes SDKs in Python and JavaScript, and the infrastructure backend is written mostly in Go, which is why Brockman spent a slide recruiting Go engineers. The infra repository is open source.
The mechanism differs from Docker in one important way. Instead of building an image and running a start command, an E2B template captures a virtual machine with its processes already running, its memory and filesystem snapshotted. When you start a sandbox from that template, everything resumes from that saved state rather than booting cold.
How the Capture the Flag Workshop Taught Sandbox Operations
The workshop was structured as a capture the flag game: each level presented a broken sandbox, participants diagnosed and fixed it, and the fix unlocked the next level. The first several levels required no code at all, only Linux commands and configuration. Coding in Python or JavaScript began around level seven.
Every challenge ran in its own sandbox spawned from a shared template, so a mistake cost nothing. Brockman broke his own demo twice on stage and recovered by clicking the reload button, which spawns a fresh copy of the template snapshot. That reset ability is itself the lesson: sandboxes are meant to be disposable, and the workflow should assume failure.
The levels covered in the session map directly to failures production users hit, as this table shows.
| Level theme | Failure demonstrated | Skill practiced |
|---|---|---|
| Sandbox identity | Unknown environment | Find the sandbox ID from the URL |
| CPU exhaustion | Process at 99.7% CPU | Inspect processes and kill the offender |
| Memory pressure | Agent code consuming RAM | Identify and terminate the process |
| Disk fill | A 512 MB file in /tmp | Locate the file, report the path, delete it |
| Lifecycle | Sandboxes outliving their tasks | Tune run timeouts and idle timeouts |
| Orphan processes | Leaked background children | Find and kill orphans |
| Workspaces | Round-robin sandbox assignment | Map each user to a dedicated sandbox ID |
Participants who preferred not to type commands could hand the sandbox ID to an AI agent with access to the E2B SDK, and Brockman noted that most agents already know the SDK. He still recommended doing the early levels by hand, because the point was learning what the commands do.
Templates: Snapshotting Memory and Filesystem for Resumable Work
Templates are the feature that makes the resumability work. An E2B template is a snapshotted virtual machine: you start a VM, run whatever setup processes you need, and save the whole state, memory included. Brockman demonstrated this by preparing the capture the flag environment in advance and spawning roughly 200 copies of it for the room, each participant resuming the sandbox exactly where he had left off.
For agent workloads the payoff is error reduction. An agent that pauses mid-task expects the filesystem, running processes, and in-memory state to be identical when it returns. Snapshot and resume makes that true, so the agent does not rediscover a cold environment and fail.
The tradeoff is inherited state. Because processes keep running across snapshots, whatever you forget to clean up comes back with the sandbox. Brockman argued that a large share of sandbox management is exactly this: killing orphans left behind by earlier work. He also pointed to fork-and-parallelize use cases, such as taking a loaded dataframe and spinning up five sandboxes to run five experiments at once.
Templates also function as an early ecosystem primitive. In the audience Q&A, Brockman compared the emerging sandbox ecosystem to Docker's and positioned templates as the shareable unit: prepare an environment once, let others resume from it.
Sandbox Lifecycle: Long Enough to Finish, Short Enough to Be Cheap
Lifecycle management is where sandbox costs are won or lost. A traditional server runs until you shut it down; a sandbox fleet with thousands of users cannot afford that. The workshop's lifecycle level simulated the policy: give a task a generous command timeout, in the demo one hour, so long jobs such as video processing or large file reads can finish, then cut the sandbox's idle lifetime down to one minute once the task completes.
The logic is a speed-versus-cost tradeoff. A running sandbox is fast but holds CPU and RAM quota; a paused sandbox is cheap to keep around in quantity. Brockman's guidance: let the task dictate the runtime, then reclaim resources quickly so another user's sandbox can start.
He also set a boundary. Sandboxes are a poor fit for long-lived daemons or persistent web servers that need CDN-style optimization; those workloads have cheaper, more traditional homes. Cloud coding sessions, where an agent may use one of many sandboxes and return unpredictably, are the canonical fit for the long-run-then-short-idle pattern.
Orphans, Workspaces, and File Permissions in Practice
Three later levels addressed the mess that resumed state creates. The orphan-process level showed a sandbox accumulating leaked background children, in the demo three processes helpfully named 'orphan worker', found by listing processes and killed one PID at a time. Brockman's blunt summary: a lot of sandbox management ends up being killing orphans, and unlike the demo, real orphaned processes are rarely named helpfully.
The workspace level replaced naive round-robin sandbox assignment with a user-to-sandbox mapping. In the Python exercise, an assign_sandbox function checked an assignments dictionary first, returned the existing sandbox ID if present, and only created a new sandbox otherwise. In production he recommended a persistent database tracking users and active sandboxes, which also lets you audit whether you are reassigning too many sandboxes.
The file-permission level separated a template's read-only cache directory from a writable runtime cache location, so agent code writes where it is allowed and nowhere else. Brockman connected this to how tools like Claude Code scope agent write access, typically configured through agents' instruction files rather than hardcoded paths. The recurring theme across all three levels is the same: track what runs where, what it may touch, and who owns it.
Limits and Roadmap: No GPUs, Firecracker Under the Hood
The Q&A set honest boundaries. E2B does not support GPUs, Brockman said in response to an engineer running distributed small-GPU workloads across providers, so that use case needs a different substrate. He also acknowledged that storage growth over time, pruning accumulated sandbox resources, is an open challenge the team is actively working on, alongside compression of stored state.
Under the hood, E2B sandboxes run on Firecracker, the microVM technology AWS open-sourced in 2018 and uses for Lambda and Fargate. Orchestration currently runs on Nomad; Brockman said the team is working toward Kubernetes but has unresolved technical issues with running Firecracker-based workloads on it. Volumes are available for shared resources that multiple sandboxes need to access.
On network restrictions, his guidance was a tradeoff between ease and security: if a sandbox holds secrets or production credentials, restrict what it can send out; if it only has dev keys, looser rules may be acceptable. Asked whether sandboxes would get a Docker-scale ecosystem, he declined to predict, noting that AI agents were roughly two years old and LLM-as-a-service about five, so nobody knows yet. Locally running coding agents such as Claude Code or Codex inside a sandbox works today, and one sandbox spawning further sandboxes from a template is supported, though the workshop did not automate it to avoid exposing API keys on a recorded stage.
Frequently Asked Questions
- What is an E2B sandbox? An E2B sandbox is an isolated microVM, built on Firecracker, where AI agents can execute generated code with defined CPU, memory, and disk limits. Sandboxes boot from templates that snapshot running processes and filesystem state, aiming for startup in under 100 milliseconds.
- How do E2B sandboxes differ from Docker containers? A Docker image starts cold from a build with a start command, while an E2B template resumes a VM with its processes already running and memory snapshotted. That makes agent work resumable mid-task, at the cost of inheriting any processes the previous session forgot to clean up.
- Does E2B support GPU workloads? No. As of the October 2026 workshop, E2B does not offer GPUs, and Brockman directed distributed GPU use cases to other infrastructure. CPU-based agent workloads, data science, and web scraping are the supported fit.
- What is the most common operational problem with sandboxes? Orphaned background processes that accumulate when sandboxes are paused and resumed instead of rebuilt. The workshop's answer is routine process inspection, killing leaked children, and tuning idle timeouts so finished sandboxes release their resources.
- Can coding agents like Claude Code run inside an E2B sandbox? Yes. Brockman demonstrated that Claude Code and Codex can run inside a sandbox, giving the agent a remote or local execution environment it talks to programmatically. Sandboxes can even spawn additional sandboxes from a template via the SDK.
Turn Your Own Workshop Recording Into a Written Walkthrough
Brockman's workshop worked because each broken sandbox became a level someone could follow. If you have that kind of hands-on teaching trapped in a conference talk, a livestream, or a demo recording, the same transformation applies: the transcript becomes a structured, searchable article.
Skala Blog turns a YouTube video into a publishable walkthrough. Paste the URL, the video is transcribed, and you get a drafted article with headings, tables, and answers shaped for search. Your operational knowledge, the kind this workshop taught, deserves a written form people can find.
Fork this article
Start a new branch from the same video, shaped your way. You keep the credit; the original keeps the attribution.
A fork in another language is filed as a translation of this article, so the two pages point at each other. You can unlink it later from the editor.
0/240
You are creating
- Format
- For
- Language
- Source
- Your angle
You will be asked to sign in before it is generated.
Buy credits