Self-hosted alternatives to E2B for AI-agent code, compared

You want an agent to run code it wrote, on machines you control, without trusting that code. This page compares the projects people find when they look for that: E2B self-hosted (Embed), Tencent Cube Sandbox, microsandbox, NVIDIA OpenShell, Kubernetes agent-sandbox, Beam (beta9), Docker Sandboxes (sbx), Temps, PandaStack, DifySandbox, Daytona, Northflank (bring your own cloud), and plimsoll. Every cell links to the page it came from, read on 2026-10-11.

Who wrote this. plimsoll's maintainer, so read it as one vendor's comparison. To keep it fair: each fact comes from the project's own documentation, README, license or release list, never from another comparison article; a fact found only in a project's marketing is marked (vendor claim); and plimsoll's weak points have their own section below. Found a mistake? Open an issue on GitHub ↗ and it gets fixed.

Terms used

microVM: A small virtual machine started per sandbox. The code gets its own Linux kernel, and the processor's virtualization keeps it apart from the host (Firecracker, libkrun, Cloud Hypervisor and RustVMM are programs that run them).
gVisor: A kernel written in Go that runs between a container and the host's kernel and answers the container's system calls itself, so the code never talks to the host kernel directly.
runc, plain container: Docker's default: the code shares the host's kernel, kept apart by Linux namespaces and cgroups. The weakest of the three for code you did not write.
KVM: The Linux kernel's built-in virtualization. MicroVMs need it, which rules out most cloud VMs that do not allow nested virtualization.
Outside-API keys: Where the password for an outside service (a database, a payments API) lives while agent-written code calls it. "Outside" means the code sees a stand-in and a proxy outside the sandbox adds the real key, so code that leaks what it holds leaks nothing.
seccomp, Landlock, chroot: Linux features that narrow what a process may do: which system calls it may make, which files it may touch, and which directory it sees as the root.
eBPF: Small programs loaded into the Linux kernel; here they filter a sandbox's network traffic.
CIDR: A way to write a range of IP addresses, such as 10.0.0.0/8.
RuntimeClass, NetworkPolicy: Kubernetes settings: which runtime a pod runs under (gVisor, Kata, plain containers), and which network traffic it may send.
One client, several backends: Whether the same code in your app can send runs to more than one place (your own machine, a hosted service) by changing configuration rather than code.

Pick by what you need

E2B's API, on your own hardware: E2B Embed (one Linux machine), or Tencent Cube Sandbox, which accepts E2B's SDK.
A microVM on a developer's laptop: microsandbox (a library, no server) or Docker Sandboxes (a CLI, not open source).
You already run Kubernetes: Kubernetes agent-sandbox with a gVisor or Kata RuntimeClass, Beam's beta9, or OpenShell's Helm chart.
Network off unless allowed: OpenShell and plimsoll deny it by default, and Docker Sandboxes' default mode allows only common development sites. E2B, microsandbox, Beam, PandaStack and DifySandbox start with the internet on.
One integration across several vendors and your own machine: plimsoll is built for that (Docker with or without gVisor, OpenShell, E2B, Docker Cloud Sandboxes), and every run states which isolation it ran behind. E2B's SDK also reaches Cube Sandbox, because Cube copies E2B's API.

At a glance

