Architecture: powered by OpenSandbox

How Isolation works under the hood comes down to three layers with one job each. Isolation Cloud is the control plane that knows who you are and what you own. isolation-server is a light layer on every machine that runs sessions. OpenSandbox is the runtime underneath that actually creates, runs, snapshots and destroys sandboxes. The same three layers serve a laptop paired as a Connected Server and a Cloud Server provisioned for you.

Isolation Cloud, the control plane

Isolation Cloud is a Cloudflare Worker with a database and object storage behind it. The database holds organizations, members, servers, workspaces, environments, agents and the action log. Object storage holds each workspace's file tree and its encrypted git bundles, which is why a server's disk can be wiped without losing anything. The website at isolation.cloud is a single-page app talking to that Worker; the MCP server at mcp.isolation.cloud and the chat apps (Slack, Teams, Linear, Jira, GitHub, Buzz) talk to the same Worker through the same catalog of actions. Whatever door a request comes through, the same role check runs and the same log line is written. What an external agent can do lists that catalog.

The Worker never talks to the runtime directly. It talks to isolation-server, over a private tunnel, with the server's own credential that the browser never sees.

isolation-server, the layer on the machine

isolation-server ships as one Docker image, ghcr.io/isolation-labs/server, installed with curl -fsSL isolation.cloud/server/install | sh and started with isolation-server up. It adds the few things a cloud-driven, browser-facing server needs and nothing else: pairing and the heartbeat, supervision of the private tunnel, the doorman that fronts every view, unsealing of launch secrets, launch orchestration (devcontainer-derived images, repo clones whose credentials never touch a command line, per-view processes), workspace persistence (git bundles pushed with compare-and-swap, end to end encrypted), and the agent supervisor. The runtime is inside the same image, pinned; how the install goes is in Connected Servers: install and pair.

Everything that can be a runtime call is one. isolation-server does not build images its own way, does not exec into containers its own way and does not snapshot its own way.

OpenSandbox, the runtime

OpenSandbox describes itself as a secure, fast and extensible sandbox runtime for AI agents. It is Apache 2.0, Python, and Isolation pins it at a fixed version through uv, unforked. Its lifecycle server creates and tears down sandboxes and takes snapshots, which is the primitive behind suspend and resume. Inside every sandbox runs its execution daemon, execd, which handles command execution, file upload and download, and a proxy to any port the app inside is listening on. Every view you open, a terminal, the code editor, the files mount, a web preview, an agent conversation, is isolation-server driving execd through that proxy.

Isolation runs OpenSandbox on its Docker runtime, bound to loopback with an API key minted at install. When the runtime lacks something Isolation needs, the gap is written up and proposed upstream as an enhancement proposal; it is never patched around locally. That keeps the runtime replaceable by the next pinned release and keeps the layer on top small.

Control plane and data plane

The split that matters for security is which bytes go where.

control plane (who, what, which server)

  browser ──HTTPS──▶ Isolation Cloud (Worker + database + object storage)
                          │  private tunnel, no public address
                          ▼
                    isolation-server on 127.0.0.1:8090
                          │
                          ▼
                    OpenSandbox lifecycle server (loopback only)

data plane (what a view shows)

  browser ──HTTPS──▶ preview origin (*.isolation.cc, no login cookie)
                          │  the same private tunnel, relayed, never stored
                          ▼
                    doorman  /v/<viewId>/*  ──▶ execd proxy ──▶ the sandbox
                    (view token, one hour)      (in-sandbox, port 44772)

The control plane is every decision: launching a session, adding a member, creating a server, reading the activity log. It goes browser to Worker, and Worker to server over the tunnel, bearing the server's master token that the Worker holds on the browser's behalf. The data plane is the content of a view: terminal output, the editor's buffers, a downloaded file, a preview's HTML. It goes from the browser to the server's doorman and into the sandbox, authorized by a short-lived token scoped to that one view. Because a paired server has no public address, those bytes ride the same private tunnel the control plane uses, relayed by Isolation Cloud and never stored; what keeps the two planes apart is the origin. Views and previews are served from the preview domain, never from the app origin that holds your login cookie, so a page running in a sandbox can never read your session. The doorman is also the only thing in front of the runtime, whose proxy route has no authentication of its own. Tunnels, the doorman and what is public walks through exactly what that leaves reachable.

Why the layers are cut this way

Each layer can be audited on its own. The runtime is an upstream project you can read and run without Isolation, and it is unmodified in the image. The per-machine layer is one image with one job, and what it may reach is plain to see: the Docker socket it is given, and the tunnel it dials out on. The control plane holds only metadata and encrypted workspace state, no sandbox bytes and no runtime, which is what makes nothing lives in the sandbox true.