Ansible for robot fleets, and where it breaks.

It is a reasonable choice. Ansible is agentless, it is already in the building, it needs nothing on the device beyond SSH and Python, and a playbook that copies a binary and restarts a service is fifteen lines. For the first twenty units it is genuinely the right tool, and reaching for something heavier before then would be overengineering.

None of what follows is a criticism of Ansible. It is an excellent tool being used a long way outside the environment it was designed for: reachable machines, on a network you control, that are up when you run the playbook.

The pattern is consistent enough to be predictable. First a wrapper script that retries the unreachable hosts. Then a spreadsheet, because the inventory stopped being trustworthy. Then a cron job on the device that pulls instead of waiting to be pushed to, which is the point at which the team has started writing an agent. Then a health check after the update, then a way to undo it, then a way to know whether it worked across the fleet rather than on one unit.

Each step is individually sensible and takes a week. Collectively they are a deployment system, maintained by people whose actual job is the robot, and it never quite gets finished because there is always something more urgent.

This is not a hypothetical. It is what the founder built at Pooled Energy for thousands of connected controllers and single-board computers in customer backyards, on Ansible, because that is what existed. Every rollout became a manual, nervous, all-hands afternoon.

The structural fix is to invert two things.

Pull instead of push. An agent on the device that fetches when it has signal removes the reachability requirement entirely, and works fine on a customer network with no inbound path. It also means a unit that was offline during the rollout is not skipped, it is just later.

Let the device judge the update, not the operator. Stage to an inactive slot, switch atomically, boot on trial, and require a positive health result including connectivity before the change is made permanent. Failure becomes the default, so the dangerous releases undo themselves without anyone reaching the robot.

Above that, gate the fleet on confirmed units rather than elapsed time. You can build all of this on top of Ansible, and plenty of teams have. The question is whether you want to be the team maintaining it.