Project	Isolation of a run	Network by default	Outside-API keys	One client, several backends
plimsoll	Stated on every run: container (Docker under runc, OpenShell), kernel (gVisor), or VM (E2B, Docker Cloud). A caller can require a minimum and is refused before anything runs below it. No microVM of its own. github.com ↗	None. A run reaches the network only through a grant. github.com ↗	Outside. A grant lists exact method and path routes, the token is minted per run, and every call is traced (route pattern, status, size, time). github.com ↗	Yes, across vendors: Docker (runc or gVisor), OpenShell, E2B, Docker Cloud Sandboxes, or in-process WebAssembly (JavaScript snippets only). One daemon serves one; a routing library spreads calls over several. github.com ↗
E2B self-hosted (Embed)	Firecracker microVM per sandbox. github.com ↗	Internet on. Allow and deny lists by IP or CIDR; domains only in allow lists, matched for HTTP on 80 and TLS on 443. docs.e2b.dev ↗	Outside with E2B Secrets (generally available 2026-10-07); header rules in public beta; support in Embed not documented, bring-your-own-cloud "coming soon". e2b.dev ↗	E2B Cloud or Embed, same SDK; no other vendor. github.com ↗
Tencent Cube Sandbox	MicroVM on RustVMM and KVM, its own kernel per sandbox. github.com ↗	eBPF egress filtering and a proxy with per-domain, path and method rules. (vendor claim) github.com ↗	Outside: "automatic credential injection, secrets never visible to sandbox code". (vendor claim) github.com ↗	Its own engine, driven by E2B's SDK: "changing one environment variable". (vendor claim) github.com ↗
microsandbox	MicroVM per sandbox (libkrun). github.com ↗	Public internet on; private ranges, loopback and cloud metadata blocked; rules or no network on request. github.com ↗	Outside: the guest sees a placeholder, swapped for allowed hosts; needs intercepted TLS by default. docs.microsandbox.dev ↗	Local runtime or microsandbox cloud (private beta), same SDK; no other vendor. github.com ↗
NVIDIA OpenShell	One runtime per gateway: Docker, Podman, Kubernetes (Kata possible) or a libkrun microVM; Landlock and seccomp inside. docs.nvidia.com ↗	Denied except the sandbox's connection to its supervisor; per-program, per-destination policy. docs.nvidia.com ↗	Outside: "never sees real credential values"; the supervisor substitutes a placeholder. docs.nvidia.com ↗	Same CLI and SDK across its four runtimes, one per gateway; no other vendor. github.com ↗
Kubernetes agent-sandbox	Whatever the pod's RuntimeClass gives (gVisor or Kata); a plain pod without one. github.com ↗	With a template: public internet only (private ranges and metadata blocked), if the cluster's network plugin enforces NetworkPolicy. github.com ↗	Not documented; no broker. github.com ↗	gVisor or Kata per template, inside your cluster. github.com ↗
Beam (beta9)	Per worker pool: gVisor by default, runc for builds, a Cloud Hypervisor microVM on request. github.com ↗	Open; block all or a CIDR allow list (no domain rules). github.com ↗	Inside: secrets are passed to the container. github.com ↗	Beam's cloud or your own gateway, same SDK; no other vendor. (vendor claim) beam.cloud ↗
Docker Sandboxes (sbx)	MicroVM with its own kernel and Docker Engine. docs.docker.com ↗	Through a host proxy; first run picks Open, Balanced (deny by default plus common development sites) or Locked Down. docs.docker.com ↗, docs.docker.com ↗	Outside: the agent sees a sentinel and the host proxy adds the real header. docs.docker.com ↗	Local or Docker's cloud through one CLI, with separate credentials and policies. docs.docker.com ↗
Temps	Docker by default; Firecracker per sandbox once set up (without its jailer); microsandbox experimental. temps.sh ↗	No network or full egress; no allow list. "Restricted" mode falls back to no network until its proxy ships. temps.sh ↗	Inside today, as environment variables; a host-side proxy is proposed (ADR-013, 2026-05-14). github.com ↗	Docker, Firecracker or microsandbox inside Temps; its SDK copies Vercel Sandbox's shape (switching is a code change). github.com ↗
PandaStack	Firecracker microVM. github.com ↗	Open; no outbound allow list. github.com ↗	Not documented; no broker described. github.com ↗	Self-hosted or PandaStack Cloud, same core. (vendor claim) github.com ↗
DifySandbox	Process level: a seccomp allow list and chroot; no VM or gVisor. github.com ↗	On in the default config; proxy settings; Dify sends it through a proxy that blocks requests to internal addresses. github.com ↗	Inside if passed: named environment variables reach the script. github.com ↗	No.
Daytona	Docs name Linux namespaces; the README says "a dedicated kernel". Not settled. daytona.io ↗	Depends on account tier: restricted on tiers 1 and 2, open with allow lists on 3 and 4. daytona.io ↗	Outside: a placeholder in the sandbox, the value kept in Daytona's control plane. daytona.io ↗	Daytona's regions or your runners, one control plane. daytona.io ↗
Northflank (bring your own cloud)	Kata Containers or gVisor microVM. (vendor claim) northflank.com ↗	Not documented on the pages read.	Not documented on the pages read.	Northflank's cloud or yours, one vendor. northflank.com ↗

Every project in full

plimsoll ↗ (the project this page belongs to)

