Consider a hypothetical infrastructure workflow: an agent proposes restarting a production service, but a person must approve the job before a worker can act. Approval must not be confused with completion, and an operator needs a trace from the original request to the recorded result. The restart operation is illustrative; the gateway, scheduler and worker boundaries below are the Cordum implementation being described.

I use NATS in Cordum to carry agent jobs from an API gateway to a scheduler and workers, then carry results back. Policy checks happen in the control plane. NATS supplies the messaging layer. Keeping those responsibilities separate makes the execution path easier to inspect, especially when a job is denied, held for approval or delivered again.

I’ve been building out an IIoT pipeline using NATS as the backbone for Sparkplug B telemetry from Ignition SCADA. This post covers the Docker setup: standalone NATS with JetStream and MQTT, Ignition Transmission publishing from the edge, and a Python subscriber decoding Sparkplug B on the other end.

No leaf nodes, no hub. Just a single NATS server you can drop anywhere and start connecting clients.

What we’re building

Ignition Transmission (edge)
        │
        │  MQTT / Sparkplug B  (tcp://<NATS_HOST>:1883)
        ▼
  NATS + JetStream (Docker)
        │
        │  NATS core  (nats://localhost:4222)
        ▼
  Python subscriber  (decodes Sparkplug B protobuf)

Everything is in the nats-ignition repo.

Previous NATS Server releases, like 2.12 in September of last year and 2.14 in April of this year, focused primarily on the addition of new and exciting features: atomic & fast batch publishing, counters, schedules, etc. The reliability of the server has been gradually increasing throughout as well, with better error handling and the squashing of tons of bugs, but it otherwise was mostly work performed in the background.

This release largely forgoes new features and instead focuses entirely on reliability and improving operations, including fully reworking how scales, moves, and peer-removes work, as well as improving stream backups, stream source recreate detection, and higher performance when using sync: always for replicated streams. While we won’t cover every change here, we’ll highlight the most impactful ones.

I am Vadym Rozov, founder of BroLabel , where we are building BroSettlement : API-first, noncustodial MPC wallet, ledger, and settlement infrastructure for fintech, iGaming, and crypto-native platforms. A wallet transaction is not one synchronous request. It moves through policy checks, MPC signing, blockchain broadcast, confirmation, ledger posting, and client notification, and any of those stages may be delayed or fail independently. We selected NATS early in the architecture—not as a replacement for another broker, but to avoid coupling every service through synchronous calls as the platform grew.

Guest post by David Farah and Sven Jonscher, creators of Cotal .

We build Cotal, the open standard for AI agents to work together in one shared space. Our first multi-agent prototypes taught us where the real difficulty lives: in the wiring between agents. Who can talk to whom? What happens to a message when the recipient is busy? Who is even online right now?

Most frameworks settle those questions for you by imposing a single shape, usually a controller handing out work to workers that never talk to each other. We wanted the shape to be configuration. A topology in Cotal is a graph: peers talk sideways in shared channels, pipelines hand work down a DAG of specialists, and a supervisor with workers is simply one of the shapes you can write down in a config file. To get there without reinventing a message bus, we built the entire contract on NATS and JetStream.

Agent systems are becoming distributed systems, and NATS already solves many of the communication problems those systems are rediscovering.

NATS has long been a natural fit for distributed, heterogeneous systems. No matter where your devices run, what languages your services use, or how ephemeral your clients are, it gives them a simple way to find and talk to one another. It also easily bridges different cloud vendors, geographies, runtimes, or hardware—with an integrated security model that naturally extends everywhere NATS does.

When we released NATS Server 2.12 back in September, we reflected on the need for shorter and more routine release cycles. While we slipped slightly beyond the intended six months due to increased activity on AI security reviews and disclosures, we’re happy to announce the release of NATS Server 2.14 today.

This release brings some new and welcome improvements, including first-class support for high-throughput publishing into JetStream, extended server-side message scheduling and correctness fixes for sourcing and mirroring with Interest and WorkQueue streams. While we won’t cover every change here, we’ll highlight the most impactful ones.

We are thrilled to announce that NATS Server 2.12 is here! 🎉

A successful 6-month release cycle

When we released the 2.11 version of the server back in March, we mentioned in our release blog that the 2.10.x series was our longest yet, having reached 26 patch releases.

With that, we have reflected on the need to be more predictable and transparent with our releases and have moved to a 6-month release cycle. This is not only important for us as maintainers, but more importantly our users for whose roadmaps may depend on new capabilities in NATS. Now, exactly 6 months later, we’re releasing server version 2.12!

After replacing RabbitMQ with NATS, Sophotech saw major improvements in performance and simplicity — here are their takeaways:

High-level overview

Sophotech migrated their ~50-service cluster from RabbitMQ to NATS. The change cut p99 latency from ~150 ms to ~40 ms, reduced ops overhead from several hours a week to under one, and eliminated queue lag during bursts (minutes -> seconds). Simpler subject-based routing also removed the need for complex RabbitMQ topology, making the system easier to operate and scale.

Important Notice for NATS.io Users on Bitnami Helm Charts

If you’re running NATS using Bitnami Helm charts, we strongly recommend migrating to the official NATS charts maintained by Synadia.

Why migrate now?

• Bitnami is deprecating the majority of it’s community tier helm charts, including NATS
• Legacy Bitnami images stop receiving updates on August 28th
• Future access to NATS via Bitnami will require a paid Bitnami Secure Images subscription

The solution:

Switch to the official NATS Helm charts, maintained by the team at Synadia