Here is a thought experiment for anyone who runs robots for a living, and it ends with a software practice called GitOps. Imagine your whole fleet — the warehouse AGVs, the inspection drones, the arm on line three — had a single master manifest: one document saying which controller version every unit runs, which map each unit carries, which speed limits apply in which zone. Now imagine the fleet itself checked that document constantly and quietly fixed itself whenever it drifted from it. No technicians shifting settings by hand, no “wait, which firmware is unit 12 on?”, no version drift between the east and west aisles. That instinct — write down what the fleet should be, then let machines enforce the writing — is what software teams settled on for running their own platforms, and the idea maps onto robot operations so cleanly that fleet teams usually grasp it faster than web developers do. Let me walk you through it without the jargon.

The GitOps Idea: A Manifest, a Reader, a Corrector

Three roles, that is the whole architecture. The manifest is a file (or a folder of files) describing exactly how things should be configured — stored somewhere that keeps every revision, so nothing is ever silently overwritten. The reader is a small program sitting near the robots that pulls the manifest on a regular schedule and compares it with reality. The corrector is what happens next: wherever reality disagrees with the manifest, the reader applies the manifest’s version and writes down what it did. Engineers never log in to change a unit directly; they propose a change to the manifest, colleagues review it, and once it is accepted the fleet converges to it on its own.

Software folks formalised this in four commitments, published under the CNCF foundation in 2021: say exactly what should exist, as plain data; keep those sayings in a store that preserves complete history; let machines fetch the sayings on their own rather than waiting for someone to deliver them; and never stop checking the match between paper and practice. Notice the last one — forever. A robot that checks its configuration once at boot and never again is doing what most factories did for years. The reconciliation loop is what turns configuration from a boot-time event into a standing property of the fleet, the same way a warehouse robot keeps verifying its own position rather than trusting its initial one. If you want the primary source behind all this, a thorough GitOps explainer lives at the Ops Atlas, and it is friendlier reading than most standards documents.

Why Fleets Should Pull Instead of Being Pushed

The question every operations team eventually asks: why not have a central server push updates out to the robots? Push is how many fleets do over-the-air updates today, and it works — until you look at the keys. Anything that pushes into a robot or its controller must hold credentials that open it. Security researchers, and the NIST guidance on deploying microservices, point out the structural problem: those credentials end up stored in the pusher, readable by everyone who manages the pusher, and attackable through it. The pull arrangement flips it around: the robot-side agent keeps its credentials to itself, and the outside world requires nothing beyond permission to read the manifest. For fleets spread across sites, carriers and customer networks, that difference is not academic — it is the difference between one leaked pipeline and a file nobody can use, instead of one leaked pipeline and a compromised fleet.

There is a second, quieter benefit: pull behaves better on flaky links. A warehouse with dead zones, a drone that loses signal over a field — a pulling agent simply checks when it can and converges when it can. Push needs the receiver to be home when the sender knocks.

Drift Is Normal — Write the Policy Anyway

Real fleets drift, and pretending otherwise is how paper procedures die. A technician bumps a speed limit during a rush; a unit’s safety zone gets widened after a near-miss; someone swaps a payload profile to test a gripper. GitOps does not forbid any of that — it makes drift visible and gives you a policy vocabulary for it, decided in advance per type of setting:

• Revert it when the manifest is the authority — an unapproved controller change goes back automatically.
• Tolerate it when the field legitimately owns its value — the robotics version of this is anything a safety engineer or an on-site tuning process adjusts, the same way cloud autoscalers own their replica counts.
• Alert on it and let a human decide, for anything ambiguous.
• Protect it from automated deletion — maps, calibration data and anything the fleet cannot live without.

The policy conversation takes an afternoon. Without it, every drift becomes a hallway argument; with it, the system simply behaves the way the document says, and the document says what the team agreed. There is a bonus for anyone who has ever inherited someone else’s fleet: because every accepted change to the manifest carries an author and a reason, the answering of “why is unit 12 configured this way?” stops being an archaeology project. The history is the explanation, and the correction of any mistake is a second, equally small review rather than a hunt through tickets, chat threads and memory.

What GitOps Will Not Do for Your Fleet

Friendly means honest, so here are the boundaries. The manifest is not a backup: it describes configurations, not the data your robots generate — maps, sensor logs, inspection footage, calibration tables all stay in whatever storage and backup discipline you already run. The manifest is also not a monitoring system; sensors, logs and alerts live in the tooling covered in our piece on how sensors are integrated into industrial robots, and the reconciler complements rather than replaces them. And it is not a substitute for staged rollouts — you still want to canary a new controller version onto one unit before the fleet, exactly the discipline described in our guide to AGV warehouse automation. Finally, pin your versions. A manifest saying “latest controller” is a wish, not a configuration; the whole model rests on declarations that mean exactly one thing, which is as true for robot firmware as for container images. Keep those boundaries in view and the practice does what it promises — nothing more magical than that, and nothing less.

Where a Fleet Team Could Start on Monday

Small, and on the software side of the house first. Every robot fleet has a cloud tail — the backend services, dashboards and device-registry components that websites and drone platforms alike depend on, much as the teams behind drone robotics platforms already run theirs. Pick one of those services, describe it as files, install one agent, and let it reconcile manually at first — a person confirming each sync for the opening fortnight. Then flip on automation, watch a hand-edit get corrected, and show the room. The fleet-side adoption — manifests reaching controllers and units — follows the same pattern once the platform team trusts the loop. The promise is worth the patience: a fleet whose configuration is written down, enforced continuously and fixable with a review, rather than one whose real state lives in three technicians’ heads and a spreadsheet nobody fully trusts.