Transparency

What we log.

Disposable VMs raise a fair question: what does this platform actually see, and what does it keep? Here's the plain answer: everything we record, why we record it, and everything we don't.

What we record, and why

Domain facts only: enough to bill accurately, debug a broken boot, and catch abuse.

Lifecycle events, with who and why
Created, booted, suspended, and more. Each one is tagged with the user, admin, PR, ticket, or system that triggered it.
Which hostname served traffic, and when you attached a terminal
A host-level match off the proxy's access feed: hostnames only, never URLs, paths, or request bodies.
Egress bytes and new-connection counts
Per-VM counters for billing and abuse detection. We never log packet contents. The scan-target set is an in-kernel counter that expires in 60 seconds, not a log.
Outbound connection metadata
Which VM opened a connection to which destination IP and port, per minute, and the source port it left from on the shared host address. Never what was sent. Kept for 7 days, so we can answer an abuse report about a shared host IP.
Boot-step outcomes and capped install logs
Which setup step succeeded or failed, plus secret-redacted, size-capped install/build output, so you can debug a broken boot.
Live resource gauges
CPU is sampled on the host; memory and disk are read from the guest on demand, not stored. Just enough to draw the runtime panel.
An audit log of account and admin actions
Actor, action, resource, IP, and user-agent, with secret-redacted diffs, for account security.
Operational wide events
Domain fields only, sent to our logging backend, kept for 30 days. Your email address is never logged.

Off limits, by design

These never reach a log, a database row, or our monitoring backend.

Terminal contents
A reattach replay is serialized inside your own VM's memory. It dies with the VM and never touches us.
AI prompts and conversations
Chat transcripts live on your VM's own disk, and your subscription's AI traffic goes straight from the VM to the provider. It never passes through us.
Your code or file contents
We orchestrate the VM; what's inside it is yours.
Secret values
Encrypted at rest, write-only via the API. We can store them but never read them back.
Email bodies
We send the email; we don't keep a copy of what it said.

Where it's not that simple

Hibernation snapshots and workspace-salvage archives

When a VM hibernates, or you salvage a workspace before it's destroyed, its disk contents are archived to object storage. That's real data, stored so your work survives, downloadable only by you, via a presigned, owner-only link. We don't read it.

Network rules every VM gets

Outbound mail on port 25 is blocked, so no VM can send spam directly. Ports 465 and 587 stay open: send through your mail provider there. Known crypto-mining pools, botnet command servers and the Tor network are blocked too, from public lists we refresh daily. A VM that keeps trying to mine is suspended, and we email you why. These rules block traffic in the kernel and only count blocked attempts. Your VM's DNS lookups go through a resolver on its host that refuses mining-pool domains; it counts refused lookups and never logs the names you look up.

7-day outbound connection log

Every VM on a host shares that host's public IP, so when a provider reports an attack from it, the only way to find the VM responsible is to know who connected where. We keep the destination IP and port, the minute and the source port for 7 days, then delete them. Contents are never recorded.

30-day operational log retention

Wide events about what our systems did (job outcomes, timings, error rates) are kept for 30 days, domain fields only, then gone.

That's the whole list. No hidden analytics, no session recording, no reading your code or your agent's conversation with you.

See how the rest of the platform works

Get started

Your next VM is one command away.

Connect a repo, and get a full-stack dev environment with Claude Code and Codex already running, before your coffee's done.