About Verrus
Verrus is a flexible data center company attacking one of the AI economy’s tightest constraints—the gap between exploding compute demand and a power grid that can’t keep up—from the power side. Rather than drawing energy like a traditional facility, Verrus treats battery energy storage as a shock absorber, leaning on the battery to flex power demand down when the grid needs it and participating in programs like demand response—all without ever disrupting the customer’s IT load.
The result is a data center designed to be roughly 30% more efficient than a traditional facility by being far less resource-intensive. Making the enormous, continuous load of a data center flexible on the utility grid without touching compute is a new approach, and it carries real design challenges around electrical topology.
Challenges
Before NATS, Verrus needed to move several very different kinds of data and control signals across on-premise systems, the cloud, and a customer-facing interface. Three challenges stood out, along with a hard requirement that none of them compromise security or correctness.
-
Real-time transparency: Verrus wanted to give customers a near real-time view into the electrical topology—graphing IT load against power utilization—something third-party data centers rarely expose. That required exfiltrating telemetry from on-premise systems out to a customer-facing interface.
-
Device intelligence: The battery energy storage system needed constant monitoring—pulling statistics over time, understanding performance, and enabling predictive maintenance across equipment.
-
A messaging backbone: Verrus needed to accept demand-response requests from utilities, proxy those through to customers, and coordinate a growing mesh of internal microservices.
-
High availability without lock-in: The operational technology (OT) world’s default is MQTT, and Verrus started there—but quickly hit a wall. Clustering MQTT brokers isn’t native to the protocol, vendor solutions threatened lock-in, and open source options didn’t cluster at all.
Technology Environment
Verrus began on MQTT, the OT-world standard for moving data off devices at the edge. While MQTT works well at the edge, its statefulness—reflecting its origins in command-and-control rather than stateless publishing—made it a poor fit for the high-availability, publish-to-everyone architecture Verrus was building toward.
The team writes most of its application stack in Rust, runs its SCADA system in Java, and stays deliberately polyglot. Inside each data center, legacy OT protocols like Modbus remain stubbornly point-to-point, requiring hard-coded IP addresses and ports. Verrus needed a single substrate that could unify all of it—edge to cloud, device to microservice, telemetry to control—without standing up four or five different tools and a handful of operators to run them.
NATS.io
NATS wasn’t in the original stack. After repeatedly hearing peers mention a “pub/sub thing” called NATS, Coco—who spent years on the IT side of the industry, including a long stretch at Twitter scaling the RPC stack—dug into the talks and docs and realized it was far more than pub/sub. What struck him was how much power emerges from very simple primitives, the fact that it’s open source, and how dead simple it was to get started.
NATS became the backbone of Verrus’s unified namespace—an OT concept in which publishers push into a single universal namespace and any authorized consumer can subscribe, replacing brittle point-to-point wiring. Effectively, NATS became the data plane connecting each data center to the cloud.
- A single substrate, not two systems bolted together: Telemetry streams in real time into the cloud, where Verrus runs predictive and optimization analysis, then shunts a slice of that data into the customer interface for subscription. Because NATS offers request-reply alongside pub/sub, Verrus builds microservices on the very same data plane that query each other and query data—a single substrate that serves as both a telemetry system and a queryable data plane.
-
Two-way control, securely: OT/IT convergence almost always starts with telemetry; Verrus closed the loop to interrogate devices and build a real two-way street. NATS’s built-in security model—nkeys and a zero-trust posture—mapped cleanly onto the architecture Verrus was already building, making the two “very simpatico.” As Coco put it, “I keep getting blown away by the feature set that is there. Every time we delve into another piece, it’s like, oh, this is already there.”
-
JetStream and KV in heavy use: Both JetStream and the Key/Value store are in heavy use, and the team is exploring the object store as a building block for an entire digital twin over the NATS substrate.
-
Proxying legacy OT protocols: Verrus built proxies through NATS for point-to-point protocols like Modbus. Devices are now referenced by a logical subject name; NATS maps that name to the current IP and port, and if anything changes, the team simply updates the mapping—no client or customer needs to know.
-
Lightweight service mesh: Using subject-based messaging for service discovery, Verrus got a lightweight mesh just by having services talk through NATS—without standing up a full service mesh or pulling something off the shelf.
-
Correctness and security over scale: Coming from hyperscale environments, Verrus made a deliberate inversion—prioritizing correctness and security over raw throughput. NATS delivers request-reply semantics, queue groups, interest-based topics, and atomic matching out of the box. The scale is there when needed: Verrus runs leaf-node-to-cloud clustering and super clusters across regions, all within one system.
-
MQTT where it still makes sense: NATS supports MQTT and even Sparkplug B, so Verrus can run NATS as an MQTT broker at the edge where the OT standard remains genuinely useful.
Synadia Platform
Verrus uses Synadia’s control plane to bootstrap its NATS clusters. A fully exposed API lets the team integrate with their orchestration layer, bootstrapping credentials and baseline cluster configuration, wired up through Crossplane to actuate cluster deployment. Operationally, Coco reported, it’s been solid—better than most of what the team has to deal with.
As Verrus adds buildings and customers, the scaling story stays clean. Each building runs an on-premise cluster that leaf-nodes up to the cloud topology. As new buildings come online, the super cluster grows, with the option to partition into sub-super-clusters grouped by campus or site. Importantly, none of this requires touching the data center to onboard a customer.
Results
NATS gave Verrus a single, open-source substrate to run a flexible, AI-era data center—consolidating telemetry, control, service discovery, and legacy-protocol abstraction onto one data plane.
-
Architectural consolidation: One system serves as both a real-time telemetry system and a queryable data plane—replacing what would otherwise be four or five different tools and a handful of operators.
-
Real-time customer transparency: Telemetry flows from on-premise systems to the cloud and into a customer-facing interface, giving customers a near real-time view of IT load against power utilization.
-
Secure, two-way control: nkeys and a zero-trust posture enabled Verrus to move from one-way telemetry to secure device interrogation and control.
-
Operational simplicity: Running NATS has been easier than running Kubernetes, with Synadia’s control plane and a fully exposed API handling cluster bootstrap and lifecycle.
-
Clean horizontal scaling: Leaf-node-to-cloud clustering and super clusters across regions let Verrus add buildings and customers without touching the data center to onboard—growing the topology like “complex Lego-block topologies.”
-
Operational flexibility: Proxying OT protocols like Modbus through NATS let Verrus escape point-to-point topologies entirely, referencing devices by logical subject name and remapping them without client or customer awareness.
-
Polyglot freedom: Solid SDKs for Rust, Java, and beyond—plus a protocol that’s headers and bytes at its base—mean almost anything on the network can move through NATS.
This story is drawn from a conversation recorded as part of the RethinkConn customer story series, spotlighting the teams building real systems on NATS and Synadia. Watch the full conversation with Christopher Coco for a deeper look at how Verrus is building a flexible data center backbone on NATS. Our thanks to Christopher Coco of Verrus for sharing the journey.
If you’re looking to replace your MQTT broker at edge locations, get in touch with a NATS expert.
