Canonical’s Zenoh Snaps Turn ROS 2’s Middleware Fix Into a Packaging Decision

ROS 2 was designed to let robotics developers swap out the network layer underneath their code without touching application logic. That flexibility has been mostly theoretical for years: almost every ROS 2 deployment has run on some flavor of the Data Distribution Service (DDS) standard, the middleware ROS 2 has shipped with by default since 2017. On September 15, Canonical published a guide for packaging Zenoh, the middleware Open Robotics formally recommended as a DDS alternative three years ago, as a snap. The guide itself reads like routine packaging documentation. What it actually represents is Canonical turning a protocol-level decision the ROS community made in 2023 into an operational choice that individual robotics teams can now make per deployment, without rebuilding their applications.

Why DDS Became the Thing Teams Wanted to Route Around

DDS is a real, mature publish/subscribe standard used well beyond robotics, and it remains ROS 2’s default middleware. But its default configuration relies on UDP multicast for node discovery, and that design choice creates specific, well-documented pain in production: discovery traffic grows with the number of nodes on a network, multicast is unreliable or unsupported outright on many Wi-Fi networks and cloud VPCs, and mismatched Quality of Service settings between a publisher and subscriber can fail silently instead of raising an error a developer would catch in testing. Teams running larger fleets, or robots that move between wired lab networks and wireless field deployments, have spent years working around this with manual sysctl tuning and hand-written XML configuration profiles.

Open Robotics, the organization that stewards ROS 2, took the complaints seriously enough to commission a formal evaluation. In a report published September 27, 2023 by the ROS 2 core team, the group concluded that “Zenoh best meets the requirements, and will be chosen as an alternative middleware,” adding that it “was also the most-recommended alternative by users.” The Eclipse Foundation, which stewards the Zenoh project, publicized the decision a month later, describing Zenoh as effectively “a modern version of the TCPROS implementation” from the original ROS 1.

What Zenoh Actually Changes

Zenoh, developed primarily by the company ZettaScale, replaces DDS’s multicast discovery with a router-based model: instead of every node broadcasting its presence to every other node on the network, nodes connect to a lightweight router, or to each other directly in peer-to-peer mode, which handles discovery and routing centrally. In benchmarks ZettaScale published comparing the two approaches on a representative ROS 2 graph, a discovery payload that took 251,576 bytes under default DDS shrank to as little as 82 bytes under Zenoh, a 97.37 percent reduction in the base case that reached 99.97 percent once Zenoh’s resource-generalization and warm-start optimizations were both enabled. ZettaScale attributes the gap to how sparingly Zenoh advertises itself: nodes announce resource interests rather than requiring every publisher to broadcast its own existence, and the underlying reliability protocol operates between whole runtimes rather than between every individual reader and writer pair the way DDS’s does. ZettaScale also describes its own wire protocol as carrying “a minimal overhead of only 5 bytes” and says it can run over TCP, UDP, QUIC, Unix sockets, WebSockets, serial links, and shared memory, a wider transport list than most DDS implementations support out of the box. “Zenoh provides an orthogonal set of primitives that, when composed, are allowed to represent Publish/Subscribe, Distributed Queries, and Distributed Computation,” ZettaScale CEO and CTO Angelo Corsaro has said of the design. The rmw_zenoh middleware implementation first shipped as an installable option with ROS 2 Jazzy Jalisco.

Canonical’s Three Packaging Paths

None of that history is new. What Canonical published this week is a concrete answer to a narrower, more practical question: once a team decides to use Zenoh, how does it actually ship that middleware to a fleet of robots running Ubuntu in a way that is reproducible, updateable, and confined the way production software is supposed to be? The guide, written by Canonical engineer gbeuzeboc, lays out three approaches and is explicit that they are not mutually exclusive.

Bundle the Middleware Into the Application

