OpenDsec

Self-hosted sandboxes for AI agents and reinforcement-learning rollouts: Firecracker microVMs, containers and full VMs behind one API, with memory-preserving fork and an E2B-compatible gateway.

Source code Website and docs Quickstart The DSec paper

OpenDsec is an independent implementation of the architecture described in DeepSeek Elastic Compute (DSec): A Sandbox Infrastructure for Effective Agentic Training at Scale (arXiv:2609.22978). It is not DeepSeek code, not an official release, and not affiliated with or endorsed by that paper's authors.

What it is

OpenDsec runs many isolated sandboxes on your own Linux machines, from a single host to a cluster, for reinforcement-learning rollouts and agents that execute code. It ships a Python SDK, a CLI, and an API compatible with E2B's SDKs, under AGPL-3.0.

Good fit: teams whose sandboxes must stay in their own data centre or an offline network; RL training that starts thousands of environments at once; workflows that need to fork a running environment with its memory; keeping existing E2B SDK code but moving it onto your own infrastructure.
Poor fit: anyone who wants a managed service with no machines to operate (there is no hosted edition), or non-x86_64 Linux hosts.

Architecture

A stateless apiserver handles authentication, quota and placement, choosing nodes from the state a watcher aggregates.
IAM keeps identities, projects and quotas in a Raft-replicated store.
Each compute node runs an edge that makes the final admission decision against its real resources.
Aether runs inside every sandbox for the runtime channel; Chronus keeps persistent shell sessions. Exec, files, HTTP, processes and PTY share one runtime API.
Components talk over gRPC with mTLS, and the sandbox id encodes its edge, so no per-sandbox routing table is needed. Any component can restart without disturbing running sandboxes.

Lifecycle

A microVM can be paused into a memory snapshot, restored, or forked while running. Copies on the same node share memory pages; a fork on another node pulls the snapshot from the source. A sandbox can also be packed back into a new image from its changes.

import asyncio
from opendsec import DSecClient, DSecRunArgs

async def main():
    async with DSecClient() as client:
        sb = await client.run_sandbox(DSecRunArgs(
            backend="microvm", image="root/py:3.12",
            cpu_cores_limit=1, memory_limit_mb=1024,
            network_rules={"pypi": True}))   # outbound denied unless allowed
        try:
            print((await sb.run_shell("python3 -c 'print(6*7)'")).stdout)
            forks = await sb.fork(count=4)   # four copies, memory included
            for f in forks:
                await f.stop()
        finally:
            await sb.stop()

asyncio.run(main())

Measured on our hardware

These are measurements of OpenDsec on its own machines, not figures from the paper. Method and conditions are in docs/SPEC.md.

Measurement	Value
microVM cold start	~0.1 s
Restore from memory snapshot	~55 ms
Resume after pause	~50 ms
Source VM stall during fork	~10 ms
Burst of microVMs, one 384-thread node	5,120
Burst of containers, two nodes	8,192, no failures

Where it differs from the paper

The network policy is enforced with nftables and a DNS proxy rather than eBPF.
Images live on any shared filesystem (NFS, CephFS, JuiceFS) instead of 3FS.
Firecracker is the primary backend rather than one option among several.

Where the paper leaves a decision open, docs/SPEC.md marks each point as either taken from the paper, with its section, or the project's own decision.

Known limits

The image store's availability is whatever the chosen shared filesystem provides.
A host reboot loses that node's sandboxes, paused microVMs included.
QEMU PCI passthrough has not been tested on real devices.
The E2B gateway does not yet cover directory watching, signed file URLs, unauthenticated browser access to sandbox ports, or template building.

Try it

One Linux x86_64 machine with systemd and cgroup v2 is enough. MicroVMs need /dev/kvm; without it the script sets up containers only.

git clone https://github.com/Kernflux/opendsec
cd opendsec
deploy/quickstart.sh        # or --no-microvm for containers only

Existing E2B programs need only three environment variables pointed at the gateway:

export E2B_API_URL=https://sandbox.internal:7400
export E2B_SANDBOX_URL=https://sandbox.internal:7400
export E2B_API_KEY=dsk.…

Licensing

The server and tools are AGPL-3.0. The client parts (the Python SDK, the Go client, and the API definitions) are Apache-2.0, so programs using OpenDsec are not bound by the AGPL.