RAUC - 10 Years of Updating 🎂
10 years ago, almost a decade before the Cyber-Resilliance-Act (CRA) enforced updates as a strict requirement for most embedded systems, Pengutronix started RAUC as a versatile platform for embedded Linux Over-The-Air (and Not-So-Over-The-Air) updates.
Looking at the git log for the initial RAUC commit, we find this short and simple message:
commit 673765859c8c4d5c8f60ae4871c55d433dfa1c28 (tag: v0)
Author: Enrico Jorns <ejo@pengutronix.de>
Date: Wed Apr 22 10:58:24 2015 +0200
Initialize project for autotools
Signed-off-by: Enrico Jorns <ejo@pengutronix.de>
So today, on April 22, 2025, we celebrate RAUC’s 10th birthday! 🥳
This post reflects on the journey from the project's early days to its recent developments — offering a behind-the-scenes look at what it took (and still takes) to create an update framework that is both easy to integrate and robust even in adverse conditions.
A New Open Source Project
Fortunately, most of our customers had already recognized the importance of updating devices in the field — even before the Cyber Resilience Act (CRA) mandated it. As a Linux consulting company with nearly 15 years of experience at that time, we had encountered a wide range of homegrown update solutions and had even built a few ourselves.
One recurring pattern quickly became clear: we were always implementing just the bare minimum in terms of update capabilities and security. The really interesting and challenging features were often postponed indefinitely. What’s even more problematic, each solution was tailored to a single customer, meaning its test coverage was extremely narrow and improvements were hard to reuse.
The desire to create a generic, reusable and Open Source update framework grew steadily. By 2015, we had two or three new customer projects lined up — all requiring OTA update functionality. We took this opportunity and asked if they’d be willing to collaborate on a shared, Open Source solution.
We researched other early frameworks, such as SWUpdate, but none of the available options met our core design goals — such as enforced signature verification, a userspace build system and use of a common utility library, and D-Bus-based IPC. So we started building something from scratch — and that’s how RAUC began.
The Early Days
We were mainly our CTO Jan Lübbe — who had most of the very good ideas and a great big picture of where the journey should go — and me, Enrico.
Before the actual implementation, we even created a concept document to align with our customers about the requirements and to be sure we all have some sort of common understanding how RAUC should behave.
Jan and I worked together on the project full-time for some weeks. Rust and other modern programming languages were far from being widely available, so, as a company with strong kernel expertise, we chose C as the implementation language for RAUC. We chose GLib as our utility library since it was a good compromise between capabilities and complexity and it was already included in most of our customer's projects already. For cryptography, we chose OpenSSL, as it is widely used and supported everything we needed.
We explored a number of “creative” ideas — some of them best left forgotten — before settling on an acronym that captured the essence of the tool we were building: RAUC — the Robust Auto-Update Controller.
Our customers received and integrated an early version of RAUC in June 2015.
First Public Steps, First Release
In the months following its initial commit, RAUC grew steadily. Although it was public from the start, it initially received little attention outside our circles — which allowed us to focus on refining its architecture and ensuring it worked reliably on various embedded hardware.
Eventually, it became clear that RAUC deserved a wider audience. We began reaching out to the Embedded Linux ecosystem:
- We registered the domain rauc.io and set up a minimalistic website — just enough to introduce RAUC and help people get started.
- In February 2017, RAUC made its conference debut at FOSDEM in Brussels, with a dedicated talk in the Embedded Devroom.
- That same year, we also presented RAUC at Chemnitzer Linux-Tage (CLT), increasing visibility in the German Linux scene.
Of course, no public-facing project is complete without a logo — and in 2017, we faced the surprisingly hard task of choosing one. What started as a few design ideas quickly turned into a long thread of iterations, feedback, and more iterations… until no one could see any design proposal ever again without squinting. Eventually, we settled on a logo that stuck — clean, simple, and recognizable.
Around that time, we also moved the code from our personal GitHub repository to the newly created rauc GitHub organization, signaling its transition from a company-driven project to a collaborative effort.
And in February 2017, after 581 commits and nearly two years of continuous development, we tagged our very first official release: RAUC v0.1 🎉
A Turning Point
Development of RAUC continued steadily — still driven in large parts by Pengutronix customer projects, but increasingly shaped by external contributions from a growing community of users and developers.
For the next release, v0.2, in November 2017, I wrote the very first post in this blog. And many others followed, all collected under the rauc tag. In 2018, after a string of releases up to v0.4, we came to the conclusion that sometimes you just have to draw a line and say: this is solid. And so we did — and tagged the next release as v1.0.
Things went on rather smoothly and predictably after that... until late summer 2020, when we received an unexpected email from the security research company JFrog (formerly Vdoo).
They had discovered a potential TOCTOU (Time-of-Check to Time-of-Use) vulnerability in RAUC's bundle verification process — a race condition that, under certain circumstances, could theoretically be exploited during update handling. This marked the first time RAUC was assigned a Common Vulnerabilities and Exposures (CVE) ID: 🔒 CVE-2020-25860.
While mitigation was possible, the issue exposed a conceptual gap in how RAUC verified bundle integrity at runtime. We saw this as an opportunity to not only patch the immediate problem but rethink how verification could be made more robust by design.
This led to one of the most significant developments in RAUC’s history: the introduction of dm-verity-based bundle verification, released with RAUC v1.5.
The process took three months of focused work — from initial report to coordinated disclosure — during which we collaborated closely with JFrog and prepared documentation, mitigation strategies, and the technical overhaul required.
In the end, the new bundle format didn’t just fix a vulnerability — it paved the way for a series of new features in RAUC, like HTTP bundle streaming, full bundle encryption, and adaptive updates.
Proven in the Field
Over the years, we’ve put a lot of effort into making RAUC accessible, understandable, and ready for the real world. We’ve polished slides and graphics for countless conference talks, improved the documentation, refined the user experience — and answered more than a few late-night emails and questions on our Matrix channel.
But back when it all started, we honestly had no idea whether RAUC would gain real relevance. Like many open source projects, it began with a need, an idea, and a bit of optimism.
Today, looking back after a decade, it’s safe to say: we made it.
RAUC has grown into one of the most widely used open source, image-based OTA update frameworks for embedded Linux. We’ve seen contributions from more than 100 external developers, covering everything from bug fixes and new features to build system integration and documentation.
And while it’s always hard to know exactly who’s using your software in the open source world, we’ve heard of many impressive projects using RAUC — without any direct involvement from Pengutronix.
You’ll find RAUC...
- powering the Steam Deck from Valve,
- running on high-speed trains in Germany as part of the Linux4ICE platform,
- inside the IKEA Dirigera smart home hub,
- or as the update engine in platforms like Home Assistant OS.
to just name a few.
While RAUC started with the classic “USB stick update” use case in mind, it has since grown into a full-featured OTA framework — now powering systems that automatically poll for and apply updates in the field. This flexibility is what makes RAUC such a good fit across a wide range of embedded applications.
The Next 10 Years?
While we designed RAUC with OTA updates in mind from the very beginning, many early use cases were still based on manual methods like USB stick installation. Today, more advanced features — like automatic polling for updates — are actively being developed to support increasingly connected and autonomous systems.
We’re excited to see where the journey takes us next — and what new use cases, platforms, and ideas RAUC will support in the future.
If you’d like to get involved, contribute, or support RAUC, we’re always happy to welcome new folks to the community!
Finally, we owe a big thank you to everyone who has contributed along the way — whether through code, ideas, bug reports, or simply by using RAUC in the wild.
Further Readings
RAUC v1.14 Released
A week ago, we released RAUC version 1.14. This release — already the second in 2025 — adds support for ComposeFS artifacts, enhances the adaptive update experience, introduces new options for fallback prevention, and lays the groundwork for future features like polling-based update checks.
RAUC v1.13 Released
After several releases with smaller, more subtle changes, the v1.13 release marks a significant milestone for RAUC by introducing the initial version of the long-awaited artifact updates feature. The initial concept was created more than two years ago. In addition to this major feature, the release reflects extensive work on testing, stabilization, and a notable increase in community contributions.
RAUC v1.12 Released
With 93 pull requests that brought in 248 new commits, a lot happened since the last release on master (v1.11.1). The new v1.12 version of RAUC focusses on making it even more robust while adding some features and improvements.