License: Apache-2.0 github.com ↗
How you run it yourself: One Go binary (plimsolld) beside Docker on Linux, with a gVisor installer; or the same binary in front of an OpenShell gateway, E2B or Docker Cloud Sandboxes. github.com ↗
Isolation of a run: Stated on every run: container (Docker under runc, OpenShell), kernel (gVisor), or VM (E2B, Docker Cloud). A caller can require a minimum and is refused before anything runs below it. No microVM of its own. github.com ↗
Network by default: None. A run reaches the network only through a grant. github.com ↗
Outside-API keys: Outside. A grant lists exact method and path routes, the token is minted per run, and every call is traced (route pattern, status, size, time). github.com ↗
One client, several backends: Yes, across vendors: Docker (runc or gVisor), OpenShell, E2B, Docker Cloud Sandboxes, or in-process WebAssembly (JavaScript snippets only). One daemon serves one; a routing library spreads calls over several. github.com ↗
Client SDKs: Go, Python, TypeScript; tools for Vercel AI SDK, Mastra, Trigger.dev, Agno, CrewAI and Google ADK. plimsollmark.github.io ↗
State across calls: Yes on Docker, OpenShell and E2B: files persist, and Python or JavaScript cells keep their variables. github.com ↗
Maturity: 2 stars; v0.21.0 (2026-10-09); first public release 2026-09-10; one maintainer; pre-1.0, so client and daemon upgrade together. github.com ↗

E2B self-hosted (Embed) ↗

License: Apache-2.0 github.com ↗
How you run it yourself: Docker Compose on one Linux host with KVM; Terraform for GCP, AWS and Azure; Kubernetes on one node. Several machines is E2B's paid deployment. github.com ↗
Isolation of a run: Firecracker microVM per sandbox. github.com ↗
Network by default: Internet on. Allow and deny lists by IP or CIDR; domains only in allow lists, matched for HTTP on 80 and TLS on 443. docs.e2b.dev ↗
Outside-API keys: Outside with E2B Secrets (generally available 2026-10-07); header rules in public beta; support in Embed not documented, bring-your-own-cloud "coming soon". e2b.dev ↗
One client, several backends: E2B Cloud or Embed, same SDK; no other vendor. github.com ↗
Client SDKs: JavaScript/TypeScript, Python. github.com ↗
State across calls: Yes: pause and resume, auto-pause, fork, volumes. github.com ↗
Maturity: Runtime 1,709 stars, release 2026.30 (2026-09-10); SDK 14,280 stars. github.com ↗

Tencent Cube Sandbox ↗

License: Apache-2.0 with listed third-party exceptions github.com ↗
How you run it yourself: x86_64 Linux with KVM, one node or a cluster; Kubernetes in preview. github.com ↗
Isolation of a run: MicroVM on RustVMM and KVM, its own kernel per sandbox. github.com ↗
Network by default: eBPF egress filtering and a proxy with per-domain, path and method rules. (vendor claim) github.com ↗
Outside-API keys: Outside: "automatic credential injection, secrets never visible to sandbox code". (vendor claim) github.com ↗
One client, several backends: Its own engine, driven by E2B's SDK: "changing one environment variable". (vendor claim) github.com ↗
Client SDKs: E2B's SDK. github.com ↗
State across calls: Yes: auto-pause and resume, snapshots. github.com ↗
Maturity: 12,880 stars; v0.7.2 (2026-09-24); repository since 2026-04-10. github.com ↗

microsandbox ↗

License: Apache-2.0 github.com ↗
How you run it yourself: A library or the msb CLI, no server; Linux with KVM, macOS on Apple Silicon, Windows with WHP. github.com ↗
Isolation of a run: MicroVM per sandbox (libkrun). github.com ↗
Network by default: Public internet on; private ranges, loopback and cloud metadata blocked; rules or no network on request. github.com ↗
Outside-API keys: Outside: the guest sees a placeholder, swapped for allowed hosts; needs intercepted TLS by default. docs.microsandbox.dev ↗
One client, several backends: Local runtime or microsandbox cloud (private beta), same SDK; no other vendor. github.com ↗
Client SDKs: TypeScript, Rust, Python, Go, Ruby. github.com ↗
State across calls: Yes: named long-running sandboxes, snapshots, fork. github.com ↗
Maturity: 8,650 stars; v0.7.8 (2026-10-09); README: "still beta software. Expect breaking changes". github.com ↗

NVIDIA OpenShell ↗

License: Apache-2.0 github.com ↗
How you run it yourself: An install script for a local gateway, or Helm on Kubernetes; Linux, macOS, WSL 2 (experimental). github.com ↗, docs.nvidia.com ↗
Isolation of a run: One runtime per gateway: Docker, Podman, Kubernetes (Kata possible) or a libkrun microVM; Landlock and seccomp inside. docs.nvidia.com ↗
Network by default: Denied except the sandbox's connection to its supervisor; per-program, per-destination policy. docs.nvidia.com ↗
Outside-API keys: Outside: "never sees real credential values"; the supervisor substitutes a placeholder. docs.nvidia.com ↗
One client, several backends: Same CLI and SDK across its four runtimes, one per gateway; no other vendor. github.com ↗
Client SDKs: Python, TypeScript, Go, Rust. github.com ↗
State across calls: Yes: create, connect, stop, start. github.com ↗
Maturity: 15,845 stars; v0.1.3 (2026-10-09). github.com ↗

