One key space carries messages, queries, and stored data
Zenoh uses the same named data space for publish and subscribe traffic, query and reply, storage, and computation. That is the decision-making fact. A sensor can publish a value, another participant can subscribe, and a queryable can answer a request without introducing a separate API vocabulary for every path. Teams already stitching together a message broker, service calls, and an edge cache may find that model easier to reason about. Teams with one simple queue probably will not.
The Rust repository contains the primary zenoh crate, zenoh-ext, the zenohd router, plugin support, internal common crates, and examples. Public stability applies to zenoh and zenoh-ext; the README says internal commons APIs may change at any time. Advanced publisher and subscriber types add stronger delivery behavior, while serialization in the extension crate is intended to work across bindings. Each feature deserves a workload test because the README's architecture description is not a latency guarantee.
Zenohd can listen, connect, discover, and host plugins
The router accepts repeated listen and connect endpoints, a JSON5 or YAML configuration, and a unique identifier of up to 16 bytes. By default it answers multicast scouting, while a flag disables that behavior. This gives operators a choice between local discovery and explicit topology. Networks that filter multicast will need configured endpoints or another reachable router path; container and cloud layouts should be tested with the real network policy.
Zenohd also manages plugins and can expose REST or storage functions through its bundled components. A requested plugin that fails to load makes the router exit, which is preferable to quietly running without a required service. The admin space defaults to read-only permissions, and command-line overrides can change nested configuration. Treat that configuration as production infrastructure: pin it, validate it, and keep write access away from clients that only need status.
What happened when we ran it
Our sandbox installed 526 Rust packages in 26 seconds for commit 9fcd9cb. The repository then built successfully in 406 seconds. The checkout was 8 MB with 790 files and about 214,777 lines of source. Those figures make Zenoh a substantial contributor build despite the compact checkout. The repository had 8 CI workflow files, no Dockerfile, and no tests directory in the supplied repository signal.
Cargo tests ended with exit code 101 after 757 seconds. The supplied summary counted 164 passed and 2 failed out of 166. In the log tail, callback_drop_on_undeclare reported 13 passed and 1 failed, then Cargo printed the command for rerunning that integration test. The tail does not identify the other failure or explain a cause, so the defensible result is simply that the complete suite did not pass in our fresh 3-CPU, 12 GB sandbox.
Several other groups shown in the tail passed, including groups of 40, 10, 6, 4, 2, and 7 tests. That does not cancel the red overall exit. A team evaluating Zenoh should rerun the named target on its deployment kernel and network settings, then run the full suite again. Callback cleanup and undeclaration touch lifecycle behavior, so a passing publish-and-subscribe demo is not a substitute for that check.
Dynamic plugins must match 3 build dimensions exactly
The router documentation gives a blunt compatibility rule: a dynamic plugin should use the same Rust version, the same Zenoh version or commit, and the same feature set as zenohd. Rust has no stable ABI for sharing these structures. The README warns that a mismatched plugin may be rejected, and an unchecked memory-layout mismatch can end in a segmentation fault. Package the router and plugins as one tested unit rather than upgrading either side independently.
The compiler floor has a second wrinkle. Zenoh itself supports stable Rust 1.75 or newer, but the main crate does not pin every dependency to that compiler because exact pins can create downstream conflicts. The repository supplies a separate pinned-dependencies crate for Rust 1.75 compatibility. If an organization fixes compiler versions for certification or long-lived devices, reproduce dependency resolution from a lockfile and verify every enabled feature before promising that floor.
Eight language APIs live across separate projects
The README links 8 language families: Rust here, two C options, plus C++, Python, Kotlin, Java, TypeScript, and Go. Most are bindings to the Rust implementation; zenoh-pico is the pure C exception. The TypeScript package is a WebSocket client for a router plugin. Language support therefore involves several repositories, release trains, and packaging systems rather than one monorepo build. Check feature parity and release compatibility for the binding you will actually deploy.
Bridges add another boundary. Separate plugins connect Zenoh to DDS and ROS 2 communications, while other repositories provide a web server and remote TypeScript API. This is useful when the network already has those systems, but a bridge is another process with configuration and version constraints. Choose Zenoh because its data model solves a topology problem, then treat each bridge as its own production dependency.
Three current reports concern router or shared-memory state
Issue 2800 reports a shared-memory provider stuck in an initializing state when requested before it is ready on version 1.10.1. Issue 2788 reports a failed shared-memory attach or memory lock dropping a sample and leaving partial metadata. Issue 2780 describes a router that stopped accepting new connections after restart while remaining alive. These are specific reports, not proof that every deployment will encounter the same conditions, but they belong in soak and recovery tests.
GitHub recorded 3,201 stars, 302 combined open issues and pull requests, and a last push on September 17, 2026. Release 1.10.1 shipped on September 7 with a new transport API method and fixes for scouting, REST content types, and pending connections. The same-day repository activity shows active maintenance. The 406-second build, failed 757-second suite, and exact-match plugin rule still make adoption an engineering commitment rather than a broker swap.