Ask a robotics company, especially a young one, how software gets onto a robot that’s already at a customer site, and the answer usually is someone driving there, accessing the robot, pulling the code and getting it to run, watching the robot move for a minute, then moving on to the next one.

The reason is lack of awareness rather than carelessness. How many robotics companies have a DevOps engineer on the team? Most are led by roboticists and researchers who can make anything happen on a few robots. So a great deal of sophisticated software gets written, and then moved around manually.

The idea rarely crosses their mind; they have other problems to chase. Between roboticists, application engineers, hardware engineers and the hardware itself, the margin is thin. It’s why so many robotics companies die when scaling. And here I am, suggesting you add one more engineer to it. Funny, right?

I’m suggesting it because the payback is faster than it sounds, and if you don’t do it at the right time, you will pay a heavy price. As soon as your company starts scaling, you will need:

  1. Compliance: prove what is running where, to a customer’s security team or a regulator
  2. Speed: ship a fix to the whole fleet the day you have it, not the month you have it
  3. Security: know which keys open which robot, and sign what you install
  4. Control: stop a rollout, roll one back, and know the state of every machine
  5. Visibility: know a robot is degrading before the customer phones you about it

That’s the subject of this series: what it takes to get from manual deployments to multiple fleets where software ships on its own.

Figure 1. The same fleet twice. On the left, updated by hand: every machine on its own version, reached one after another, and no way to tell which one is broken. On the right, one known state, every machine traceable to a single origin, and the fault visible at a glance.

We will cover:

  1. The architecture: from a developer’s push to a controlled rollout
  2. Update planes: ship application and OS changes separately, roll either back
  3. Data collection at the edge: get system and ROS data off the robot
  4. Logging: find out what happened, during and afterwards
  5. Alerting: get paged for what stops the robot, and nothing else
  6. Predictive maintenance: catch a failing part before the customer calls
  7. Connectivity: pick the link that fits the site and the budget
  8. Hardware-in-the-loop testing: catch it in CI, not at a customer site
  9. Signing releases and keeping secrets: only builds you approved reach a robot
  10. Image hardening: ship less attack surface than the distribution handed you
  11. Compliance (SBOM and more): answer the audit without reconstructing history
  12. Tooling and training: let every engineer deploy without asking you

How most robot fleets actually get updated

Most companies run some blend of three.

The first is pure SSH. Someone connects to each machine and updates it. It fails quietly, so nobody ever decides it needs patching. It just slips. Some time later the fleet runs four versions and nobody can say which machine has which. Keeping a mixed fleet in a known state is the problem the fleet-management literature keeps circling back to (IEEE, December 2024).

The second looks better and often isn’t. An Ansible playbook, or a pile of bash from the founders’ time, still runs and still reports success. It just isn’t what’s on the robots any more, because a patch was applied by hand at one site and never added to the playbook. That’s worse than nothing, because it looks like a solution.

The third is the OS, which usually has no story at all. The application changes weekly and the customer notices when it breaks. The operating system changes rarely, nobody notices it not changing, and the robot keeps running whatever it shipped with. That part is measurable. One scan found 643 public-facing DDS services across 34 countries, some of them running implementations with disclosed, unpatched vulnerabilities (Alias Robotics, 2022). Looking at firmware more broadly, manufacturers left outdated libraries in place in 67.3% of the 6,900 images examined (AutoFirm, arXiv, June 2024).

What manual fleet updates really cost

Doing it by hand costs hours, and that’s the smallest of it.

Control is knowing the state of every machine and being able to change it. Today that answer lives in a spreadsheet somebody updates when they remember.

Visibility is knowing a machine is going wrong before anyone tells you.

Security is knowing who can change what a robot runs, and proving it was you. Keys get dropped on machines by hand, never rotated, never revoked, and nothing is signed. An assessment of the humanoid ecosystem scored three shipping robots between 39.9% and 79.5% on security maturity, and named the over-the-air update channel itself as part of the exposure (SoK, arXiv, August 2025).

Compliance is showing which machine got which fix, and when. A manual process can’t produce that history afterwards, and without it you lose the customer.

Scale is all of the above without the cost growing with the fleet. Wait too long and half the work is just finding out what’s on each machine.

Application and OS updates need separate paths

Often, developers will not have access to the robot (which is on a private network or no network at all) and the robots are anyway working.

There are 2 situations: an application update, which restarts a process or an OS one which often reboots the machine. The latter will be much more disruptive.

So, we have 2 architecture paths. Application changes: frequent, reversible, no reboot. The OS, on the other side is switched over only in extreme situations.

The CRA puts a deadline on OTA updates

Everything above is an internal argument, and an internal argument can always wait another quarter. This one arrives on a date.

The EU’s CRA (Cyber Resilience Act) covers products with digital elements and a network connection, which describes essentially every commercial robot sold into the European market. Its vulnerability and incident reporting obligations apply from 11 September 2026, and from 11 December 2027 its full obligations apply, including the requirement that a product be capable of receiving security updates, with a support period of at least five years (European Commission). Robotics systems are explicitly in scope (Rockwell Automation), and if you build machines it lands alongside the Machinery Regulation rather than instead of it (Machinery Safety 101, February 2026).

“We can’t patch machines in the field” stops being a known limitation and becomes a compliance gap with a date attached. No choice anymore.

A reference architecture for robot fleet deployment

A complete deployment architecture for robot fleets, worked through end to end: provisioning bare metal, connecting sites you can’t dial into, running workloads at the edge, shipping application and operating-system releases down their two separate paths, and operating the result once it exists.

I’m David Bensoussan. I build deployment and update infrastructure for hardware and robot fleets. If you’re working out how to ship software to machines you can’t reach, book 30 minutes and we can work out your fleet’s update path.