The first approach packages the Zenoh RMW implementation directly inside a ROS 2 application’s own snap, by adding ros-jazzy-rmw-zenoh-cpp as a stage package in the application’s snapcraft.yaml and pointing the RMW_IMPLEMENTATION environment variable at it. Canonical’s own talker_listener_zenoh_core24 example in the ROS snap examples repository demonstrates the approach against the standard ROS 2 demo nodes:

parts:
  ros-demos:
    plugin: colcon
    source: https://github.com/ros2/demos.git
    source-branch: jazzy
    stage-packages:
      - ros-jazzy-rmw-zenoh-cpp
      - ros-jazzy-ros2run
apps:
  talker-router:
    command: opt/ros/jazzy/bin/ros2 run demo_nodes_cpp talker
    plugs: [network, network-bind]
    extensions: [ros2-jazzy]
    environment:
      RMW_IMPLEMENTATION: rmw_zenoh_cpp

The result is a single, self-contained artifact a developer can move between a workstation and a robot without rebuilding, one that can run against either a dedicated Zenoh router or fall back to multicast scouting for smaller deployments.

Run the Router as Its Own Service

The second approach treats the Zenoh router as infrastructure rather than application code: it installs and runs independently of any ROS 2 application, via sudo snap install zenohd followed by sudo snap start --enable zenohd.daemon. Canonical ships the router disabled by default so operators decide when to turn it on, and once enabled, snapd manages it like any other confined system service, reading configuration from a snap-managed data directory rather than an arbitrary filesystem path. That confinement matters specifically because a router deployed in the cloud can let Zenoh-enabled robots on different networks reach each other over the internet, at which point authentication becomes a real concern; Canonical’s guide points teams toward Zenoh’s own TLS support for that case.

Bridge Existing DDS Applications Without Rewriting Them

The third path targets teams that don’t want to repackage anything at all: the zenoh-bridge-ros2dds snap runs the upstream Zenoh-to-DDS bridge, discovering existing ROS 2 nodes on their current DDS middleware and mapping that traffic onto Zenoh transparently. A robot’s existing nodes keep running exactly as configured; only the transport between the robot and the outside world changes. This is the option Canonical is positioning as the low-risk migration path, since it requires no application changes at all, only installing and enabling the bridge snap alongside a robot’s existing software.

Why Canonical Is the One Publishing This

Canonical’s interest here is not incidental. In August 2025, the company elevated its membership in the Open Source Robotics Alliance, the industry body that funds and governs ROS development, to Platinum status, the alliance’s top tier. “Robotics is evolving rapidly, and we are entering a new phase that will define the next era of automation,” Canonical VP of Engineering Olivier Philippe said at the time. “Open source has been the foundation of this growth, and ROS will remain central to scaling and deploying advanced robotics worldwide.” Open Robotics CTO Geoffrey Biggs, announcing the upgrade, called Canonical “one of the longest continuous contributors to open-source robotics,” citing its Ubuntu platform work, ROS contributions, and open-source security work specifically.

That membership carries a commercial logic. Canonical positions Ubuntu Core as an industrial-compliant pathway to production for robotics, and it sells Extended Security Maintenance (ESM) contracts that keep older ROS distributions patched after they lose upstream support, aimed squarely at teams that could not migrate off ROS Noetic before its May 2025 end of life. Snap-packaged Zenoh fits the same commercial pattern as ESM: Canonical positioning Ubuntu not just as a Linux distribution robots happen to run, but as the layer that makes ROS 2’s own middleware decisions operationally simple to act on.

Where the Decision Actually Lives Now

For a robotics team building on ROS 2 today, the practical effect is that escaping DDS’s discovery problems no longer requires understanding Zenoh’s internals, compiling a custom RMW implementation, or auditing a fleet’s application code. It requires choosing one of three snap install commands, based on whether the team is starting a new application, standing up shared infrastructure, or migrating an existing deployment without touching it. Open Robotics made the protocol-level call in 2023. Three years and one ROS 2 LTS release later, Canonical’s packaging work is what turns that call into something a platform team can actually schedule.