{"slug": "opendsec-self-hosted-sandboxes-for-rl-rollouts-and-code-running-agents", "title": "OpenDsec: self-hosted sandboxes for RL rollouts and code-running agents", "summary": "A developer at Kernflux built OpenDsec, an AGPL-licensed self-hosted sandbox platform for agentic reinforcement-learning rollouts and code-running agents, modeled on DeepSeek's DSec paper. It runs Firecracker microVMs with memory snapshots, boots a sandbox in about 0.16 seconds, and forks a running environment into four memory-inclusive copies in roughly 0.1 seconds on XFS. The project is independent of DeepSeek and swaps the paper's eBPF networking for nftables and a DNS proxy, and 3FS for any shared filesystem.", "body_md": "If you train a model with agentic reinforcement learning, every rollout needs somewhere to run code: install a package, run the tests, hit the network, write files. Thousands of those run at once. When the training job is preempted they all have to stop together and come back later. And when you want to explore one state several ways, you want copies of the environment as it is right now, memory included, not fresh ones from the image.\n\nHosted sandbox services cover part of this. We wanted all of it on our own machines, so we built [OpenDsec](https://github.com/Kernflux/opendsec) and published it under the AGPL.\n\nThis is the first post in a series about it. Here: what it does, what it looks like to run, and where its limits are.\n\nThat is a real recording on one bare-metal server: the install script, then a short Python program that creates a Firecracker microVM, runs `print(6*7)` in it and forks it into four copies. The six minutes of building and installing are cut; everything after runs at real speed. The 0.16 s is the whole API call (placement, boot, the in-VM agent ready), measured from the client.\n\nThe program is the whole client side:\n\n``` python\nimport asyncio, time\nfrom opendsec import DSecClient, DSecRunArgs\n\nasync def main():\n    async with DSecClient() as client:\n        t = time.perf_counter()\n        sb = await client.run_sandbox(DSecRunArgs(backend=\"microvm\", image=\"root/py:3.12\"))\n        print(f\"ready in {time.perf_counter() - t:.2f}s (whole API call: placement + boot)\")\n        print((await sb.run_shell(\"python3 -c 'print(6*7)'\")).stdout.strip())\n        t = time.perf_counter()\n        forks = await sb.fork(count=4)    # copies with memory\n        print(f\"forked 4 in {time.perf_counter() - t:.2f}s\")\n        await asyncio.gather(*(s.stop() for s in [sb, *forks]))\n\nasyncio.run(main())\n```\n\nDeepSeek described the sandbox platform behind their agentic RL training in [*DeepSeek Elastic Compute (DSec)*](https://arxiv.org/abs/2609.22978). OpenDsec follows that paper: a stateless apiserver, IAM with nested projects and quotas, a watcher that aggregates scheduling state, power-of-k placement where each node has the final say on admission, layered images loaded on demand, a default-deny network policy, and pausing a whole task at once.\n\nWhere the paper leaves things open, or where we chose differently, the decisions are ours: nftables and a DNS proxy instead of eBPF for the network policy, any shared file system (NFS, CephFS, JuiceFS) instead of 3FS for images, and Firecracker with memory snapshots as the main backend. The [design document](https://github.com/Kernflux/opendsec/blob/main/docs/SPEC.md) marks every point as either from the paper or our own.\n\nOpenDsec is an independent project. It is not affiliated with DeepSeek and contains none of its code.\n\n`fork(count=N)` pauses the source for about 10 ms and gives you N copies with the same processes, imports and open ports. On one node the copies share memory pages; on another node they pull the snapshot from the source node directly.`E2B_API_URL`, `E2B_SANDBOX_URL`, `E2B_API_KEY`). E2B's own Python and JS SDK checks pass.\nAll numbers are our own measurements on our bare-metal machines; the design document says how each was measured. Your hardware will give different ones. For example, the fork time depends on the file system under the sandbox state: 0.1 s on XFS, which copies memory files by reflink, and about 1 s on ext4, which has to copy them.\n\nYou need a Linux x86_64 machine with systemd and cgroup v2 (we test on Ubuntu 24.04). MicroVMs also need `/dev/kvm`, so use bare metal or a cloud VM with nested virtualization; without it you get containers only.\n\n```\nsudo -i\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 checks the machine, builds everything, downloads Firecracker and the guest kernel (checked against pinned hashes), installs the components as systemd services with their own CA, imports `python:3.12` from Docker Hub, and runs one container and one microVM as a check. Then:\n\n```\npython3 -m venv .venv && .venv/bin/pip install ./sdk/python\n. /root/opendsec-ops/demo.env\n.venv/bin/python sdk/python/examples/quickstart.py\n```\n\n`deploy/quickstart.sh --uninstall` removes all of it again.\n\nThe servers are AGPL-3.0. The Python SDK, the Go client and the API definitions are Apache-2.0, so programs that only call OpenDsec are not bound by the AGPL. A commercial license is available for closed modifications.\n\nFirecracker, gVisor and containers compared for running AI-generated code: isolation, start time, memory and compatibility, with measurements.\n\nThe code is at [github.com/Kernflux/opendsec](https://github.com/Kernflux/opendsec), the docs at [kernflux.github.io](https://kernflux.github.io/en/docs/). Issues and questions are welcome there or in the comments.", "url": "https://wpnews.pro/news/opendsec-self-hosted-sandboxes-for-rl-rollouts-and-code-running-agents", "canonical_source": "https://dev.to/kernflux/opendsec-self-hosted-sandboxes-for-rl-rollouts-and-code-running-agents-g", "published_at": "2026-10-31 04:39:47+00:00", "updated_at": "2026-10-31 04:49:23.930682+00:00", "lang": "en", "topics": ["ai-infrastructure", "ai-agents", "mlops", "developer-tools", "ai-tools"], "entities": ["OpenDsec", "Kernflux", "DeepSeek", "Firecracker", "DSec", "E2B", "Ubuntu"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/opendsec-self-hosted-sandboxes-for-rl-rollouts-and-code-running-agents", "markdown": "https://wpnews.pro/news/opendsec-self-hosted-sandboxes-for-rl-rollouts-and-code-running-agents.md", "text": "https://wpnews.pro/news/opendsec-self-hosted-sandboxes-for-rl-rollouts-and-code-running-agents.txt", "jsonld": "https://wpnews.pro/news/opendsec-self-hosted-sandboxes-for-rl-rollouts-and-code-running-agents.jsonld"}}