OTA updates for robotics

Robots are starting to get the same kind of update pipeline that phones and cloud apps already have, except a bad update here can strand a warehouse cart, freeze a vacuum fleet, or force a truck roll to hundreds of devices. Foundries.io is now pitching that workflow directly at robotics teams, with a March 27, 2026 robotics page centered on continuous over-the-air updates, continuous integration and continuous delivery pipelines, rollback-ready releases, and fleet observability. (foundries.io) An over-the-air update is just software sent to a machine after it has already shipped. In robotics, that software can include the application, the operating system, and even firmware, so the update touches more of the machine than a typical phone app patch. (foundries.io) That changes the stakes. If a web service update goes wrong, you usually roll traffic back in a data center, but if a robot update goes wrong, the failure happens on a moving, battery-powered, sensor-filled device sitting in a hotel, factory, hospital, or warehouse aisle. (foundries.io) This is why embedded teams care so much about the shape of the update itself. Foundries.io says its platform supports atomic, immutable, secure, and incremental updates, which is industry shorthand for packaging changes so a device can switch cleanly to a known software state instead of ending up half-updated. (foundries.io) The old mental model for continuous integration and continuous delivery came from servers. Developers pushed code, automated tests ran, and new software rolled into cloud machines that were easy to replace if something broke. (foundries.io) Robotics adds a second half to that pipeline: device lifecycle management. The same automated build system that compiles code now also has to decide which robot gets which release, when it installs, what happens after reboot, and how to recover if the new image fails in the field. (docs.foundries.io 1) (docs.foundries.io 2) Foundries.io’s documentation makes that shift unusually explicit. A code push can trigger a continuous integration job that builds a new target, signs update metadata, and publishes it for devices that follow a specific tag, which turns source-control events directly into device-available releases. (docs.foundries.io) Those tags matter because fleets are rarely updated all at once. Foundries.io describes devices following specific update tags and also describes large-fleet release patterns where a small canary set gets the update first before a wider rollout, which is the robotics version of “try it on a few machines before you touch the whole building.” (docs.foundries.io) (foundries.io) Rollback becomes a first-class feature in that world, not a nice extra. Foundries.io’s robotics pitch specifically highlights rollback-ready over-the-air updates, because the safe move for a deployed robot is often “return to the last known-good image,” not “hotfix it live and hope.” (foundries.io) Security also moves closer to the center of operations. Foundries.io says its update system uses The Update Framework, a widely used secure update design, and pairs that with signed updates, secure boot, software bill of materials generation, and embedded Common Vulnerabilities and Exposures tracking so that patching becomes part of normal fleet operations instead of a special emergency project. (foundries.io 1) (foundries.io 2) The company is also tying that pitch to regulation. Its robotics page says the platform is aligned with the European Union Cyber Resilience Act, which matters because many robot makers now have to prove not just that they can ship a device, but that they can maintain it securely for years after sale. (foundries.io) This is not only a theory slide for Foundries.io. Its website says Tailos, previously Maidbot, used the platform for robotic vacuum cleaners, including “fine control over the lifecycle of OTA updates” and integrated continuous integration for both platform software and applications, which is exactly the kind of mixed hardware-software stack robotics teams struggle to keep synchronized. (foundries.io) So the news here is less “robots can now get updates” than “the software release process for robots is being rebuilt to look like cloud DevOps, with extra rules for safety, rollbacks, staged rollout, and hardware diversity.” Foundries.io is selling that as a product category, but the deeper point for embedded engineers is that continuous integration and continuous delivery is no longer stopping at the build server; it now reaches all the way into how physical machines live, fail, recover, and stay secure in the field. (foundries.io) (docs.foundries.io)