NATS Blog | NATS.io

Posts from NATS maintainers, end users and community contributors. To write one, see the contributor guide.
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.
Everything is in the nats-ignition repo.
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: always for replicated streams. While we won’t cover every change here, we’ll highlight the most impactful ones.
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.
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.
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.
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.
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.
Neil Twigg & Maurice van Veen
We are thrilled to announce that NATS Server 2.12 is here! 🎉
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