Isolation and worker pools

Worker pools are single-tenant

Desktops run on a worker host (shown in the console as your workspace's compute pool). A host is bound to exactly one workspace: no other workspace's desktops, saved states or screenshots are ever on it. The gateway in front of the host serves only the workspace bound to it, so a key from another workspace is refused there, and ids from another workspace are answered with 404, never 403, so that their existence is not revealed.

• The console's Overview shows your compute pool, its region and its desktop capacity. The sidebar's status footer shows the host's state (Provisioning, Active, Draining, Quarantined, Retired, or No heartbeat after 60 s).
• A workspace without a bound host shows "No compute pool yet. Drums assigns a dedicated host to this workspace; you'll see it here when it's ready." Launching computers and runs is disabled until the platform operator binds a dedicated host.
• The host's capacity is shared by all of your workspace's members and keys: client.health()["capacity"] returns {live, max}.

Each desktop is isolated

The runtime restores every desktop into its own:

• pid, mount, network, ipc and uts namespaces, checked after every restore by the isolation gate (they must differ from the host's and from every other desktop's);
• cgroup with CPU, memory and swap limits (4 vCPU, 4 GiB, no swap), checked by the cgroup gate;
• user namespace (root inside it is an unprivileged id on the host), with no_new_privs, a reduced capability set and a seccomp filter;
• network namespace with loopback only: no outbound network and no DNS from inside a desktop.

The agent's user user is in no administrator group, and every process it drives has no_new_privs, so sudo, su and pkexec refuse. Task setup steps that need root are run by the runtime as trusted provisioning, never by the agent.

If any of these checks fails, the episode is invalid and its reward is flagged: see Tasks and verifiers.

What the gateway checks on every call

1. The API key: format, hash, not revoked, not expired, its owner still an active member, the workspace active.
2. The rate limit: 20 requests per second per key, burst 60.
3. The host binding: the key's workspace is the one this host serves.
4. The route's scope, against the key's effective scopes (key scopes intersected with the owner's current role).
5. Ownership: path ids must be computers or saved states of your workspace on this host.
6. For creates and forks: your live-computer limit, the host's capacity, your spend cap, and that the template still matches its manifest and the host runs an approved runtime build.

Records the gateway returns never include host internals (ports, process ids, host paths); paths in error text are removed.

Observation in the console

The console shows desktops through the screenshot viewer, which is observation only: there is no keyboard or mouse input from the browser. Actions go through the SDK or HTTP API.