Updates

There are two things that get updated: your hub (managed by us) and your spoke tooling (the single dev file on your machines). This page explains how each stays current and what, if anything, you do.

Managed hub updates (we do this)

On the managed plan you do not deploy your hub — we do, on a staged, health-gated pipeline designed so a bad update never leaves you broken. The rollout is three steps:

deploy  ->  canary  ->  trust

• Deploy — the new release is fetched, installed, and the hub restarted, then gated on a real health check. If health does not go green, the pipeline automatically rolls back to the previous release. Releases are kept versioned so rollback is instant.
• Canary — a green health check proves the hub is *up*; it does not prove it can drive a spoke. The canary sends a real, authenticated no-op keystroke to a reserved spoke and confirms it landed in that spoke's tmux. A failed canary means the control path is broken even though the service is up — the signal to roll back.
• Trust — only after a green canary is the new release treated as live.

For larger changes we can stand up a staging hub — a second, identical hub fronting a small set of canary spokes — and prove a release there before promoting the exact same version to your production hub. This keeps the blast radius of any change to a canary, not your whole fleet.

Practical takeaway: you take no action for hub updates. They roll forward safely and roll back automatically on failure.

Spoke tooling updates (quick and boring)

A spoke runs one file: the dev script. Updating a spoke is re-running the installer, which fetches the current single file:

./install.sh --role spoke

Because a spoke holds no state beyond its tmux sessions and its local repos, updating the tooling never touches your work. Your sessions and worktrees are unaffected.

To confirm a spoke is wired correctly after an update:

dev onboard-check

It prints one OK/FAIL line per check so you can see at a glance that hooks, config, and reachability are intact.

How to know an update is available

• Hub / cockpit: when the hub serves a newer cockpit build than the tab you have open, a small update pill appears in the header. Click it to reload into the new version. Nothing is forced on you mid-session.
• Spokes: re-running the installer always fetches current; there is no version to pin by hand for routine use.

Durability across updates

Hub updates restart the hub service, but your agent sessions are held in tmux and survive the restart. Clients reconnect automatically — tmux-backed sessions with automatic reconnect — so a hub update looks, from your seat, like at most a brief reconnect, not a lost session.

Next steps

• Adding spokes — register new machines.
• Billing — plans and what an upgrade changes.
• Troubleshooting — if the cockpit does not reconnect after an update.