Blog

Shipping a production embedded Linux product on an NXP i.MX board eventually leads to the same question: how do we update these devices in the field without bricking them? If the product is going to live for five, ten, or fifteen years, the answer needs to be more robust than “SSH in and run apt upgrade.” For devices that cannot afford to brick under any circumstances, the established answer is A/B system updates: two copies of the system on separate partitions, a bootloader that picks between them, atomic switchover, and automatic rollback if the new copy does not come up cleanly.

This article is a practical, technically detailed walk-through of how to build A/B system updates for NXP i.MX boards. The approach is generic across the i.MX 8, 8M, and 9 families; we have validated it end-to-end on the NXP FRDM-IMX91. Along the way, we cover partition layout, U-Boot configuration, A/B version selection from the bootloader, signed FIT images for verified boot, and dm-verity for runtime rootfs integrity, all the way up to how these pieces plug into a meta-imx build. By the end, you'll have a reference design that updates atomically, rolls back on failure, and cryptographically verifies boot artifacts and rootfs blocks, ready to drive with Rugix Ctrl or any other update engine.

Today, with the release of Rugix Ctrl 1.1, we are introducing Rugix Apps, a new mechanism for deploying and managing application workloads on embedded Linux devices.

Embedded devices typically run diverse application workloads on top of their base system: containerized services, local HMIs, data pipelines, or inference models. These workloads change more frequently than the OS, and different devices in a fleet often need different combinations of them. Managing their lifecycle, versioning, rollback, crash recovery, and persistent state, has traditionally been left as an exercise for the integrator. Rugix Apps makes it a first-class capability of Rugix Ctrl, building upon Rugix's best-in-class delta update capabilities, security properties, and reliability.

Rugix Apps works standalone: you do not need Rugix Bakery, Rugix's state management, or even Rugix system updates to use it. Any Linux device with Rugix Ctrl installed can deploy and manage application workloads.

In this article, we discuss the challenges of deploying and managing application workloads on embedded Linux devices, show how Rugix Apps addresses those challenges, and walk through a concrete example using Docker Compose.

If you are building an embedded Linux product, one of the engineering decisions you face is which on-device update engine to use. This decision has lasting implications: embedded devices routinely have lifecycles of 5 to 15 years, and whichever update mechanism you choose today will determine how you ship software to devices already in the field for the entire duration of that lifecycle.

Fortunately, the landscape of open-source OTA update engines for embedded Linux has matured significantly over the past decade. Where teams once wrote bespoke shell scripts to flash partitions, there are now several ready-made open-source tools available to choose from. These tools differ in philosophy, architecture, features, and the trade-offs they make. In this article, we survey and compare the major open-source OTA update engines for embedded Linux, examine the fundamental techniques and strategies they employ, and provide a technically grounded comparison.

We are thrilled to announce the release of Rugix Ctrl 1.0 and Rugix Bakery 0.9. 🎉

With Rugix already powering tens of thousands of devices worldwide, this milestone felt overdue. But we didn't want to rush it. We wanted to get things right, and we believe this release reflects that.

There is a growing trend in the embedded Linux space: vendors are coupling their cloud platforms with their own on-device OTA update mechanisms. On the surface, this makes sense. You get a single vendor, a single integration, a single bill. But if you look a few years ahead, this coupling comes at a cost that is easy to underestimate.

You know you're in a very special niche when you write blog posts with both "NixOS" and "Yocto" in the title. But, here we go. If you're still reading, you're probably one of the few people who will actually appreciate this. Welcome. 👋

At Silitics, we maintain meta-rugix, the Yocto layers for integrating Rugix Ctrl into Yocto-based systems. As the layers mature and gain more users, we need CI to catch issues before they ship. The problem: even our Debian-based Rugix Bakery builds are slow and hit disk limits on hosted runners, and Yocto is worse. We're talking hours of build time and 50+ GB of disk space. We kept putting it off, but we just set up self-hosted GitHub runners on NixOS, and it wasn't as painful as we feared.

In this article, we'll walk through how we set up our CI infrastructure: declarative runner configuration, shared build caches, rootless Podman, and secrets management with SOPS. If you're struggling with Yocto CI, this might save you some headaches.

As part of our ongoing commitment to Rugix as an independent open-source project, we moved it to its own GitHub organization. The repository has moved from silitics/rugix to rugix/rugix, and the Docker images have moved accordingly.

Together with EY and Cumulocity, we have released a whitepaper on a practical reference architecture for EU Cyber Resilience Act (CRA) compliance. Rugix is a core component of the whitepaper's reference architecture, providing essential on-device functionality needed to meet the CRA's technical requirements.

We are thrilled to announce the release of Rugix version 0.8.14! 🎉 Don't let the version number fool you, this release packs two game-changing features for embedded Linux OTA updates:

• Cryptographic integrity verification through embedded signatures.
• Out-of-the-box compatibility with Mender and RAUC.

import DeltaSavingsCalculator from "../../components/DeltaSavingsCalculator.tsx"; import { PlotRollingUpdates, PlotTotalSizes, PlotMajorUpdates, } from "../../components/DeltaPlots.tsx";

We are excited to announce the release of Rugix (formerly Rugpi) version 0.8. 🎉 This release marks a significant milestone for the project. With this release, we rename the project from Rugpi to Rugix, cleanly separate Rugix into two independent tools, Rugix Ctrl and Rugix Bakery, and furthermore add a myriad of new and exiting features to both tools. Read on to learn more! 🚀

We are excited to announce the release of Rugpi version 0.7. 🎉 With this release, we expand the device support beyond Raspberry Pi and add official support for Debian and Alpine Linux.

We are excited to announce the release of Rugpi version 0.6. 🎉 This release introduces significant enhancements to the image building pipeline, elevating its flexibility and power.

We are excited to announce the release of Rugpi version 0.5. 🎉

Version 0.5 signifies the end of Rugpi's experimental phase. We are confident that the foundational update mechanism is sound. From this point forward, we aim to maintain backwards-compatibility for updates. This means, if you deploy a system with Rugpi now, you should be able to update it remotely later. While the update process itself is stable, we are still iterating on the design of the image building pipeline and the CLI and APIs. What will change in the upcoming months is the way system images are build. We are planning to introduce layers, drawing inspiration from Docker. Layers will streamline the image-building process and enable fail-safe delta updates in the future.

We are thrilled to introduce Rugpi, the first open-source platform that empowers you to create innovative products based on Raspberry Pi. 🎉 At its core, Rugpi is designed to streamline the process of building commercial-grade, customized variants of Raspberry Pi OS for your projects. Developed out of the need for a reliable platform for our customers, Rugpi boasts three core features: