Is NATS deprecated?
No. The NATS server is actively developed, hosted by the Cloud Native Computing Foundation, and shipped under the Apache 2.0 license. The component people are thinking of is NATS Streaming, also called STAN, which was deprecated in favor of JetStream. JetStream is built into the same server binary, so there is no separate project to install.
What was actually deprecated
NATS originally shipped persistence as a second program. The core nats-server handled fire-and-forget publish/subscribe, and nats-streaming-server sat alongside it to add durable subjects, replay, and acknowledgements. Running two servers to get one messaging system was awkward, and the streaming server never gained the clustering story the core server had.
Synadia deprecated NATS Streaming in 2023 and archived its repository. Anything you read about STAN reaching end of life, or a NATS component being retired, is about that server. Searching for it today lands on deprecation notices, which is most of why the question gets asked at all.
The replacement is JetStream, which arrived in NATS Server 2.2 and is part of the core server rather than a companion to it. You turn it on with a flag:
nats-server -js
That gives you persistent streams, consumer groups with explicit acknowledgements, replay from a sequence number or timestamp, and per-stream retention and replication. Migrating from STAN means moving from channels to streams and from durable subscriptions to JetStream consumers, and the delivery semantics are stronger on the other side: at-least-once delivery with configurable redelivery, plus deduplication by message ID within a window.
The licensing episode is not a deprecation
The second reason people ask is governance rather than code. In 2025, Synadia, the company that created NATS and employs most of its maintainers, moved to reclaim the NATS trademark and relicense the server under a Business Source License. The CNCF objected publicly, and the two reached an agreement that kept nats-server under Apache 2.0 as a CNCF project.
That episode is worth knowing about when you evaluate any single-vendor open source project, but it is a licensing and trademark dispute, not an end-of-life announcement. The server that came out of it is the same Apache-licensed server, in the same foundation, with the same maintainers.
Signals that NATS is still current
Look at what a project ships rather than what people say about it. The server releases regularly, the CLI and the official clients for Go, Java, Python, Rust, and JavaScript track those releases, and JetStream has kept gaining features since 2.2. NATS is also the messaging layer inside other infrastructure, which tends to keep a project honest: if it stopped receiving fixes, the systems embedding it would notice first.
The confusion is easy to fall into because NATS is quiet in a way Kafka is not. There is less conference material, fewer managed offerings, and a smaller consulting industry around it. Low noise reads as abandonment when you are used to projects that market themselves continuously.
Should you start a new project on NATS?
NATS suits service-to-service messaging where latency and operational simplicity matter: a single binary with no external dependencies, subject-based addressing with wildcards, and request/reply as a first-class pattern. Add JetStream when a subject needs to survive a consumer being offline.
It is the wrong tool when you want a long retention window you can replay repeatedly, an ecosystem of connectors, or stream processing on top of the log. That is Kafka's territory, and Kafka vs NATS walks through the split. If your problem is routing rather than throughput, with per-consumer rules and dead letter queues as broker features, RabbitMQ vs NATS is the comparison to read instead.
One boundary is worth drawing explicitly. NATS moves messages between systems you operate. Sending events to your customers' servers is a different problem: those endpoints go down, verify signatures differently, and need retry schedules and delivery logs that your customers can see. That is what Svix does as a service, and it sits downstream of whatever internal broker you choose rather than replacing it.
Ready to send webhooks?
Svix handles signing, retries, rate limiting, and delivery observability for the webhooks you send to your users, so your team can stay focused on your product.
Start sending webhooks with Svix or read the build vs. buy analysis