The requirements:
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
Most of the conversation in robotics sits around hardware and AI and less is about how to ship and maintain them.
Some companies I talked to in the past are still using Founders' time bash scripts or ansible to deploy their robots. It's 2026, we must do better.
This is the intro, it looks at why updating machines by hand gets harder as a fleet grows and explaining what are the requirements.
Very much a work in progress. I'd be glad to hear from anyone who's been through it.
Updating robots by hand works at five. What happens at fifty, and why you must fix it before you get there.
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:
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:
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).
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.
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.
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 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.