NATS Blog
Posts from NATS maintainers, end users and community contributors. To write one, see the contributor guide.
How Cordum routes agent jobs over NATS
Yaron Torgeman
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.
NATS + Ignition MQTT: Sparkplug B from Edge to Subscriber
Alex Miller
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.
NATS Server 2.15 Release
Maurice van Veen, Neil Twigg, Daniele Sciascia
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: alwaysfor replicated streams. While we won’t cover every change here, we’ll highlight the most impactful ones.Laravel NATS: A Production-Ready Bridge for PHP Applications
Zaeem
PHP powers a large share of the web, and Laravel is one of its most widely adopted frameworks. Teams building event-driven services, background workers, and microservice boundaries in Laravel need messaging that is fast, simple to operate, and easy to wire into familiar Laravel patterns: facades, service providers, queue workers, Artisan commands, and configuration via
.env.Laravel NATS is an open source package that brings NATS and JetStream into Laravel applications without forcing developers to re-learn their framework. It wraps the basis-company/nats PHP client with Laravel-native configuration, a JSON message envelope, queue drivers, JetStream helpers, and production-oriented features such as idempotency, observability hooks, and optional subject ACLs.
Building a Wallet Event Backbone with NATS JetStream: Lessons from BroSettlement's Staging Tests
Vadym Rozov
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.
Coordinating Teams of AI Agents in Real Time on NATS and JetStream
David Farah and Sven Jonscher
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.
What's old is new: A NATS-native protocol for AI agents
Andrew Connolly
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.
NATS Server 2.14 Release
Maurice van Veen, Neil Twigg, Daniele Sciascia
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.
NATS Server 2.12 Release
Neil Twigg & Maurice van Veen
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!
How Sophotech Cut Latency by 3x Migrating from RabbitMQ to NATS
Synadia
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.