rs-matter: a pure Rust Matter implementation for tiny MCUs

A toolkit rather than a finished product

rs-matter is described as a pure Rust, no_std, no-alloc, async-first implementation of the Matter protocol, and the constraint list is the interesting part. No standard library and no allocator means the crate can sit on a microcontroller, and the claimed range runs from bare-metal parts with 1MB of flash and 256KB of RAM up to ARM embedded Linux and larger machines. The framing is deliberately not a shrink-wrapped product: the project calls itself a toolkit first, and says users are free to consume all of the APIs, including the provided system clusters, or to pick up only pieces.

That choice changes what you are adopting. You are adopting a set of building blocks, including a transport layer, a Secure Channel and an Interaction Model, and you decide how much of the protocol stack you want to own. The result is more work in the short term and more control later, which is a reasonable trade for a device that has to run on a part with 256KB of RAM. The code is Apache-2.0 licensed and published on crates.io, and the last push was on 2026-10-19 with no tagged releases in the repository, so the version you get is the one you pin.

The pieces you can take or leave

The project enumerates what a user may do with the crate, and the list is effectively a menu of extension points. You can switch features on and off, including the sizing of the basic structures for small or large devices. The IP network implementation and the BLE GATT peripheral and central implementations are pluggable. You can write custom Exchange responders and supply your own mDNS provider. You can reuse the transport layer and the Secure Channel while implementing your own Interaction Model, which is the route for a device that needs a device type the library does not cover. The futures can also be polled flexibly, for example as separate tasks in whichever async executor you prefer, so the crate does not dictate your runtime.

The alternative to all of that is the shrink-wrapped arrangement in the separate rs-matter-stack repository and its downstream crates, which the documentation points to when you would rather not do the bootstrapping. The examples directory shows what the result looks like in practice, and the source of one of them is worth reading because it is short and shows the handler structure:

//! An example Matter accessory that implements a Speaker device over Ethernet.
//! Demonstrates how to make use of the `LevelControl` and `OnOff` cluster handlers,
//! and how to run a Matter device over Ethernet with mDNS discovery.

The file continues with the cluster handler imports and the device logic, but those three lines already set out the shape: a device type, the clusters it implements, and a transport.

Porting to your own board means implementing traits

Running the protocol on hardware is handled by ports, and the project is clear about who owns what. For bare-metal microcontrollers with the Embassy framework, the rs-matter-embassy crate covers Espressif ESP32XX parts, the Nordic nRF52840, and the RP2040 Pico and Pico W. For Espressif parts running on the ESP-IDF, the esp-idf-matter crate is the route. For any other vendor SDK, the answer is that you implement the rs-matter platform traits yourself, in the same way the Embassy and ESP-IDF ports do.

That is the main practical cost of the toolkit approach, and it is front-loaded: the porting work is per vendor, not per product, but it is real work that the shrink-wrapped stack would have absorbed. Once a port exists, though, the protocol code above it is shared, which is where the value is if you are shipping a family of devices rather than a single one. The repository also contains a bloat-check directory, which suggests the project treats binary size as a tracked concern rather than an afterthought.

Matter 1.6, tested ecosystems, and a certification gap

The project describes itself as relatively feature complete, and says it can be used to implement accessories, which is the typical case, as well as controllers and commissioners. The supported Matter specification version is 1.6. Provisioning and operating under the major smart home controllers is stated to work, and the list of tested environments is specific: Google Home, Apple HomeKit, Alexa, Home Assistant, Samsung SmartThings and the IKEA Dirigera Hub.

The honest part is what comes next. The API is not stable and is likely to still see backwards incompatible changes, though the project expects the blast radius to be more limited now. The next steps list includes even more memory optimisation, with the smallest configuration sitting at roughly 60KB of BSS and 20KB of stack, more flash trimming, with a minimal firmware using the Embassy port plus Thread and BLE coexistence on the nRF52840 weighing in the region of 600 to 650KB, enabling more of the ConnectedHomeIP YAML and Python tests, and working towards certification of a product built on top of rs-matter. That last item is the one to read twice: the library gets you a device that works, and the certification is still work you own.

Running the official Matter test suite locally

Because interoperability is the whole point of a protocol implementation, the test story matters more here than in most projects. The standard CI runs on every push and pull request, with build, test and lint steps across multiple feature combinations, which is how a crate with this many optional configurations avoids breaking one of them silently.

The more interesting half is the ConnectedHomeIP integration, which runs the official Matter test cases through native Rust tooling provided by the xtask crate. The command for running them locally is documented, there is automated nightly execution in CI, and the project describes an iterative test enablement workflow for developers. Enabling more of the YAML and Python tests is listed as an ongoing task, so the coverage is real but partial, and the fact that the official suite is run in Rust rather than through the reference implementation is a meaningful difference when you are debugging a conformance failure.

The build profile is tuned for flash

The workspace manifest shows the engineering priorities. The workspace holds the main crate plus the macro and code generation crates, the examples and the tests, and the version is 0.4.1 with edition 2021 and a minimum Rust version of 1.87. The release profile is tuned for size rather than speed, and the build script is given its own optimisation level, with the reason stated in a comment:

[profile.release]
opt-level = "z"
debug = 0
debug-assertions = false
codegen-units = 1 # LLVM can perform better optimizations using a single thread
lto = "fat"
incremental = false
overflow-checks = false

The comment above the build overrides explains the other half, that the build scripts and proc macros are run optimised, because the build script of the main crate generates about 30MB of cluster code from the Matter IDL and takes several times longer when it runs unoptimised, which is the default for build scripts. A first build of this crate is therefore slow for a reason, and knowing that in advance saves a lot of confusion.

Nix shells, and the documentation that does not exist yet

The project supports the nix package manager with two shells for two purposes, and the distinction is explained rather than implied. The devenv.nix file is for normal development of applications, entered with a devenv shell command in the project root, and it requires devenv to be installed. The shell.nix file is for the cases where tools expect a standard Linux filesystem layout, entered with nix-shell in the project root, and it is the one to use when running the integration test command, because it sets up connectedhomeip, which expects that layout. For nix managed systems the documentation says to add pkgs.devenv to environment.systemPackages.

The documentation gap is the other thing to plan around. The project says there will be an rs-matter Rust Book in the future, but for now points to the examples, the docs directory and the code documentation, and the discussions page for questions. The repository layout backs that up, with a docs directory, an examples directory, the macro and code generation crates, a tests directory, the xtask directory excluded from the workspace, and files for contribution, security and a code of conduct.

Editorial conclusion

rs-matter fits a hardware team building a Matter accessory that has to fit in a small microcontroller and wants a Rust codebase instead of a C SDK, since the footprint numbers in the documentation are specific enough to plan against and the Matter specification version is known. It is the wrong choice if you want a product you can ship without a certification effort, because the project lists working towards certification as a next step rather than a finished state, and it is the wrong choice if you need a stable API, since backwards incompatible changes are still expected. Before you start, read the examples and the docs directory, since the promised Rust Book does not exist yet, check the footprint of the smallest configuration against your flash budget, and pick a port deliberately, because only the Embassy and ESP-IDF ports exist and any other vendor SDK means implementing the platform traits yourself.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. project-chip/rs-matter on GitHub
4. README