Design goals
The system exists to run code its operators do not trust — typically AI-generated — without that code being able to harm the host, other workloads, or the data around it. Two non-functional properties dominate every decision: high isolation and high scalability.
Treat every workload as hostile, then make 'hostile' boring.
High isolation
Isolation is layered on purpose, because no single mechanism is sufficient on its own:
- Namespaces hide the rest of the system from the workload (what it can see).
- Seccomp-BPF removes syscalls the workload should never need (what it can ask the kernel to do).
- Cgroups cap CPU, memory, I/O and process count (how much it can use).
- Timeouts bound how long it can run (how long it can hold a slot).
Together they form four independent walls. An attacker has to defeat all of them at once, which is far harder than slipping past any one.
High scalability
Scale comes from the Job Manager / execution-node split. The control plane (UI, database, Job Manager) stays small and shared; the data plane (execution nodes) is stateless and disposable. To handle more load you add nodes — the Job Manager just dispatches to more of them.
Why a database in the middle
Routing jobs, results and logs through a shared database decouples the layers: the UI never calls an execution node directly, and monitoring can read everything without touching the sandbox. Decoupled layers can be scaled — and reasoned about — independently.
Industry context (verified)
This design sits squarely in a fast-moving field. A few corroborated data points for scale:
- A 2025 Veracode report found ~45% of AI-generated code fails security tests — sandboxing is not optional.
- E2B reported sandbox sessions growing from ~40,000/month (Mar 2024) to ~15M/month (Mar 2025).
- Stronger isolation tiers exist above this design: gVisor intercepts syscalls in user space (only a vetted subset reaches the host); Firecracker microVMs give each workload its own kernel, booting in ~125ms with under 5 MiB overhead.
- A common production recommendation is defense in depth: namespaces + seccomp + cgroups, optionally wrapped in a microVM for a hardware boundary.
Sources
- Linux namespaces — en.wikipedia.org/wiki/Linux_namespaces
- Seccomp BPF — docs.kernel.org/userspace-api/seccomp_filter.html
- Control Group v2 — docs.kernel.org/admin-guide/cgroup-v2.html
- What are namespaces and cgroups — blog.nginx.org
- How to sandbox AI agents — northflank.com/blog/how-to-sandbox-ai-agents
- Sandboxed environments for AI coding — bunnyshell.com