Fleets and sites

Every robot belongs to a site and a fleet inside that site.

This hierarchy shows up everywhere:

• Enrollment keys are scoped to one site and one fleet. The robot lands in that fleet automatically.
• Releases can deploy to a target_kind: "robot" or target_kind: "fleet". A fleet deploy creates per-robot child deployments so failures stay robot-specific.
• Config deployments use the same target kinds.
• Fleet logs at GET /api/fleets/{id}/logs aggregate logs from every robot in the fleet, with the same density/search UI as a single robot's log debugger.

When to add a new fleet

Add a fleet when you need to roll out a different release or config than the rest of a site. Common splits:

• By model — forklift-v1, forklift-v2. Different hardware needs different builds.
• By canary — canary versus prod. Push to canary first, watch the events log, then promote to prod.
• By role — pickers, chargers. Same robots, different software.

Avoid sprawl: a fleet that ends up with only one robot is just a robot.

API surface

GET  /api/sites
POST /api/sites           {"name": "Warehouse A"}
GET  /api/fleets
POST /api/fleets          {"name": "pick-v1", "site_id": "..."}
GET  /api/robots          # filtered to org; shows site/fleet membership

Once a robot is enrolled, its site and fleet are fixed. To move a robot, re-enroll it with a key bound to the new fleet (planned). For v0, re-provision the agent's config file.

Why a site at all

A robot that never leaves Warehouse A still has a site, because:

• Per-site enrollment keys keep blast radius small if a key leaks.
• Connectivity health is computed per-site (gateway RTT, packet loss) so one bad uplink doesn't make every robot look offline.
• Rosbag export and config rollouts often want to target a whole site, not every robot the org owns.