iceoryx2releaserustcppcpythoncsharp

Announcing iceoryx2 v0.9.0

Christian Eltzschig - 18/05/2026

What Is iceoryx2?

iceoryx2 is a communication library designed to build robust and efficient data-intensive systems. It enables ultra-low-latency communication between processes - comparable to Unix domain sockets or message queues, but significantly faster and easier to use.

The library provides language bindings for C, C++, Python, Rust, and C#, and runs on Linux, macOS, Windows, FreeBSD, and QNX, with experimental support for Android and VxWorks.

iceoryx2 supports multiple messaging patterns, including publish-subscribe, events, request-response streams, and the blackboard pattern, a key-value repository implemented directly in shared memory. Its architecture is fully decentralized and does not rely on a central broker, which improves robustness and scalability.

To get a better impression of the performance characteristics, check out the iceoryx2 benchmarks and try them on your own platform.

Release v0.9.0

With v0.9.0, we continued pushing iceoryx2 toward embedded and mission-critical deployments. The main focus areas were better no_std testability, more robust decentralized recovery after process crashes, and many smaller developer experience improvements across Rust, C++, Python, Bazel, Docker, and the iox2 command-line tooling.

Take a look at the iceoryx2 v0.9.0 release notes to see the complete list of changes.

Another important announcement is that iceoryx classic, our trusted predecessor, will reach end-of-life at the end of this year. At the same time, we are happy to share that we plan to release iceoryx2 v1.0 before the iceoryx classic EOL. iceoryx classic has proven itself in millions of devices and has served the community reliably for many years. But iceoryx2 has now surpassed its predecessor in performance, stability, portability, and features. Therefore, it is time to fully focus on the next generation. If you encounter any issues during the migration from iceoryx classic to iceoryx2, we are happy to support you.

The main highlights of iceoryx2 v0.9 are:

no_std Test Support
Improved Decentralized Recovery
Developer Experience and Quality-of-Life Improvements

`no_std` Test Support

iceoryx2 could already be deployed to no_std platforms, but the test suite still required a std environment. This made it difficult to verify that iceoryx2 behaved correctly on embedded platforms where the Rust standard library is unavailable.

With v0.9.0, we added a custom test framework that allows us to run the test suite both on regular std platforms and on no_std targets. This is an important step toward making iceoryx2 easier to validate on embedded and bare-metal systems.

Currently, no_std still requires an implementation of our POSIX layer, and bare-metal support remains experimental. If you feel like experimenting, check out our bare-metal examples.

Improved Decentralized Recovery

iceoryx2 already provides a decentralized mechanism for identifying resources owned by dead nodes and cleaning them up. However, processes have an annoying habit of being killed at the worst possible moment. Even with robust cleanup logic, a process can still leave behind resources, or leak internal indices used by lock-free data structures that manage shared memory.

With v0.9.0, we introduced a lock-free robust unique index set that can survive process crashes and recover leaked indices. No matter when a process crashes, iceoryx2 can identify the stale state and clean it up. And this without requiring a central daemon or broker.

This is especially important for long-running systems where stale shared-memory resources must not accumulate over time. And the best part: recovery remains fully decentralized.

In the future, we want to combine this with a process launcher designed for mission-critical systems and portable across all platforms supported by iceoryx2. This would be the next step toward systems that can clean up, recover, and repair themselves in a decentralized way.

Developer Experience and Quality-of-Life Improvements

This release also contains many smaller improvements that make iceoryx2 easier to use, debug, deploy, and integrate.

iox2 service hz: The iox2 CLI tool can now show the send frequency of data in a service, including rolling-rate statistics and timeout support. This makes it easier to inspect live systems and quickly answer the question: “Is this service still publishing, and at what rate?”
RelocatableOption and RelocatableDuration: Rust’s standard Option and Duration types are not suitable for shared memory because their layout is not guaranteed to be ABI-stable. We added shared-memory-compatible alternatives that implement ZeroCopySend and can safely be used in payloads. In the future, we want to extend this further so that these types become memory-layout compatible with their C++ counterparts.
Degradation handler: Until now, iceoryx2 could handle back pressure with safe overflow behavior or BackpressureStrategy, but users had no direct callback or error value when a subscriber buffer was full and a sample could not be delivered. The new backpressure handler closes this observability gap. Check out the publish-subscribe-with-backpressure-example.
Global AllocationStrategy configuration: When sending dynamic data with iceoryx2, users can define an AllocationStrategy during service creation to control how memory is reallocated. Previously, deviating from Static always had to be done explicitly in code. With v0.9.0, this can now be configured globally in the iceoryx2 configuration.
Source UniqueNodeId in request-response headers: When a server receives a request, or when a client receives responses from multiple servers, it is useful to know where the message came from. Request and response headers now include the source UniqueNodeId, making it possible to identify the sending node.
Better Docker support with PID namespaces: iceoryx2 can now handle Docker deployments that use PID namespaces. Previously, resource recovery could run into clashes when different containers used the same process ID. The new handling avoids these conflicts and makes containerized deployments more robust.
Python blocking calls release the GIL: Blocking Python APIs, such as listener.blocking_wait_one(), now release the Python Global Interpreter Lock while waiting. This improves integration with multi-threaded Python programs and avoids unnecessarily blocking unrelated Python code.
Improved C++ diagnostics: iceoryx2 now provides a C++20 source_location implementation based on compiler builtins and uses it to improve Expected and Optional diagnostics on contract violations. This should make debugging incorrect API usage easier.

Commercial iceoryx2 Tools: ekxide Mission Control

ekxide follows an open-core business model. The core of iceoryx2 remains fully open source, while closed-source tools are used to finance continued open-source development.

In the upcoming weeks, we will release the first version of ekxide Mission Control and provide demo licenses to everyone interested in a debugging tool for iceoryx2.

The screenshot above shows Mission Control in action. It helps users monitor, inspect, and optimize iceoryx2-based systems by allowing them to:

track CPU and memory usage of the overall system and individual processes
inspect iceoryx2 nodes and services
log lifecycle events of iceoryx2 entities
analyze and optimize the iceoryx2 configuration down to memory pools and lock-free queues

Roadmap: What’s Next?

Looking ahead, we will continue improving no_std and bare-metal support with better documentation, more examples, and a smaller memory footprint.

At the same time, we want to make iceoryx2 easier to integrate into heterogeneous systems without compromising its zero-copy and safety-oriented design.

A major step in this direction is type-definition support. The goal is to use Rust payload types to generate compatible FlatBuffers, Protobuf, C, and C++ representations, making shared data models easier to use across language boundaries.

Another area we will improve is the event messaging pattern. Currently, notifications can be lost when the underlying socket buffer is full. We will rework this mechanism so that we can guarantee that event notifications are always delivered reliably.

Thank You

We want to thank our community. Your ideas, discussions, bug reports, and contributions help shape iceoryx2 every day. Even frustrating bugs become less painful when tackled with humor and openness.

A big thank you also goes to the iceoryx team, who were relentless in implementing these features and improvements.

And finally, a big thank you to our customers who help us to keep the development hight and share our vision:

To create an open-source zero-copy data plane for physical AI and mission-critical systems