Kubernetes agent-sandbox ↗

License: Apache-2.0 github.com ↗
How you run it yourself: kubectl or Helm on your own cluster. github.com ↗
Isolation of a run: Whatever the pod's RuntimeClass gives (gVisor or Kata); a plain pod without one. github.com ↗
Network by default: With a template: public internet only (private ranges and metadata blocked), if the cluster's network plugin enforces NetworkPolicy. github.com ↗
Outside-API keys: Not documented; no broker. github.com ↗
One client, several backends: gVisor or Kata per template, inside your cluster. github.com ↗
Client SDKs: Go, Python; TypeScript in progress. github.com ↗
State across calls: Yes: one stateful pod with stable identity and storage; warm pools. github.com ↗
Maturity: 4,221 stars; v1.0.6 (2026-10-08); API v1beta1. github.com ↗

Beam (beta9) ↗

License: AGPL-3.0 github.com ↗
How you run it yourself: Helm on Kubernetes. github.com ↗
Isolation of a run: Per worker pool: gVisor by default, runc for builds, a Cloud Hypervisor microVM on request. github.com ↗
Network by default: Open; block all or a CIDR allow list (no domain rules). github.com ↗
Outside-API keys: Inside: secrets are passed to the container. github.com ↗
One client, several backends: Beam's cloud or your own gateway, same SDK; no other vendor. (vendor claim) beam.cloud ↗
Client SDKs: Python, TypeScript. github.com ↗, github.com ↗
State across calls: Yes: keep-warm, durable disks, memory snapshots. github.com ↗
Maturity: 1,809 stars; continuous component tags. github.com ↗

Docker Sandboxes (sbx) ↗

License: Proprietary, no source github.com ↗
How you run it yourself: The sbx CLI on your own machine (a developer tool, not a server); Linux needs KVM. docs.docker.com ↗, github.com ↗
Isolation of a run: MicroVM with its own kernel and Docker Engine. docs.docker.com ↗
Network by default: Through a host proxy; first run picks Open, Balanced (deny by default plus common development sites) or Locked Down. docs.docker.com ↗, docs.docker.com ↗
Outside-API keys: Outside: the agent sees a sentinel and the host proxy adds the real header. docs.docker.com ↗
One client, several backends: Local or Docker's cloud through one CLI, with separate credentials and policies. docs.docker.com ↗
Client SDKs: Local: CLI only. Cloud: REST API and an experimental TypeScript SDK. docs.docker.com ↗
State across calls: Yes: persists until removed. docs.docker.com ↗
Maturity: v0.47.0 (2026-10-05); cloud API and SDK experimental. github.com ↗, docs.docker.com ↗

Temps ↗

License: MIT or Apache-2.0 github.com ↗
How you run it yourself: One Rust binary with PostgreSQL; Firecracker needs /dev/kvm and a root setup step. github.com ↗, temps.sh ↗
Isolation of a run: Docker by default; Firecracker per sandbox once set up (without its jailer); microsandbox experimental. temps.sh ↗
Network by default: No network or full egress; no allow list. "Restricted" mode falls back to no network until its proxy ships. temps.sh ↗
Outside-API keys: Inside today, as environment variables; a host-side proxy is proposed (ADR-013, 2026-05-14). github.com ↗
One client, several backends: Docker, Firecracker or microsandbox inside Temps; its SDK copies Vercel Sandbox's shape (switching is a code change). github.com ↗
Client SDKs: Node, Python. github.com ↗
State across calls: Partly: files survive a suspend, memory and processes do not. temps.sh ↗
Maturity: 836 stars; v0.1.0-beta.57 (2026-10-11); no stable release. github.com ↗

PandaStack ↗

License: Apache-2.0 (some database features cloud-only) github.com ↗
How you run it yourself: KVM hosts; Terraform for AWS and GCP; a single-node Linux quickstart is on the roadmap. github.com ↗
Isolation of a run: Firecracker microVM. github.com ↗
Network by default: Open; no outbound allow list. github.com ↗
Outside-API keys: Not documented; no broker described. github.com ↗
One client, several backends: Self-hosted or PandaStack Cloud, same core. (vendor claim) github.com ↗
Client SDKs: Python, TypeScript; REST API. github.com ↗
State across calls: Yes: pause and resume, hibernate, snapshots, fork. github.com ↗
Maturity: 32 stars; no releases; repository since 2026-06-14. github.com ↗

