How I Learned to Stop Worrying and Love the Sandbox — Matt Brockman, E2B

1. Matt Brockman on Why AI Agents Need Sandboxes

Timestamp: 00:02:51 to 00:04:53

Running AI coding tools like Codex or Claude Code directly on a local machine or shared server exposes environment variables, secrets, and files to accidental deletion or CPU exhaustion. Matt Brockman explains that E2B isolates user and agent code in dedicated sandboxes while aiming to spin them up in under 100 milliseconds. This rapid isolation lets developers run untrusted agent workloads safely in parallel.

Significance (High): Frames fast microVM isolation as a foundational security boundary for autonomous coding agents that execute arbitrary commands.

Sources in support: Matt Brockman (Engineer at E2B)

2. Snapshotting Running Memory and Disk State

Timestamp: 00:04:54 to 00:08:11

Unlike Docker images that build static layers and run a start command on boot, E2B starts processes first and snapshots both RAM and the filesystem. When an AI agent pauses to perform work elsewhere and returns later, the sandbox resumes with processes and memory intact as if no time passed. Brockman notes that preserving exact runtime state reduces agent execution errors.

Significance (High): Distinguishes stateful VM snapshots from cold container boots, cutting agent failures caused by lost in-memory context.

Sources in support: Matt Brockman (Engineer at E2B)

3. Orienting in the Sandbox Dashboard and URL Routing

Timestamp: 00:08:12 to 00:10:49

During the initial capture-the-flag setup, participants log into the E2B web dashboard to launch a terminal and web server inside a live sandbox. To solve the first challenge of identifying the active environment, participants can extract the sandbox identifier directly from the browser URL. E2B constructs exposed service URLs by combining the listening port number and the unique sandbox ID.

Significance (Low): Shows how port-prefixed URLs give developers immediate HTTP access to services running inside isolated cloud environments.

Sources in support: Matt Brockman (Engineer at E2B)

4. Forking VM Templates and Killing Runaway CPU Tasks

Timestamp: 00:16:02 to 00:20:06

Matt Brockman explains that all 200 workshop copies are forked from a single snapshotted VM template, a pattern also useful for running parallel data science experiments. Opening a dedicated sub-sandbox for level two, he inspects running processes via a pseudo-terminal and finds a runaway task consuming 99.7% of the CPU. Killing process ID 1250 restores normal operation and unlocks the next level.

Significance (High): Illustrates both parallel environment forking from a single VM template and isolating runaway AI code so it can be terminated safely.

Sources in support: Matt Brockman (Engineer at E2B)

5. Resolving Memory Pressure Under Fleet Quotas

Timestamp: 00:20:16 to 00:22:31

Moving to the third challenge, Brockman highlights that running fleets of sandboxes introduces strict trade-offs between CPU speed, RAM allocation, and cloud instance quotas. When an agent or user script balloons memory usage inside a sandbox, operators must quickly identify and terminate the offending process to conserve fleet capacity. Using terminal inspection commands, he locates and kills process 1248 to clear the memory spike.

Significance (Medium): Highlights why per-sandbox memory discipline is essential when operating under finite cloud CPU and RAM quotas.

Sources in support: Matt Brockman (Engineer at E2B)

6. Recovering Broken Environments and Clearing Disks

Timestamp: 00:22:40 to 00:27:44

In the fourth challenge, a 512-megabyte binary file in the temporary directory fills the sandbox disk. When Brockman manually deletes the file from the terminal instead of submitting its path through the lab checker, he accidentally breaks the challenge state. Because each exercise runs in an isolated snapshot, he clicks the reload button to spawn a fresh copy in seconds and properly submits the path.

Significance (Medium): Proves the operational value of disposable snapshots: even when an operator breaks an environment, resetting to a known state takes seconds.

Sources in support: Matt Brockman (Engineer at E2B)

7. Programmatic SDK Control vs Browser Debugging

Timestamp: 00:27:45 to 00:30:25

Responding to an audience question about resetting state and automated scraping, Matt Brockman clarifies that production applications interact with E2B sandboxes programmatically through a backend server rather than a browser terminal. However, exposing a fast browser UI and terminal remains valuable for human developers who need to inspect and debug live failures. He then completes the reset disk cleanup level to advance the workshop.

