Self-hosting E2B: run E2B code sandboxes on your own servers

A developer documented a self-hosted deployment of E2B, the code-execution sandbox used by AI agents, using an open-source project called OpenDsec that runs Firecracker microVMs on a single Linux x86_64 machine. The quickstart script installs an E2B-compatible gateway on port 7400 with a Python 3.12 template, letting the standard E2B Python and JS/TS SDKs connect unchanged, and the setup took about 11 minutes on a fresh 8-core VM. The writeup also covers memory-preserving fork, snapshot and pause features for agent tree search and RL rollouts, plus building E2B's code interpreter from its open-source server.

E2B https://e2b.dev is one of the most used code execution sandboxes for AI agents: the code an agent writes runs in an isolated Firecracker microVM, and many agent frameworks support E2B. But E2B is mainly a hosted cloud service, so your code and data go to E2B's cloud. When data must stay on your network, the network is air-gapped, or you run enough sandboxes that the hosted price stops making sense, you self-host. The short version. There are two ways to self-host E2B: This post walks through the second: a single-machine install, calling it with the E2B SDK, setting up the code interpreter, growing into a cluster, and how it differs from E2B. You need a Linux x86 64 machine tested on Ubuntu 24.04 with systemd and cgroup v2. For microVMs Firecracker, as in E2B you also need /dev/kvm : bare metal, or a cloud VM with nested virtualization. sudo -i the rest runs as root apt update && apt install -y make git python3-venv curl -fsSL https://go.dev/dl/go1.27.3.linux-amd64.tar.gz | tar -C /usr/local -xz git clone https://github.com/kernflux/opendsec && cd opendsec deploy/quickstart.sh The script builds the binaries, downloads Firecracker and the guest kernel, and installs every service, including the E2B gateway port 7400 with a template named base Python 3.12 . On a fresh 8-core VM the whole run took about 11 minutes, most of it building. The install writes /root/opendsec-ops/demo.env , which already holds the three variables the E2B SDK reads: . /root/opendsec-ops/demo.env sets E2B API URL, E2B SANDBOX URL, E2B API KEY python3 -m venv .venv && .venv/bin/pip install e2b E2B API KEY is the OpenDsec token written as e2b followed by its hex, the only form some versions of E2B's Python SDK 2.25 to 2.45 accept; the gateway decodes it back into the token. From here the code is exactly what you would write for E2B's cloud run it with .venv/bin/python : python from e2b import Sandbox sbx = Sandbox.create template "base" print sbx.commands.run "python3 -V" .stdout sbx.files.write "/tmp/a.txt", "hello" print sbx.files.read "/tmp/a.txt" sbx.kill To call it from another machine, point the three variables at this machine: export E2B API URL=http://<gateway :7400 export E2B SANDBOX URL=http://<gateway :7400 export E2B API KEY=e2b $ printf %s "$OPENDSEC TOKEN" | od -An -tx1 -v | tr -d ' \n' your OpenDsec token The JS/TS SDK works too Node.js 22.19 or newer . On microVMs, fork, snapshots and pause all keep memory , so running processes carry on: python from e2b import Sandbox src = Sandbox.create timeout=300 src.files.write "/tmp/state", "v1" forks = src.fork count=2 two copies of the running sandbox snap = src.create snapshot a snapshot again = Sandbox.create snap.snapshot id a sandbox from the snapshot Pause instead of ending at the timeout; connect resumes s = Sandbox.create timeout=60, lifecycle={"on timeout": "pause", "auto resume": True} s2 = Sandbox.connect s.sandbox id for x in src, forks, again, s2 : x.kill Forks suit an agent's tree search, or fanning out many RL rollouts from one prepared environment. E2B's code interpreter run code , with results, charts and pandas tables needs a template of its own. OpenDsec builds it from E2B's open-source code-interpreter server: a memory snapshot of a microVM already running that server and a Python Jupyter kernel, so a new sandbox runs code at once. The build installs packages inside the sandbox, so the machine needs access to apt mirrors and PyPI. Still in the opendsec directory: curl -fsSL https://codeload.github.com/e2b-dev/code-interpreter/tar.gz/refs/heads/main | tar -xz . /root/opendsec-ops/env the admin token: publishing into the root project .venv/bin/pip install ./sdk/python .venv/bin/python deploy/e2b/build-code-interpreter.py code-interpreter-main/template That builds the image root/code-interpreter:v1 . Add a template for it under e2b.templates in /root/opendsec-ops/opendsec.json : "code-interpreter-v1": {"image": "root/code-interpreter:v1", "backend": "microvm", "cpu": 2, "memory mb": 2048} Push the config and restart: export OPENDSEC OPS=/root/opendsec-ops deploy/prod/opendsecops push-config all && deploy/prod/opendsecops restart Callers then install e2b-code-interpreter and use it: python from e2b code interpreter import Sandbox sbx = Sandbox.create "code-interpreter-v1" print sbx.run code "6 7" .text 42 Measured on 2026-10-23 on the project's bare-metal test machines AMD EPYC 9Y24 , through the gateway, on Firecracker microVMs: | Operation | Time | |---|---| | Sandbox.create , template base 2 vCPU, 1 GB, cold start | p50 166 ms | | First command after create | p50 12 ms | | Sandbox.create "code-interpreter-v1" 2 GB memory snapshot | about 250 ms | | First run code | about 40 ms | | fork count=2 | about 100–150 ms | | create snapshot | about 40–70 ms | | Sandbox.create snapshot id | about 65–85 ms; about 0.6 s for the first one right after the snapshot it waits for the snapshot to be published to the image store | If one machine is enough, stop here. With more sandboxes, OpenDsec grows into a multi-machine cluster deployment docs https://kernflux.github.io/en/docs/cluster , and the E2B gateway into several replicas: e2b section, list the gateways' addresses, the project sandboxes go into, and the templates. e2b=<index . /readyz . The gateway keeps no state of its own and makes every call to OpenDsec with the caller's token, so permissions, quotas and audit records apply as usual. The full list is in E2B compatibility https://kernflux.github.io/en/docs/e2b . The main points: | | E2B | OpenDsec gateway | |---|---|---| | Templates | Built with E2B's template build | An admin maps template names to OpenDsec images in the config; no template build API | | Sandbox ports | Can be public | Need the token the SDK sends it | | Filesystem-only pause | Supported | Refused 400 : pause always keeps memory | | Filesystem-only snapshots | Supported | Refused 400 on microVMs; container snapshots are filesystem-only anyway | | Code interpreter languages | Python, JavaScript, R, Java, Bash | Python | | Not supported | | Directory watching, signed file URLs, MCP, volumes | Options the gateway cannot honour return 400 instead of being ignored, so a program never runs without a setting it asked for. More in OpenDsec compared with E2B, Daytona and Modal https://kernflux.github.io/en/docs/compare . Yes. E2B's runtime is open source Apache-2.0 and can be self-hosted on one machine; deploying into your own cloud account is an enterprise feature. Alternatively, OpenDsec's E2B gateway serves the API the E2B SDK calls on your own machine or cluster. No. Set E2B API URL , E2B SANDBOX URL and E2B API KEY to point the SDK at the gateway. Features the gateway lacks, such as directory watching, return a clear error. Yes. Build the template with deploy/e2b/build-code-interpreter.py and run code works, with results, logs, errors, charts and pandas tables. Only the Python kernel for now. Yes. Without /dev/kvm the install sets up containers only, and the gateway's base template uses the container backend. Fork and snapshots then keep only the file system, and the code interpreter template needs microVMs. Yes. OpenDsec has an offline bundle deploy/offline ; we tested installing it and using the E2B SDK on a VM with no internet access. See Install https://kernflux.github.io/en/docs/install . OpenDsec is free, open-source software server AGPL-3.0, SDKs Apache-2.0 ; you only need your own machines. OpenDsec is not affiliated with E2B; it implements the API the E2B SDK calls. What this post says about E2B comes from its documentation and repositories, checked on 2026-10-25.