Every Agent runs on its own dedicated VM. There is no shared compute, no shared filesystem, and no shared network namespace between Agents — even Agents on the same CrabGlamp account.
The isolation boundary
For new Agents (Hetzner cohort):
- Compute — one Hetzner Cloud server per Agent. Bare-metal isolated CPU, dedicated RAM, dedicated disk.
- Network — outbound only. The Agent's
cloudflareddaemon opens an outbound connection to Cloudflare's edge. There are zero inbound ports on the Hetzner server — the public URL is served via Cloudflare's anycast network. - Data plane — TLS terminates at Cloudflare. Cloudflare forwards to the Agent over the tunnel. The platform control plane never sits in the customer's data path.
- Filesystem — the entire VM filesystem is the Agent's own; no volume is shared with any other Agent.
/data/home-coderis the persistent slice that survives stops and image upgrades, but the whole disk is isolated, not only the home directory.
For legacy Fly-hosted Agents:
- Compute — one Fly app per Agent (full isolation).
- Network — Fly's proxy fronts the Agent. Different topology, same boundary.
What is logged
Per Agent:
- Lifecycle events — provision, start, stop, destroy, transfer. Recorded as immutable audit events that persist even after the Agent is destroyed.
- State periods — every transition between running and paused. These power the dashboard's per-Agent state timeline.
- Compute usage — running and paused seconds, aggregated daily.
- Platform-side container logs — the platform's on-VM CLI logs at INFO level to the platform's runtime logs. Customer code inside the container is not exfiltrated.
What survives deletion and transfer
When an Agent is destroyed, the Agent itself is removed but its lifecycle and usage history persist. Usage dashboards correctly attribute past spend to the destroyed Agent's account.
When an Agent is transferred, the source's state period closes, the destination's opens, and a transfer event records the boundary. Past usage on the source stays on the source.
Image pinning
Every Agent is a frozen snapshot at provisioning time. The image, the env vars, and the platform-side code baked into the container are pinned for the Agent's lifetime. Pushing a new image or changing provisioning code has zero effect on existing Agents — only newly provisioned Agents pick up the new image.
Restarting a stopped Agent reuses the same image it was provisioned with, never the latest.
The trade-off: a security patch in the image only reaches an Agent after the customer destroys and re-provisions it. We surface this in the dashboard as a "Cloning is the supported upgrade path" note on Agents older than the current image — the customer clones into a new Agent on the new image, then destroys the old one.
What is not done at v1
- Customer-owned encryption keys — disks are encrypted at the provider level (Hetzner / Fly) but the keys are theirs, not ours and not yours.
- Network egress policy — Agents can reach the open internet on outbound. There is no v1 mechanism for egress allowlists.