# Ariel OS: an operating system written in Rust for low-power devices > Ariel OS is a Rust operating system for secure, memory-safe, low-power IoT hardware, assembled by integrating crates from the embedded Rust ecosystem rather than by building a stack from scratch. Its MSRV is Rust 1.98, it is dual licensed, and it targets 32-bit microcontroller architectures only. **ariel-os/ariel-os** — Ariel OS is a library operating system for secure, memory-safe, low-power Internet of Things, written in Rust - Repository: https://github.com/ariel-os/ariel-os - Website: https://ariel-os.org - Stars: 1,242 · Forks: 115 - Language: Rust - License: Apache-2.0 - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/ariel-os-ariel-os ## A Rust operating system aimed at constrained devices Ariel OS describes itself as an operating system for secure, memory-safe, low-power Internet of Things devices, written in Rust from the ground up. The security and memory-safety claims follow from the language choice rather than from a feature list, which is the entire reason the project exists as an operating system instead of being another set of embedded crates. The hardware target is narrow and specific. The README states that Ariel OS supports hardware based on 32-bit microcontroller architectures, naming Cortex-M, RISC-V and Xtensa. That is a constraint with real consequences. If you are building firmware for one of those families, the project is relevant. If your target is a 64-bit host, a server class processor or any architecture outside those three, there is nothing here to build on. The project is hosted at ariel-os.org, is not archived, and the last push was on 2026-10-19, so it is an actively moving codebase. Copyright is held by Freie Universität Berlin, Inria and Kaspar Schleiser, covering 2020 to 2026, which places the project in the academic and research world rather than in a commercial vendor's portfolio. ## Integration rather than reinvention The design decision that defines Ariel OS is that it does not try to own the low-level embedded Rust stack. The README lists the projects it builds on: Embassy, esp-hal, defmt, probe-rs, sequential-storage and embedded-test. Each of those occupies a specific layer of the embedded Rust stack, covering asynchronous execution, vendor hardware support, logging, flashing, storage and on-target testing. The README is explicit about the gap that motivated the project: while those projects provide high-quality building blocks for a wide range of embedded applications, they do not provide the high level of integration that developers know from contemporary C-based operating systems for microcontrollers. The claim is not that the building blocks are weak, it is that you still have to assemble them yourself. So Ariel OS is best understood as an integration layer. You keep the crates you would have written anyway, and you get the integration on top. ## What Ariel OS adds: scheduler, peripheral APIs, network security Three additions are named explicitly in the README, and they describe the shape of the operating system layer. The first is a preemptive multicore scheduler. Preemptive means a thread can be suspended at a scheduling point and another thread of higher priority runs, rather than only switching at explicit yield points, and the multicore part means it operates across more than one core. The workspace confirms this is a first class concern rather than a slogan, with dedicated benchmark crates named bench-sched-flags and bench-sched-yield under tests/benchmarks, and a set of threading test crates covering dynamic priorities, floating point use, locks, mutexes and an FPU test. The second is portable peripheral APIs. The workspace members make the scope visible: ariel-os-hal for the hardware abstraction layer, then family specific crates for nRF, STM32 and ESP hardware, plus ariel-os-power, ariel-os-random, ariel-os-storage, ariel-os-log, ariel-os-identity and ariel-os-sensors, with a sensors registry and a set of concrete sensor drivers for parts such as the AHT20, LIS2DU12, LPS22DF, STTS22H and an nRF91 GNSS module. The third is additional network security facilities, alongside dedicated crates for CoAP with a coapcore library, a ringbuffer, and a CoAP test suite. ## laze holds the build together The integration is assembled by laze, which the README describes as a meta-build system to bind it all together, maintained as its own project. A meta-build system is a layer above the build tool. Cargo already exists in the workspace, and it can still be used, but the README's description is that laze binds the pre-existing crates and the operating system code together. For a project that supports three architecture families, dozens of boards and a long list of optional subsystems, deciding what goes into a firmware image is a decision that has to live somewhere, and laze is where it lives here. The repository layout reflects the two build systems coexisting. There is a laze-project.yml at the root alongside Cargo.toml and ariel-os-cargo.toml, a.cargo/ directory, a boards/ directory for board definitions, a scripts/ directory and a supply-chain/ directory. The examples carry their own laze.yml file, and each example is a separate workspace member, which means an example can be built on its own rather than only as part of a whole firmware image. ## The workspace in Cargo.toml and the hello-world default member The root Cargo.toml is the clearest map of the project. It declares a workspace with resolver version 3, an edition of 2024 and a rust-version of 1.98, and the members list covers the examples, the ariel-os crates, the library crates, the sensor drivers and the test suites: ```toml [workspace] resolver = "3" members = [ "examples/*", "src/ariel-os", "src/ariel-os-alloc", "src/ariel-os-bench", "src/ariel-os-boards", "src/ariel-os-buildinfo", "src/ariel-os-buildutils", "src/ariel-os-coap", "src/ariel-os-debug", "src/ariel-os-embassy-common", "src/ariel-os-esp", "src/ariel-os-hal", "src/ariel-os-identity", "src/ariel-os-log", "src/ariel-os-macros", ] ``` The list continues into the remaining ariel-os crates, the src/lib and src/sensors trees and the tests directory, and the whole set is far too long to read in one sitting. Two lines are worth isolating though. The workspace excludes src/lib and doc from the members list, and it sets a default member: ```toml default-members = ["examples/hello-world"] ``` That default is the answer to the getting started question. The README points you at the Getting Started page in the User Guide and at the hello-world example, and says the example can be running in less than 5 minutes. The example tree also shows the breadth of what the operating system offers: ble-advertiser, ble-scanner, coap-client, coap-server, http-client, http-server, tcp-client, tcp-echo, i2c-scanner, spi related work in the test suite, storage, sensors, power, alloc, benchmark, log, random, gpio and threading examples. ## MSRV, dual licensing and the contribution rules Ariel OS compiles with stable Rust 1.98 and up, and the README states that the MSRV can be increased in patch version updates. That second sentence is the one to note. A policy that allows the minimum supported Rust version to move in a patch release means your toolchain can need an upgrade without a major version bump, which matters for CI images and for organisations that pin compiler versions. The workspace package section records the same number, with a comment noting that some individual crates may have a different MSRV. Licensing is a choice rather than a single grant. The project is licensed under either the Apache License 2.0 or the MIT licence, at your option, with both LICENSE-APACHE and LICENSE-MIT in the repository root and the workspace package license field recorded as MIT OR Apache-2.0. Contributions carry the same rule. The README states that unless a contributor explicitly says otherwise, any contribution intentionally submitted for inclusion is dual licensed under both licences with no additional terms or conditions. Contributors are also pointed at a contributing guide, and the repository carries a CODE_OF_CONDUCT.md, a GOVERNANCE.md and a CITATION.cff, which is a sign of a project that expects academic and institutional use. ## How it differs from RIOT and Zephyr, and where it is the wrong tool The README names the comparison itself. Ariel OS exists because crates like Embassy and esp-hal do not give you the high level of integration that developers know from contemporary C-based operating systems for microcontrollers, and it gives RIOT and Zephyr as the examples of that familiarity. The difference in approach is the language and the assembly model. RIOT and Zephyr are C based systems that the README presents as the reference for the level of integration developers expect. Ariel OS keeps Rust as the interface and builds its integration on top of independently developed crates, which means you can pick up individual components without adopting the whole system, at the cost of a young project whose components do not share a single author's design. The wrong-tool cases are clear. If your hardware is not a 32-bit Cortex-M, RISC-V or Xtensa microcontroller, this project does not apply. If you need a vendor support contract, a published release train or a long track record of API stability, the repository's own signals argue against it: it has no GitHub releases at all, keeping its history in a CHANGELOG.md, and its roadmap file exists precisely because features are still planned. If you are writing a host side application or a Linux service, none of this is relevant. Ariel OS also asks you to accept a specific set of dependencies. The security story rests on Rust, but it also rests on defmt, probe-rs, Embassy and the rest, and a supply-chain/ directory plus deny.toml and criticalup.toml exist to keep those pinned and reviewed, which tells you the project treats dependency control as part of the job rather than an afterthought. ## Conclusion Adopt Ariel OS if you are writing firmware in Rust for a 32-bit microcontroller and you want an operating system layer with a preemptive multicore scheduler and portable peripheral APIs rather than a bare metal loop, and if you are prepared to work against a moving target. Do not adopt it for 64-bit hosts, for hardware outside the Cortex-M, RISC-V and Xtensa families, or if your organisation needs a platform with a long published release history, since the repository has no GitHub releases and keeps its history in CHANGELOG.md. Before you start, read the hardware support page for your board, confirm your toolchain is on Rust 1.98 or newer, and check the ROADMAP.md so you know which subsystems are still planned rather than shipped. ## FAQ ### What is Ariel OS and which hardware does it support? Ariel OS is an operating system written in Rust for secure, memory-safe, low-power IoT devices. The README states that it supports hardware based on 32-bit microcontroller architectures, naming Cortex-M, RISC-V and Xtensa. ### What Rust version do I need to build Ariel OS? The README states that Ariel OS compiles with stable Rust 1.98 and up, and that the MSRV can be increased in patch version updates. The root Cargo.toml records rust-version = 1.98 for the workspace package, with some individual crates possibly differing. ### How do I start with Ariel OS and the hello-world example? The README points to the Getting Started page in the User Guide, which gets the hello-world example running in less than 5 minutes, and the examples directory holds a laze.yml for each example. The workspace sets default-members to examples/hello-world, so that example is the natural entry point. ### What licence does Ariel OS use? Ariel OS is licensed under either the Apache License 2.0 or the MIT licence at your option, with both LICENSE-APACHE and LICENSE-MIT in the repository. Contributions are dual licensed under the same terms unless a contributor explicitly states otherwise. ## Sources - [ariel-os/ariel-os on GitHub](https://github.com/ariel-os/ariel-os) - [Issues](https://github.com/ariel-os/ariel-os/issues) - [License: Apache-2.0](https://github.com/ariel-os/ariel-os/blob/main/LICENSE) - [Project website](https://ariel-os.org) - [README](https://github.com/ariel-os/ariel-os/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ariel-os-ariel-os