DifySandbox ↗

License: Apache-2.0 github.com ↗
How you run it yourself: A Go server or its image, Linux only; ships inside Dify's Docker Compose. github.com ↗
Isolation of a run: Process level: a seccomp allow list and chroot; no VM or gVisor. github.com ↗
Network by default: On in the default config; proxy settings; Dify sends it through a proxy that blocks requests to internal addresses. github.com ↗
Outside-API keys: Inside if passed: named environment variables reach the script. github.com ↗
One client, several backends: No.
Client SDKs: None; an HTTP API Dify calls. Runs Python and Node.js. github.com ↗
State across calls: No. github.com ↗
Maturity: 1,274 stars; 0.2.15 (2026-04-27). github.com ↗

Daytona ↗

License: Closed source since 2026-06-11; the archived tree stays AGPL-3.0 at v0.190.0 daytona.io ↗, github.com ↗
How you run it yourself: Runners only, by Helm, under Daytona's hosted control plane. daytona.io ↗
Isolation of a run: Docs name Linux namespaces; the README says "a dedicated kernel". Not settled. daytona.io ↗
Network by default: Depends on account tier: restricted on tiers 1 and 2, open with allow lists on 3 and 4. daytona.io ↗
Outside-API keys: Outside: a placeholder in the sandbox, the value kept in Daytona's control plane. daytona.io ↗
One client, several backends: Daytona's regions or your runners, one control plane. daytona.io ↗
Client SDKs: Python, TypeScript, Ruby, Go, Java. daytona.io ↗
State across calls: Yes: stateful sandboxes, snapshots, volumes. github.com ↗
Maturity: Repository archived; last open release v0.190.0 (2026-06-23). github.com ↗

Northflank (bring your own cloud) ↗

License: Proprietary northflank.com ↗
How you run it yourself: Northflank's control plane deploys into your cloud account; not software you run alone. northflank.com ↗
Isolation of a run: Kata Containers or gVisor microVM. (vendor claim) northflank.com ↗
Network by default: Not documented on the pages read.
Outside-API keys: Not documented on the pages read.
One client, several backends: Northflank's cloud or yours, one vendor. northflank.com ↗
Client SDKs: JavaScript, CLI, REST API. northflank.com ↗
State across calls: Yes: ephemeral or persistent with volumes. (vendor claim) northflank.com ↗
Maturity: Commercial service; no public repository.

Where plimsoll is weaker

It is new. First public release 2026-09-10, one maintainer, few users. The others above with thousands of stars have far more people running them.
No microVM of its own. Self-hosted, its strongest boundary is gVisor (it reports that as the kernel tier). The VM tier comes only from E2B or Docker Cloud Sandboxes, which bill by the second. If you need a microVM on your own hardware today, E2B Embed, Cube Sandbox, microsandbox or PandaStack give you one.
gVisor costs time. On one machine, a one-file TypeScript compile-and-run took 4.1 s under gVisor against 1.95 s as a plain container (median of 20, 2026-09-29; measurement ↗).
Before 1.0, versions move together. v0.21.0 changed the protocol, so a 0.20 client and a 0.21 daemon refuse each other; upgrade both.
No Kubernetes deployment of its own. It runs as one binary beside Docker, or in front of a service that runs the sandboxes.

Hosted only, not self-hostable

Modal Sandboxes: gVisor or VMs; secrets as environment variables in the sandbox; no self-hosting offered. modal.com ↗
Vercel Sandbox: Firecracker microVM; the SDK is Apache-2.0 but the service runs on Vercel. vercel.com ↗
Cloudflare Sandbox: A microVM per container instance on Cloudflare; Workers Paid plan. developers.cloudflare.com ↗

Out-of-date claims in other comparisons

Daytona is no longer open source (2026-06-11). Articles from before June call it AGPL and self-hostable. daytona.io ↗
E2B's self-hosting is now Embed: one Linux machine by Docker Compose, Terraform or Kubernetes, no license key. Older articles describe a Nomad setup on GCP. github.com ↗
Kubernetes agent-sandbox is at v1.0.6 with a v1beta1 API, not alpha. github.com ↗
Two repositories moved: e2b-dev/infra is e2b-dev/runtime, and microsandbox is superradcompany/microsandbox. github.com ↗