{"slug": "self-hosting-e2b-run-e2b-code-sandboxes-on-your-own-servers", "title": "Self-hosting E2B: run E2B code sandboxes on your own servers", "summary": "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.", "body_md": "[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.\n\nThe short version. There are two ways to self-host E2B:\n\nThis 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.\n\nYou 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.\n\n```\nsudo -i                                    # the rest runs as root\napt update && apt install -y make git python3-venv\ncurl -fsSL https://go.dev/dl/go1.27.3.linux-amd64.tar.gz | tar -C /usr/local -xz\ngit clone https://github.com/kernflux/opendsec && cd opendsec\ndeploy/quickstart.sh\n```\n\nThe 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.\n\nThe install writes `/root/opendsec-ops/demo.env`, which already holds the three variables the E2B SDK reads:\n\n```\n. /root/opendsec-ops/demo.env       # sets E2B_API_URL, E2B_SANDBOX_URL, E2B_API_KEY\npython3 -m venv .venv && .venv/bin/pip install e2b\n```\n\n`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`):\n\n``` python\nfrom e2b import Sandbox\n\nsbx = Sandbox.create()                          # template \"base\"\nprint(sbx.commands.run(\"python3 -V\").stdout)\nsbx.files.write(\"/tmp/a.txt\", \"hello\")\nprint(sbx.files.read(\"/tmp/a.txt\"))\nsbx.kill()\n```\n\nTo call it from another machine, point the three variables at this machine:\n\n```\nexport E2B_API_URL=http://<gateway>:7400\nexport E2B_SANDBOX_URL=http://<gateway>:7400\nexport E2B_API_KEY=e2b_$(printf %s \"$OPENDSEC_TOKEN\" | od -An -tx1 -v | tr -d ' \\n')   # your OpenDsec token\n```\n\nThe JS/TS SDK works too (Node.js 22.19 or newer).\n\nOn microVMs, fork, snapshots and pause all keep **memory**, so running processes carry on:\n\n``` python\nfrom e2b import Sandbox\n\nsrc = Sandbox.create(timeout=300)\nsrc.files.write(\"/tmp/state\", \"v1\")\n\nforks = src.fork(count=2)                       # two copies of the running sandbox\nsnap = src.create_snapshot()                    # a snapshot\nagain = Sandbox.create(snap.snapshot_id)        # a sandbox from the snapshot\n\n# Pause instead of ending at the timeout; connect resumes\ns = Sandbox.create(timeout=60, lifecycle={\"on_timeout\": \"pause\", \"auto_resume\": True})\ns2 = Sandbox.connect(s.sandbox_id)\n\nfor x in [src, *forks, again, s2]:\n    x.kill()\n```\n\nForks suit an agent's tree search, or fanning out many RL rollouts from one prepared environment.\n\nE2B'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.\n\nThe build installs packages inside the sandbox, so the machine needs access to apt mirrors and PyPI. Still in the `opendsec` directory:\n\n```\ncurl -fsSL https://codeload.github.com/e2b-dev/code-interpreter/tar.gz/refs/heads/main | tar -xz\n. /root/opendsec-ops/env                        # the admin token: publishing into the root project\n.venv/bin/pip install ./sdk/python\n.venv/bin/python deploy/e2b/build-code-interpreter.py code-interpreter-main/template\n```\n\nThat builds the image `root/code-interpreter:v1`. Add a template for it under `e2b.templates` in `/root/opendsec-ops/opendsec.json`:\n\n```\n\"code-interpreter-v1\": {\"image\": \"root/code-interpreter:v1\", \"backend\": \"microvm\", \"cpu\": 2, \"memory_mb\": 2048}\n```\n\nPush the config and restart:\n\n```\nexport OPENDSEC_OPS=/root/opendsec-ops\ndeploy/prod/opendsecops push-config all && deploy/prod/opendsecops restart\n```\n\nCallers then install `e2b-code-interpreter` and use it:\n\n``` python\nfrom e2b_code_interpreter import Sandbox\n\nsbx = Sandbox.create(\"code-interpreter-v1\")\nprint(sbx.run_code(\"6 * 7\").text)               # 42\n```\n\nMeasured on 2026-10-23 on the project's bare-metal test machines (AMD EPYC 9Y24), through the gateway, on Firecracker microVMs:\n\n| Operation | Time | \n|---|---|\n| `Sandbox.create()` , template`base` (2 vCPU, 1 GB, cold start) | p50 166 ms | \n| First command after create | p50 12 ms | \n| `Sandbox.create(\"code-interpreter-v1\")` (2 GB memory snapshot) | about 250 ms | \n| First `run_code` | about 40 ms | \n| `fork(count=2)` | about 100–150 ms | \n| `create_snapshot()` | about 40–70 ms | \n| `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) | \n\nIf 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:\n\n`e2b` section, list the gateways' addresses, the project sandboxes go into, and the templates.`e2b=<index>`.`/readyz`.\nThe 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.\n\nThe full list is in [E2B compatibility](https://kernflux.github.io/en/docs/e2b). The main points:\n\n|  | E2B | OpenDsec gateway | \n|---|---|---|\n| Templates | Built with E2B's template build | An admin maps template names to OpenDsec images in the config; no template build API | \n| Sandbox ports | Can be public | Need the token (the SDK sends it) | \n| Filesystem-only pause | Supported | Refused (400): pause always keeps memory | \n| Filesystem-only snapshots | Supported | Refused (400) on microVMs; container snapshots are filesystem-only anyway | \n| Code interpreter languages | Python, JavaScript, R, Java, Bash | Python | \n| Not supported |  | Directory watching, signed file URLs, MCP, volumes | \n\nOptions the gateway cannot honour return 400 instead of being ignored, so a program never runs without a setting it asked for.\n\nMore in [OpenDsec compared with E2B, Daytona and Modal](https://kernflux.github.io/en/docs/compare).\n\nYes. 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.\n\nNo. 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.\n\nYes. 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.\n\nYes. 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.\n\nYes. 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).\n\nOpenDsec is free, open-source software (server AGPL-3.0, SDKs Apache-2.0); you only need your own machines.\n\n*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.*", "url": "https://wpnews.pro/news/self-hosting-e2b-run-e2b-code-sandboxes-on-your-own-servers", "canonical_source": "https://dev.to/kernflux/self-hosting-e2b-run-e2b-code-sandboxes-on-your-own-servers-3675", "published_at": "2026-11-02 07:19:08+00:00", "updated_at": "2026-11-02 07:22:48.433031+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "ai-infrastructure", "developer-tools", "mlops"], "entities": ["E2B", "OpenDsec", "Firecracker", "Ubuntu", "Python", "Node.js"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/self-hosting-e2b-run-e2b-code-sandboxes-on-your-own-servers", "markdown": "https://wpnews.pro/news/self-hosting-e2b-run-e2b-code-sandboxes-on-your-own-servers.md", "text": "https://wpnews.pro/news/self-hosting-e2b-run-e2b-code-sandboxes-on-your-own-servers.txt", "jsonld": "https://wpnews.pro/news/self-hosting-e2b-run-e2b-code-sandboxes-on-your-own-servers.jsonld"}}