Significance (Low): Clarifies the boundary between automated SDK orchestration in production and interactive browser terminals used for human debugging.

Sources in support: Matt Brockman (Engineer at E2B)

8. Balancing Long Task Lifetimes With Short Timeouts

Timestamp: 00:31:14 to 00:35:32

Pre-allocating 20-minute sandboxes for thousands of web visitors wastes capacity when users bounce, yet data science and video processing tasks require long uninterrupted runtimes. Matt Brockman demonstrates a two-phase lifecycle policy: granting a sandbox a one-hour timeout while a command actively runs, then dropping the idle timeout to one minute once the task finishes. This ensures long jobs complete while idle instances rapidly pause or shut down.

Significance (High): Provides a concrete lifecycle pattern that prevents long jobs from timing out without paying for idle compute across thousands of users.

Sources in support: Matt Brockman (Engineer at E2B)

9. Matt Brockman on Persistent Daemons and Forking

Timestamp: 00:35:46 to 00:39:03

Addressing audience questions on lifecycle trade-offs, Matt Brockman notes that running sandboxes are fast while paused sandboxes are cheap. For persistent, day-long daemons or production web servers requiring CDNs, he advises that traditional hosting is often cheaper and better optimized than a sandbox. Conversely, forking a pre-cached base template across multiple Git worktrees is an ideal sandbox workflow.

Significance (Medium): Helps engineers recognize when not to use sandboxes, steering always-on daemons to standard servers while reserving templates for parallel worktrees.

Sources in support: Matt Brockman (Engineer at E2B)

10. Why State Snapshots Accumulate Orphaned Processes

Timestamp: 00:39:04 to 00:42:30

Because E2B pauses and resumes existing VM states rather than booting fresh container images every time, uncleaned background tasks persist across sessions. Over time, these leaked child processes accumulate and degrade sandbox performance, just as forgotten sandboxes consume fleet resources if not tracked. Brockman demonstrates searching for three leaked worker processes and terminating their PIDs to restore the environment.

Significance (High): Exposes the primary operational downside of stateful VM snapshots: forgotten background processes survive across pause-and-resume cycles.

Sources in support: Matt Brockman (Engineer at E2B)

11. Replacing Round-Robin Routing With User Mapping

Timestamp: 00:42:31 to 00:50:07

In the first Python coding challenge, Matt Brockman critiques naive round-robin sandbox allocation, which hands users arbitrary instances and loses their prior workspace state. In production, a database should map user IDs to active sandbox IDs, while also separating read-only template caches from writable runtime directories. Brockman edits a Python router function to store user-to-sandbox assignments in a dictionary and updates a cache config path to pass the test suite.

Significance (High): Demonstrates the core routing and filesystem permission patterns needed so returning users reconnect to their exact workspace without corrupting shared template caches.

Sources in support: Matt Brockman (Engineer at E2B)

12. Matt Brockman on GPU Limits, Nomad, and Security

Timestamp: 00:51:48 to 00:59:04

During the final Q&A, Matt Brockman explains that E2B does not currently support GPUs and that fleet-scale challenges center on storage compression, logging, and network connection limits per host. He reveals that E2B uses Firecracker microVMs orchestrated with Nomad because the team has not yet resolved technical issues with Kubernetes, though shared volumes and nested sandboxes are supported. Finally, he notes that network egress rules should restrict sandboxes that hold production secrets.

Significance (High): Offers candid infrastructure transparency on E2B's Firecracker-on-Nomad stack, lack of GPU support, storage pruning hurdles, and secret exfiltration rules.

Sources in support: Matt Brockman (Engineer at E2B)

Speaker Employed by Featured Platform E2B (Medium severity)

Type: Commercial

Matt Brockman is an engineer at E2B and uses the workshop to require E2B account sign-ups, pitch E2B's startup credit program, and recruit Go backend engineers.

Significance: Architectural comparisons between snapshotted microVMs and traditional containers favor E2B's design, and performance targets like sub-100ms spin-up times are presented from an insider perspective.