Tunnels, the doorman and what is public
A paired server has no public address. A private tunnel slot reaches it, the doorman fronts every sandbox, and only a preview's random label is public.
Is a self-hosted sandbox server exposed to the internet? No. Once paired, a server has no public address at all. It keeps listening on 127.0.0.1:8090, runs one outbound tunnel with no ingress and no DNS record, and is reached only over Isolation Cloud's own network binding for the tunnel slot it was assigned. The runtime underneath is loopback-only, the doorman is the single thing in front of any sandbox, and the only deliberately public surface is a preview's random label.
A private tunnel, addressed by slot
At pairing, Isolation Cloud claims a free slot from a pool of pre-minted tunnels and hands the server that tunnel's credential. The server runs it with cloudflared over QUIC, the credential in the process environment rather than on the command line, and reconnects with backoff if the connection drops. The tunnel has no public hostname and no ingress rule: nothing on the internet resolves to it. On the cloud side, each slot is a network binding the Worker can dial, and every server behind a tunnel is plain 127.0.0.1:8090, because only one server is ever behind a given tunnel. The binding is the selector; there is no per-server IP.
Every request the Worker sends this way carries the server's master token, which the Worker holds encrypted and the browser never sees. When a server is removed, the slot is rotated, disconnected and verified empty before it returns to the pool, so a recycled slot can never deliver one organization's traffic to another's machine. On the server side, isolation-server disconnect or three rejected heartbeats drop the tunnel and the preview configuration together.
Loopback-only underneath
isolation-server binds 127.0.0.1:8090 and accepts a bearer token or a loopback origin, nothing else. The OpenSandbox lifecycle server it drives binds loopback too, with an API key minted at install. That matters because the runtime's per-sandbox proxy route has no authentication of its own: anything that could reach it could reach any port in any sandbox. Nothing can, because the doorman fronts everything.
The doorman
The doorman is isolation-server's data plane: one origin for every view of every sandbox, at /v/<viewId>/*, WebSocket-capable, so terminals, the editor, file transfers and agent conversations all ride it. A browser cannot put an authorization header on an iframe or a WebSocket handshake, so the doorman accepts a view token in the URL and promotes it to a cookie scoped to that view's path. View tokens are minted per view, signed by the server, and live for one hour. A token for one view opens nothing else, and nothing a sandbox could invent passes the check.
Views are served from a different origin than the app itself, so a page rendered inside a sandbox, an agent's output included, cannot read the app's session or call its API. What each view is made of is in views: terminal, editor, display, agent.
Previews are public by design
A display of kind web or api is different. It exists so someone else can open the app you are building, so it gets a public label, <slug>.isolation.cc, routed by hostname so the app sits at / and its absolute asset URLs resolve. The label is twenty characters: a ten-character prefix naming the server's slot and a ten-character random suffix. The suffix is the access secret, fifty bits of it, minted when the view is created and shown by /share. There is no login in front of a preview: whoever has the link can open it, and nobody can enumerate one. An unknown label is a 404, and a slot recycled to another server answers old labels with a 404 too. On a server that is not paired, the same view is <slug>.localhost, reachable only from a browser on that machine. Sharing rules are in yours by default, and sharing a preview.
The preview plane claims its hostnames whole: the token-gated API and the /v/ views are never reachable there, and the server strips its own credentials from anything that crosses onto it.
What can be reached from the internet
| Surface | Reachable from the internet? | Who gets in |
|---|---|---|
isolation-server, 127.0.0.1:8090 | No. No public address, no ingress, no DNS | Isolation Cloud, over the slot's binding, with the master token |
| OpenSandbox lifecycle server | No. Loopback only | isolation-server, with the runtime API key |
| A sandbox's ports | No. Only through the doorman | Whoever holds a valid view token for that view |
A view, /v/<viewId>/* | Through the view's own origin | A member who opened it, for one hour per token |
A preview, <slug>.isolation.cc | Yes | Anyone with the link; the random suffix is the secret |
ssh, ssh <session>.isolation through the CLI | HTTPS to Isolation Cloud, then the session's Doorman | The member's sign-in, per view |
| The server's own log | No | Owners and admins, with /server-logs |
The ssh path goes through the isolation CLI: isolation ssh-proxy carries the stream over HTTPS to Isolation Cloud and on to the session's own Doorman, the same way a terminal view reaches it, so no ssh port is needed on your side and the member's sign-in decides who gets in. The host always comes from /connect or "Open externally", never from the server's address. How it all fits together is in Architecture: powered by OpenSandbox; pairing a machine is three commands in Connected Servers: install and pair.
Questions
Do I need to open a port in my firewall?
No. The server makes one outbound tunnel connection and nothing dials in. There is no ingress, no DNS record and no port forward.
Can someone who knows my server's name reach it?
No. A server has no name to know. Isolation Cloud reaches it through a network binding tied to the tunnel it was assigned, and only after checking the caller's session and role.
Are previews public?
Yes, on purpose. A display of kind web or api gets a label under isolation.cc whose random suffix is the access secret. Anyone with the link can open it; nobody can guess it.