How it works
Two planes, one small seam
A thin control plane decides who gets a session. A separate data plane runs the browsers. Neither one does the other's job — that split is what keeps the isolation real.
Control plane
Identity, plans, quotas, audit logs, and the website you're reading run on Cloudflare — Workers, D1, KV, and Durable Objects. This half decides who is allowed to start a session and how many they can run at once. It never runs a browser.
Data plane
The browsers themselves run on our own nodes, one sandbox per session. This half executes what the control plane decides. It never decides who is allowed to use it — every session it creates was already authorized.
Isolation
The sandbox, described honestly
"Isolated" means something specific here, and it varies by node. We report which tier a session actually got, in the session record and the audit log — never a silent downgrade.
Firecracker microVMs
Where availableOn nodes that expose hardware virtualization (/dev/kvm), each session gets a Firecracker microVM — its own kernel, a hardware-backed boundary between the browser and the host.
gVisor
Default on our nodes todayWhere hardware virtualization isn't exposed — the case on our current node fleet — sessions run under gVisor's runsc, a user-space kernel that intercepts every syscall the browser makes. It's a materially stronger boundary than a plain container, but it is not a hardware VM, and we don't call it one.
Network isolation, every tier
Regardless of runtime, each session gets its own network bridge. It can reach the internet; it cannot reach the node, other sessions, or any internal address. Egress is deny-by-default outside that path.
Streaming
Pixels in, input out — nothing else crosses the wire
The viewer is a WebRTC video stream of the sandbox's display, plus your mouse and keyboard events sent back. No file, no cookie, no page content is transferred to your machine in any other form.
The page never reaches you
A drive-by exploit, a tracking script, a malicious download — all of it lands on the sandbox, not you.
You never reach the page
Your IP, fingerprint, and network are never exposed to the site. It sees the node, not you.
Direct media, allowlisted
Video goes straight to the node's public IP on a per-session port, opened only for your address.
Access control
Per-user IP allowlisting, at the node
There's no client agent and no VPN to configure. When you sign in, we note the IP your request came from. That IP — and only that IP — is allowed to reach your session's viewer and media ports on the node.
Scoped to the session
The allowlist entry exists only for the life of the session. It grants access to that session alone.
Follows you across networks
If your IP changes mid-session — a VPN flips, you switch networks — we notice on your next request, add the new address, and let you know your access was updated. No re-login required.
Forensic capture
What each session records — and where it's limited
Capture happens in layers so a gap in one layer doesn't mean a gap in the evidence. The layers differ between Chrome and Tor Browser profiles, and we say so.
Chrome profiles (clearnet, or Chrome-over-Tor)
Full HAR-grade capture: every request and response, the browser's own NetLog, console output, and downloads, recorded through the DevTools protocol. This is the most complete record we produce.
Tor Browser profile
Weaker HAR coverageTor Browser doesn't expose the same instrumentation Chrome does, so request-level HAR capture is thinner here. We still record packet capture on the session's bridge, the DNS resolved through Tor, periodic screenshots, and video where enabled. For sessions where request-level detail matters more than Tor Browser's specific fingerprint, use the Chrome-over-Tor profile — Chrome's capture depth, Tor's egress.
Always captured, every profile
- Packet capture on the session's network bridge
- DNS log for every name the session resolved
- Periodic screenshots
- A sha256 manifest covering every file in the bundle
Everything above is uploaded, hashed, and made available as one downloadable bundle after the session ends. See plan limits for retention windows.
See the limits and plans
Retention, dwell time, and session length all vary by plan.