# What are the best open-source sandboxes for AI agents? > E2B Runtime, microsandbox, Kata Containers, Firecracker, OpenHands and LLM Sandbox compared for self-hosted agent code: license, isolation, GPUs, effort. Source: https://www.nodus-compute.ai/blog/open-source-ai-agent-sandboxes/ Build revision: 6510e19cffae8c0eece3cc7a12cf299b2b2bd168 The best open-source sandboxes for AI agents are E2B Runtime and microsandbox for microVM isolation, Kata Containers for Kubernetes shops, and OpenHands or LLM Sandbox when a container is enough. If you would rather not run KVM hosts, Nodus Sandboxes are the managed option, with networking off by default and a 2 vCPU, 4 GiB sandbox listed at $0.0357/hr on the Nodus pricing page. Self-host when code or data must stay on machines you control; otherwise price the managed bill first. We build Nodus, which is a managed service, not an open-source project. Every fact about the projects below comes from their own GitHub repositories and docs, read on November 12, 2026. If you want managed E2B, Modal, Daytona and Nodus compared instead, read [Which sandbox is best for running AI agent code?](https://www.nodus-compute.ai/blog/best-sandbox-for-ai-agents/). ## Which open-source agent sandboxes can you self-host today? Six projects are maintained, open source and built or documented for running untrusted code. They split into two groups: microVM projects that give every sandbox its own guest kernel, and container projects that share the host kernel. |Project|License|Isolation|GPU|What you run| |-|-|-|-|-| |[E2B Runtime](https://github.com/e2b-dev/runtime)|Apache-2.0|Firecracker microVM per sandbox|Not documented|One KVM host with Docker Compose, or Terraform on GCP, AWS or Azure, or one Kubernetes node| |[microsandbox](https://github.com/superradcompany/microsandbox)|Apache-2.0|libkrun microVM, embedded as a library|Not documented|A CLI or SDK on Linux with KVM, Apple Silicon macOS or Windows; beta| |[Kata Containers](https://github.com/kata-containers/kata-containers)|Apache-2.0|Lightweight VM per container, via a containerd shim|NVIDIA passthrough with QEMU|A Kubernetes or containerd cluster plus a hypervisor| |[Firecracker](https://github.com/firecracker-microvm/firecracker)|Apache-2.0|KVM microVM monitor|Not documented|A building block; you write the API and lifecycle| |[OpenHands agent server](https://docs.openhands.dev/sdk/guides/agent-server/docker-sandbox.md)|MIT|Docker container, or rootless Apptainer|Not documented|Docker on the host| |[LLM Sandbox](https://github.com/vndee/llm-sandbox)|MIT|Docker, Podman, Kubernetes, Bubblewrap or NsJail|Not documented|A Python library plus one backend| Sources: each project’s README and docs linked in the table, the [E2B Embed guide](https://github.com/e2b-dev/runtime/blob/main/embed/README.md), the [Kata hypervisors table](https://github.com/kata-containers/kata-containers/blob/main/docs/hypervisors.md) and [OpenHands SDK license](https://github.com/OpenHands/software-agent-sdk). Checked November 12, 2026. “Not documented” means the project’s own pages do not describe GPU support, not that it is impossible. ![Open-source agent sandboxes: E2B Runtime, microsandbox and Firecracker use microVMs, Kata Containers uses a lightweight VM with NVIDIA GPU passthrough on QEMU, and OpenHands and LLM Sandbox use containers.](https://www.nodus-compute.ai/blog-charts/open-source-ai-agent-sandboxes/projects.svg) *Only Kata Containers documents a GPU path; the agent-focused microVM projects are CPU-only on paper.* We left Daytona out of the table on purpose. Its repository is public under AGPL-3.0, but the README now says it is no longer maintained; more on that below. ## How much isolation does agent code actually need? Treat any code a model wrote after reading outside input as untrusted, and put a kernel boundary around it. A prompt-injected README or web page can steer the model into writing code that probes its environment, and the sandbox is what decides how far that code gets. Containers share one kernel. Docker’s [security docs](https://docs.docker.com/engine/security/) describe its isolation as kernel namespaces and control groups on the host, so a kernel bug reachable from inside a container is a bug in the host itself. Nodus says the same about its own development nodes in the [Sandbox isolation](https://www.nodus-compute.ai/docs/concepts/sandboxes-isolation/) docs: plain containers share the host’s Linux kernel and are for trusted code only. MicroVMs move that line. E2B Runtime starts one Firecracker microVM per sandbox, in its own cgroup and network namespace, with a per-sandbox nftables egress firewall. microsandbox and Kata Containers also give each workload its own guest kernel. Our rule: containers for code your own team wrote and reviewed, such as CI jobs or a fixed tool; a microVM or a user-space kernel for anything a model generated. The network and credential side matters as much as the kernel, and we cover it in [How do you sandbox an AI agent?](https://www.nodus-compute.ai/blog/how-to-sandbox-an-ai-agent/). ## Which project fits which agent? Pick by how much you want to build yourself. E2B Runtime is the closest to a finished product, Firecracker is the furthest. E2B Runtime is the full backend behind E2B’s cloud, released under Apache-2.0. Its README lists pause and resume with memory and disk, and forking a running sandbox into up to a hundred copies per request. It also gives every open port a URL and supports domain allow and deny lists. The [Embed](https://github.com/e2b-dev/runtime/blob/main/embed/README.md) package runs the whole stack on one Linux host with KVM through `docker compose up -d --wait`. Embed is one machine by design; for more than one node, the README points to E2B’s enterprise deployment. microsandbox is a library, not a service. You spawn microVMs from your own code with no server and no long-running daemon, on Linux with KVM, Apple Silicon Macs or Windows with WHP. It runs standard OCI images, ships an MCP server so agents can create their own sandboxes, and keeps secret keys outside the VM. The README warns that it is still beta software with breaking changes. Kata Containers suits platform teams that already run Kubernetes. It plugs in as a containerd runtime, so each pod gets a lightweight VM while still looking like a container to the cluster. You still build the agent-facing parts yourself: an exec and file API, idle stops and egress policy. Firecracker is the virtual machine monitor underneath E2B Runtime. It gives you microVMs on KVM and nothing else, so choose it only if you plan to write your own orchestrator. The OpenHands agent server fits agents already built on the OpenHands SDK. Its `DockerWorkspace` starts a container with the agent server inside and removes it when the work ends, and an Apptainer variant runs rootless on shared HPC machines. LLM Sandbox is a Python code-interpreter library with swappable backends. Use it when you want one API over Docker today and Bubblewrap or NsJail later, without a daemon on Linux hosts. ## What happened to Daytona’s open-source repository? Daytona’s open-source repository is frozen. Its [README](https://github.com/daytonaio/daytona) says that as of June 2026 core development moved to a private codebase, and the repository will get no further updates, fixes or releases. The code stays public and usable under the [AGPL-3.0 license](https://github.com/daytonaio/daytona/blob/v0.190.0/LICENSE), as is and without support. A fork of the last release can still work, but you own every security patch from here on. That is a poor trade for a component whose whole job is containing hostile code. Daytona’s managed service continues, and we compare it with Nodus in [Nodus vs Daytona](https://www.nodus-compute.ai/blog/nodus-vs-daytona/). ## Do any open-source agent sandboxes support GPUs? Kata Containers is the only project here that documents a GPU path. Its [GPU guide](https://github.com/kata-containers/kata-containers/blob/main/docs/use-cases/GPU-passthrough-and-Kata.md) covers passing NVIDIA GPUs into the VM, and its hypervisor table marks GPU support for QEMU only, not for Firecracker or Cloud Hypervisor. The E2B Runtime, microsandbox and LLM Sandbox READMEs do not mention GPUs. So if your agent needs CUDA inside a self-hosted microVM, the GPU passthrough work is yours. Nodus Sandboxes can request a GPU, and the [Sandboxes guide](https://www.nodus-compute.ai/docs/guides/sandboxes/) says they run on a dedicated on-demand machine, never spot or preemptible. [GPU sandboxes for AI agents](https://www.nodus-compute.ai/blog/gpu-sandboxes-for-ai-agents/) covers that case in detail. ## When is self-hosting worth it, and when is managed cheaper? Self-host when the requirement is about where the code runs, not about price. That means data that cannot leave your machines or a customer’s environment, which is the use E2B describes for Embed, or a product that ships sandboxes inside itself. It also fits if you already run Kubernetes with a platform team that can own Kata. For everything else, compare the managed bill with what running the fleet costs you. We priced the same workload on the [Nodus pricing page](https://www.nodus-compute.ai/pricing/): agents working 8 hours a day, 22 days a month, each in a 2 vCPU, 4 GiB sandbox at $0.0357/hr. * 10 agents: 10 x 8 x 22 = 1,760 hours, or $62.83 a month. * 50 agents: 8,800 hours, or $314.16 a month. * 200 agents: 35,200 hours, or $1,256.64 a month. Prices checked November 12, 2026, CPU and memory with included disk, no other fees. ![Monthly managed cost for agents running 8 hours a day, 22 days a month, in a 2 vCPU, 4 GiB Nodus sandbox at $0.0357/hr: 10 agents $62.83, 50 agents $314.16, 200 agents $1,256.64.](https://www.nodus-compute.ai/blog-charts/open-source-ai-agent-sandboxes/managed-cost.svg) *Managed cost grows in a straight line with agent count; 200 full-time agents come to $1,256.64 a month at list price.* Set that against the self-hosted side. You need hosts with KVM, a patch schedule for host and guest kernels, an egress firewall you trust, image builds and an API your agents can call. None of the six projects removes that work; E2B Runtime removes the most of it. If the monthly figure for your agent count is smaller than the time your team would spend on that list, managed wins. ## Where does Nodus fit next to these projects? Nodus is the option for teams that want a kernel boundary around agent code without operating one. Production CPU Sandboxes use a user-space kernel that passes only a filtered set of system calls to the host. Each sandbox gets its own network namespace with a default-deny firewall. A cgroup caps it at the CPU and memory you asked for and 256 processes, and commands run as a non-root user with no Linux capabilities. Machines are packed per organization, and an empty machine is destroyed after 10 minutes rather than handed to another organization. Lifecycle limits are part of the spec. A sandbox stops after 5 idle minutes by default, `maxLifetime` goes up to 720 hours, and `maxCostUSD` stops it once it has cost that much. The smallest real start, copied from the [Python Sandboxes guide](https://www.nodus-compute.ai/docs/guides/python/sandboxes/): Terminal window ```sh pip install nodus-compute nodus login ``` ```python import nodus sb = nodus.Sandbox.create( cpu=1, memory="2Gi", idle_timeout="5m", max_cost=1, ) try: p = sb.exec("python", "-c", "print(6 * 7)") print("stdout:", p.stdout.read().strip(), "exit:", p.wait()) finally: sb.terminate() ``` ## Where are the open-source options the better choice? Open source wins whenever you need to own the whole stack. With E2B Runtime or Kata you can read every line between the agent and the hardware, run it in an air-gapped network, and never depend on a vendor’s roadmap. E2B Runtime is better if your agent relies on forking a running sandbox or pausing with memory intact. On Nodus a stop keeps files but not processes, and CPU memory pause is still in Beta. microsandbox is better for sandboxes on a developer’s laptop, since it runs on Apple Silicon without a server. Kata is better if your GPU workloads must stay on your own cluster. ## FAQ ### Can I run E2B’s open-source runtime on a Mac? Not directly. E2B Runtime needs Linux with KVM, so on a Mac you would need a Linux VM with nested virtualization. microsandbox lists Apple Silicon macOS as a supported host. ### Which licenses allow embedding a sandbox in a commercial product? E2B Runtime, microsandbox, Kata Containers and Firecracker use Apache-2.0, and OpenHands and LLM Sandbox use MIT, both permissive licenses. Daytona’s archived code is AGPL-3.0, which adds obligations when you modify it and offer it over a network, so check with your own counsel before shipping it. ### Do open-source agent sandboxes come with an MCP server? microsandbox ships an MCP server so agents can create and drive their own sandboxes. Nodus runs a hosted MCP server at `https://api-next.nodus-compute.ai/mcp`, and resource creation through it requires an accepted dry run first. ### Is Nodus open source? No. Nodus Sandboxes are a managed service you drive from the CLI, Python SDK, REST API or MCP server. Billing is prepaid, and the hourly price is quoted before a sandbox is created.