Your station is a container on hardware we own, with a network of its own. This page describes exactly what that means, what we hold, and what we deliberately don’t.
“Isolated container” usually means your container shares one network bridge with every other customer on the machine. Ours doesn’t.
Every station gets its own dedicated network bridge and a static address on it — not a shared bridge, and not DHCP on a pool your neighbours also sit in. Stations cannot see each other’s traffic or reach each other over the local network.
Stations run on dedicated bare-metal servers we lease from Hetzner and administer ourselves — not resold cloud instances. We control the host kernel, the firewall and the update schedule.
You get real SSH into your own container, authenticated with an SSH key you add and can remove. Connections reach it through the host, so the container is never directly exposed to the internet on the SSH port.
CPU, memory and disk are capped per station at the size of your plan, so a busy neighbour cannot starve your assistant.
What we store, and how.
Every station gets its own hostname and its own certificate, issued and renewed automatically. There is no plain-HTTP path to your station’s dashboard, terminal or gateway.
Requests to your station’s web surfaces are checked against your ClawStation session before they reach the container. A stopped or lapsed station serves a lock page, not your assistant.
A Content Security Policy is enforced in production, and sign-in and account endpoints are rate-limited against brute force and abuse.
Chat channels are configured to answer people you have paired with, so a stranger who finds your bot cannot start using your assistant — or your inference budget.
Stations are backed up daily. You can take one on demand, restore it yourself, and download it — restoring is not a support ticket, and leaving is not a hostage negotiation.
We upgrade OpenClaw and Hermes across the fleet and then check the version actually running afterwards — not the one the installer reported. See below for why that distinction is the whole point.
Every station has its own uptime monitor. Twice a day we check the health of every container in the fleet, and once a day we create and tear down a throwaway station to prove the whole signup path still works.
Stopping a station shuts it down cleanly and confirms it stopped, so the assistant’s memory and task databases are never left mid-write. Stopping deletes nothing.
Most “automatic updates” in this category are an unattended package update on a timer. That fails quietly in more ways than it looks: a runtime version check that rejects the new release, a storage change that needs a migration, or an install that lands in a directory the running service never reads from.
We know each of those because we have hit them. Our own upgrade pipeline once reported success on every attempt while installing to a path the gateway did not run from, which meant stations reported as upgraded were still running the old build. The fix was to stop believing the installer: we now read back the version the service is actually running and treat a mismatch as a failed upgrade.
The limits matter as much as the controls, so here they are plainly.
Administrative access to the hosts is limited to the ClawStation operators and is used for provisioning, upgrades, incident response and the health checks described above. Actions taken against a station are recorded.
Found a vulnerability? Please report it to legal@clawstation.ai before disclosing it publicly, and give us a reasonable window to fix it. We will confirm receipt, keep you updated, and credit you if you’d like the credit.