Self-hosted AI sandbox options: running an E2B alternative yourself

01What does self-hosting an AI sandbox actually mean?

A cloud code-interpreter sandbox gives an agent a fresh machine to run code in, reached over an API, on someone else's servers. Self-hosting moves that machine onto hardware you control: a laptop, a server in your rack, or a cluster in your own cloud account. Teams usually want this for one of three reasons: data that may not leave the network, an air-gapped or regulated environment, or cost and latency at high volume.

Three questions sort the options better than any feature list. Where does it run: one developer's machine, one Linux host, or a cluster? What is the boundary: a shared host kernel with a syscall filter, a user-space kernel like gVisor, or a hardware-virtualized microVM with its own kernel? And what do you have to operate: a single binary, a compose file, or a control plane, image builder and object storage? The sections below answer those three for each option, using each project's own documentation.

• E2B Embed: one Linux host with KVM; Firecracker microVMs; you run the whole stack.
• Daytona (archived repo): wherever you deploy your fork; AGPL-3.0; no upstream fixes.
• microsandbox: a developer machine on Linux, macOS or Windows; local microVMs; a library or CLI.
• Kubernetes agent-sandbox: your cluster; gVisor or Kata via RuntimeClass; cluster operations.
• Docker Sandboxes: a developer machine; microVMs with a host-side proxy; the sbx CLI.
• kosa8: an Apple-chip Mac or x86-64 Linux machine; microVMs with their own kernel; one install.

02Can you self-host E2B?

Yes. E2B publishes its backend as E2B Runtime, Apache-2.0 licensed, and describes it as the same code that serves its public cloud, dedicated enterprise deployments and a single-machine package called Embed. The runtime gives each sandbox one Firecracker microVM in its own cgroup and network namespace, with a per-sandbox nftables egress firewall and domain allow and deny lists that inspect SNI and the Host header. Sandboxes boot from snapshots, can be paused and resumed, and a running sandbox can be forked.

Embed is the whole stack on one Linux host with KVM, started from a compose file. E2B also ships it as Terraform for GCP, AWS and Azure and as a Kubernetes manifest, and says Embed is one machine by design; for multi-node production it offers a dedicated deployment inside your own cloud account. The ops burden is real but bounded: a KVM-capable Linux host, the compose stack, templates you build, and upgrades you apply. Because Firecracker needs KVM, Embed does not run natively on a Mac.

03What happened to self-hosting Daytona?

Daytona's public repository now opens with a notice: as of June 2026 core development moved to a private codebase, and the repository will receive no further updates, fixes or releases. It stays public and usable under its licence, which is the GNU Affero General Public License version 3, as is and without support. That is why searches for a Daytona alternative now often mean either a community fork of that AGPL-3.0 code or a different project.

Running a fork is a legitimate choice, but it changes the ops picture. Security fixes become your job or your fork's maintainers' job. And AGPL-3.0 has a network clause: if you modify the program and let users interact with it over a network, you must offer them the corresponding source. Check that with whoever handles licensing before building a product on it. Daytona's hosted service continues separately; this section is only about the self-hosted code.

04Local microVM runtimes: microsandbox and Docker Sandboxes

microsandbox, Apache-2.0 licensed, runs untrusted workloads in local microVMs on Linux, macOS and Windows. It runs standard OCI images, can fork live sandboxes and save and restore running state, and is embeddable: its README says you can spawn VMs from your own code with no setup server and no long-running daemon. It also lists secrets that never enter the VM. The ops burden is close to that of a library, and the boundary is a hardware-virtualized machine per sandbox.

Docker Sandboxes run coding agents through the sbx CLI, either locally or on Docker-managed cloud compute. Docker's architecture page describes each local sandbox as a microVM with hypervisor isolation and its own Docker daemon, image cache and packages. All outbound TCP goes through a proxy on the host, and the agent sees a sentinel in place of the real API credential, which the proxy swaps in after the request leaves the VM. Docker states the CLI and local sandboxes are free to use, including commercially, while central admin policy management needs a separate paid subscription.

Both suit a developer or a small team on their own machines. Neither is a multi-tenant server you point a fleet of agents at, which is where E2B Embed or Kubernetes fit better.

05Self-hosting on Kubernetes: agent-sandbox with gVisor or Kata

If you already run Kubernetes, agent-sandbox is a Kubernetes SIG Apps project, Apache-2.0 licensed, that adds a Sandbox custom resource and controller for long-running, stateful, single-pod workloads with a stable identity and persistent storage. Extensions add SandboxTemplate, SandboxClaim and SandboxWarmPool for pre-warmed pools. Its README is explicit about scope: it is a sandbox orchestrator and delegates isolation to a runtime such as gVisor or Kata Containers, chosen through RuntimeClass.

So the boundary depends on the runtime you install. gVisor describes itself as an application kernel, neither a syscall filter nor a VM in the everyday sense, that gives many of a VM's security benefits with a smaller footprint. Kata Containers builds lightweight virtual machines that plug into the container ecosystem, using hardware virtualization as a second layer of defence, so its nodes need virtualization support. The ops burden is the highest here: a cluster, node pools configured for the runtime, network policy for egress, and the controller itself. The pay-off is scale and the scheduling, quotas and audit you already have.

06How to choose a self-hosted sandbox

Start from where the agents run today, not from the feature table. If one developer runs a coding agent on a laptop, a local microVM runtime is the shortest path. If a service runs thousands of short code-interpreter calls, a server-side stack such as E2B Embed or a Kubernetes cluster is built for that. Then check the boundary and the secrets model, because those decide what a hijacked agent can reach.

Mixing is normal. A team can give developers a local sandbox for coding agents and run a server-side stack for the product's code-interpreter feature, as long as both answer the questions below the same way.

• Does it run on the hardware you have: macOS, Linux with KVM, Windows, or a cluster?
• Is the boundary a separate kernel per sandbox, or a shared host kernel with filtering?
• Is the network closed by default, and is egress decided outside the sandbox?
• Do API keys stay outside the sandbox, or are they copied in as environment variables?
• Is the code maintained upstream, and does its licence fit how you will ship it?
• Who will apply security updates, and how much of a control plane are you taking on?