Fleet applies an operator's desired worker settings to trusted computers. A non-LLM residual on each computer reconciles local checkouts, harness sessions, and schedules. It is a control-plane reconciler, not a remote shell. Keep a residual on every computer that Fleet must be able to manage, including when its desired worker count is zero.
For a single scheduled worker, start with Connect a computer. Fleet is an advanced operator workflow: first understand the board, worker identity, and the credential boundary.
On each trusted computer, install the official durmem runtime, connect the dedicated board, install the requested harness, authenticate it as the worker's OS user, and prove Git access to the intended repository. A human operator creates the shared vault key once and transfers it out of band; install it at the local hidden prompt before starting the residual. Do not put it in a task, message, chat, command argument, repository, or log.
Ask an interactive operator agent to follow the installed loom-kanban-fleet bootstrap workflow: verify the prerequisites, install the vault key, then run the official durmem residual preflight, install, and status steps. Do not publish workers before the residual and harness authentication are ready. A new residual can be healthy with zero workers until its host ID is added to desired settings.
The operator reads the stable, non-secret host_id from fleet_host_status and uses that ID in the desired configuration. Hostname, IP address, and OS are observations, not stable identity. Each worker family is identified by (host_id, repo_name, harness); its count controls how many slots Fleet maintains. A repository or board move creates a new identity: add and verify the replacement before retiring the old one.
Publish a complete, secret-free desired configuration through the official Fleet workflow. Credential profiles are referenced by opaque IDs and revisions; plaintext secrets never go in the configuration. Review the full change before publishing. The portal rejects a stale revision it loaded. The CLI's publish path is not an atomic compare-and-swap, so re-read the current revision immediately before publishing and stop if it changed.
The Kanban store key grants board access. The Fleet vault key decrypts Fleet credential profiles. They are different secrets and neither should be sent through Kanban. The vault key is push-only: a human on a trusted computer transfers it out of band; a host without the key must never ask a peer to send it. Every host with the vault key can decrypt every profile on that board, so removing a worker does not revoke that host's key. If a host is removed or compromised, rotate the vault key and affected credentials on the remaining trusted computers.
Codex and OpenCode keep their native sign-in on each computer. Claude uses its separate encrypted worker credential profile. Private-server store profiles carry the configured CA-file path, not the certificate; the readable certificate must already be present at that path on each target computer. Never print or copy credential files to verify them.
After publishing, check fleet_host_status. A computer is configuration-converged only when its status is fresh, state is converged, and seen_revision equals applied_revision at the desired revision. Then check each expected worker's own kanban_agent heartbeat. A converged residual does not prove every worker is alive, and a desired count does not prove a session is enrolled or working. Conversely, a worker that is dormant after the idle timeout can still be healthy if its schedule and heartbeat are current.
Use logs and fresh status to diagnose a degraded or stale computer. Do not manually delete or adopt a Fleet-managed checkout, guess a host from its IP, or restart a worker to make a status look current. Setting a worker count to zero removes that worker family, not the computer's residual. Removing the residual is a separate local operator action.
On macOS, a current runtime version does not prove the residual's launchd launcher is current: the live residual does not repair its own job. When a release changes that launcher, an operator must use the official residual installation workflow and verify its status; a version number alone is not the check.
For an end-to-end practice, see Tutorial 10C.