Your fleet stays in control on-site and visible from anywhere.
Onboard control never leaves the robot's own network. Latency and safety stay where they belong.
A realtime mirror of every robot reaches the cloud, so you can observe and step in from anywhere.
Drops into ROS 2 (Cyclone DDS, rmw_zenoh), native Zenoh, and MQTT setups without re-architecting your fleet.
It sits alongside. The robot keeps its ROS 2 middleware (Cyclone DDS or rmw_zenoh) for on-board comms — low-latency LAN-local fabric, exactly what those layers are tuned for. We add a sidecar that bridges DDS / Zenoh topics → CDR-on-MoQT → the cloud relay. Cloud subscribers (fleet ops dashboard, simulators, operators) speak our SDK, not DDS.
Two ways. (1) rmw_zenoh is a first-class ROS 2 middleware now — it replaces DDS for many fleets that want a unicast, peer-aware fabric without DDS's multicast assumptions. We bridge into our cloud relay the same way we bridge DDS topics, so the swap is transparent to your cloud subscribers. (2) Native [Eclipse Zenoh](https://zenoh.io/) workloads (non-ROS robots, edge sensors, MQTT-replacement deployments) plug directly into our MoQT fabric — Zenoh sessions on the south side, MoQT tracks on the north — without going through ROS at all.
DDS does discovery via multicast — WAN routers drop multicast. Zenoh does WAN better than DDS does, but neither gives you per-track auth, multi-tenant namespacing, or a 1000-fleet-deep relay tree. Our relay does. The on-robot fabric stays as-is (whichever you picked); only the cloud-bound edge of it talks our wire.
Every MoQT track is captured to object storage with frame-accurate timestamps. The Cruise viewer (over WebTransport) lets ops scrub time the way Foxglove does on bag files, but live. Bag files as a format are imported on the way in if you have an archive.
On an 8-vCPU GCE box we held 36,732 concurrent MoQT-over-WebTransport connections at 0.04 / 8 cores. The bottleneck wasn't the relay — it was the load fleet. For real workloads (more tracks/robot, real publish rates), 1k–5k robots / box is the practical envelope. Mesh fanout scales horizontally; the relay is shard-per-core (shared-nothing SMP) so adding cores adds capacity ~linearly.
Most MQTT topology survives. The substrate ships a broker-mode façade that speaks MQTT 3.1.1 / 5 on the south side and MoQT on the north. Existing MQTT clients keep working unchanged; new code talks to the cleaner MoQT API directly. Same pattern for Zenoh-fronted deployments — the fabric is whichever protocol your robots already speak; the cloud sees MoQT.
Telequick ships every modality on the same transport.