The last article listed five capabilities and the order to build them in. Before building anything, we must agree on the architecture: what runs where, and which direction each connection travels.
The architecture has three layers. The robot runs its own ROS2 stack as before. Above it, one or more edge servers per site carry updates and data between the robot and the hub. Above the edge servers is a single hub, shared by the whole fleet, and every edge server connects to it. The hub never opens a connection to a site, that’s what makes control and security possible.
None of this touches the robot itself by the way. DDS (ROS2’s transport) assumes every participant is on the same local network, like a factory floor. A fleet isn’t: sites can be kilometers apart, reached over the internet or a cellular network, if reached at all. The edge server handle the fleet-facing connection, and the robot keeps using DDS locally, which protects it from outside interference.
One or more edge server, three jobs
A site is:
- One or more edge servers
- Its network
- And the robots it drives.
The edge server(s) run a Kubernetes cluster. That’s enough to give the site a system that keeps itself in sync, instead of a script someone has to remember to update and run. It does three jobs: hosts the application the robot depends on, terminates the tunnel back to the hub, and stores the operating-system images the robots boot from. One machine covers all three by default. A site adds a second edge server when there’s more data than one box can process, or for redundancy, so one machine failing doesn’t take the site’s fleet connectivity down.
One direction only
The edge server is on a network the operator doesn’t own, usually behind a customer’s firewall with no inbound port to open. A VPN handles this: the tunnel always starts at the site and ends at the hub. The hub only answers connections; it never starts one.
That one rule covers most of the security story. A customer’s firewall can block every inbound connection by default and the fleet still works, because nothing was ever going to arrive uninvited. Scanning the customer’s network for an open management port finds nothing, because there isn’t one. The only request to the customer’s firewall is letting one machine reach the internet. The customer’s own security guidance asks for the same shape: eight national cyber agencies recommend outbound-only, uni-directional connectivity at the boundary of an operational network (NCSC, “Harden your OT boundary”).
Two release paths from the hub
Software reaches an edge server one of two ways. The application plane ships through Git: no reboot, and a bad push reverts the same way it shipped. The operating-system plane ships through a signed image written to one of two boot slots: a reboot, gated by a maintenance window and a check that the robot isn’t mid-motion. Article one covers why the two need separate paths; article two covers how each one is built.
Both stage through the same three rings: the test site first, then a canary or two, then the rest of the fleet. Each ring has to clear before the next one gets the build.
The decision: three layers
Fewer layers looks simpler, until you weigh what each one loses.
One layer means no channel to the robot at all: checking on it or changing anything means driving there. Two layers puts the robot itself on the internet, uploading its own data and pulling its own updates directly. That’s fragile, since the fleet connection now depends on the robot’s own uptime, and exposed, since the robot’s local network is open to the internet. A reachable interface on the robot is a fleet-wide problem: a hardcoded key in Unitree’s setup interface gave root on four robot models, and a compromised machine could find others in range and take them over on its own (IEEE Spectrum, September 2025). It’s impossible anyway. No customer will add your devices to their network.
Three layers moves that job onto the edge server. It holds the connection, buffers and gates what leaves the site, and takes the load off the robot, none of which the robot needs to know about.
| Feature | 1 layer | 2 layers | 3 layers |
|---|---|---|---|
| Remote access to the robot | ✗ | ✓ | ✓ |
| Fleet connection survives a robot restart | ✗ | ✗ | ✓ |
| Robot's local network stays closed | ✓ | ✗ | ✓ |
| Data buffered before it leaves the site | ✗ | ✗ | ✓ |
| Extra compute or redundancy possible | ✗ | ✗ | ✓ |
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.