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 web 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 web 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, the bastion connection 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. The files view adds one more credential: a stable mount password for native file clients, confined to that view's WebDAV path. What each view is made of is in views: terminal, code, files, web, agent.
Web previews are public by design
A web view 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 web 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 files view mount | Through the same origin, WebDAV | The view's mount password, scoped to that path |
A web preview, <slug>.isolation.cc | Yes | Anyone with the link; the random suffix is the secret |
ssh, ssh <routeId>@ssh.isolation.cc | Through the bastion | Keys on the member's credential, per route |
| The server's own log | No | Owners and admins, with /server-logs |
The ssh path rides a bastion on a public edge that routes by ssh username to a control connection the server parks outbound, so no host or port is ever handed to a user there either. 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 web previews public?
Yes, on purpose. A web view gets a label under isolation.cc whose random suffix is the access secret. Anyone with the link can open it; nobody can guess it.