Skip to content

NATS

Summary

NATS is a CNCF incubating, Apache-2.0 messaging system in a single Go binary. Core NATS gives at-most-once pub/sub, queue groups and request-reply (the docs' single-machine nats bench example averages 50.87 µs per request-reply round trip). JetStream, built into the same server, adds replicated streams, at-least-once and exactly-once (dedup + double ack) delivery, Key-Value and Object Store. Accounts give multi-tenancy, and clusters, gateways and leaf nodes let one subject space span data centres, clouds and edge devices. The current release is 2.15.0 (2026-09-17).

Overview

NATS targets cloud-native services, edge and IoT fleets, and multi-tenant platforms. Its distinguishing traits are a decentralized JWT security model (operator, account, user), account-level isolation of subjects and streams, and a leaf node + supercluster topology that connects sites without an overlay network.

Recent releases pushed JetStream well beyond a simple log: per-message TTLs and message tracing (2.11), atomic batches, counters and delayed scheduling (2.12), fast batch publish, cron schedules and reliable WorkQueue sourcing (2.14), and a desired-state meta-layer with evacuate and rescue operations (2.15). There was no 2.13 release.

Key Facts

Attribute Detail
Website nats.io
Repository nats-io/nats-server
Latest Version 2.15.0 (2026-09-17); previous line 2.14.7 (2026-09-15)
Release cadence Minor line roughly every 6 months (2.11 Mar 2025, 2.12 Sep 2025, 2.14 Apr 2026, 2.15 Sep 2026); patches every few weeks
Language Go (2.15.0 built with Go 1.27.1)
License Apache-2.0 (server, clients, CLI, NACK)
Governance CNCF Incubating since 2018-03-15; graduation application open since 2026-02 (cncf/toc#2042)
Trademark Held by the Linux Foundation since the May 2025 CNCF and Synadia settlement
Main sponsor Synadia (Synadia Cloud, Synadia Platform)
Stars ~16k+ (recorded by 2026-08)
Security advisories advisories.nats.io (28 security notes published 2026-02 to 2026-06)

Evaluation

Pros Cons
Low latency: the docs' single-machine nats bench example averages 50.87 µs per Core NATS request-reply round trip Subject hierarchy design needs discipline up front
Single static binary, no external dependencies (no ZooKeeper, no BookKeeper) JetStream R3/R5 failure modes (quorum loss, catchup) need study before production
Per-account multi-tenancy with strict subject isolation nsc and decentralized auth have a learning curve
Leaf nodes and gateways for edge and multi-region fabrics KV and Object Store inherit JetStream limits (no secondary indexes, chunked objects)
Official clients for Go, Rust, Java, .NET, JavaScript/TypeScript, Python and C, plus many community clients Not a drop-in Kafka replacement: no Kafka protocol, different consumer model and ecosystem
MQTT 3.1.1 and WebSocket listeners in the same process Smaller operations community than Kafka or RabbitMQ; many 2026 advisories hit MQTT/WebSocket/leaf code paths
JetStream KV and Object Store replace Redis or MinIO for light cases Upgrade rules between minors are strict (2.15 needs every peer on 2.14+)

Architecture

A supercluster of two clusters, a leaf node at an edge site, and one R3 stream replicated by Raft inside cluster A.

flowchart TB
    subgraph ClusterA["Cluster A (us-east)"]
        nA1["nats-server a1"]
        nA2["nats-server a2"]
        nA3["nats-server a3"]
        nA1 <--> nA2
        nA2 <--> nA3
        nA1 <--> nA3
        JS3[("JetStream stream ORDERS (R3 Raft group)")]
        nA1 -.- JS3
        nA2 -.- JS3
        nA3 -.- JS3
    end
    subgraph ClusterB["Cluster B (eu-west)"]
        nB1["nats-server b1"]
        nB2["nats-server b2"]
        nB3["nats-server b3"]
        nB1 <--> nB2
        nB2 <--> nB3
        nB1 <--> nB3
    end
    nA1 <-.->|"gateway :7222"| nB1
    subgraph Edge["Edge site (JetStream domain site17)"]
        Leaf["nats-server leaf"]
        Devices["Devices<br/>(MQTT / WebSocket / NATS)"]
    end
    Devices --> Leaf
    Leaf -->|"leaf node link :7422<br/>(account-bound)"| nA2

Component-level diagrams (server internals, request-reply, R3 replication, JWT trust chain) are in Explanation.

Use Cases

  • Microservice request-reply - replace internal HTTP with request-reply and queue-group load balancing; micro service framework in the official clients.
  • Edge and IoT fleets - leaf nodes at the edge with local pub/sub and a local JetStream domain that syncs to the hub.
  • Multi-tenant SaaS - one account per tenant gives subject and stream isolation without per-tenant clusters.
  • Distributed state (KV) - replicated KV buckets with watch and compare-and-swap for configuration, leases and sessions.
  • Object distribution - firmware, ML models and other files through Object Store buckets.
  • Cross-region pipelines - gateways plus stream mirrors and sources for regional data placement.
  • Scheduling and counters - delayed and cron-scheduled messages (2.12/2.14) and counter streams (2.12) without extra services.

Licensing and Pricing

  • NATS server, clients, nats CLI, nsc, NACK: Apache-2.0, free for any use.
  • Synadia Cloud: Synadia's managed global NATS service. Pricing is set by Synadia; check the vendor site.
  • Synadia Platform: self-hosted or Synadia-managed (including BYOC) deployment with Control Plane (UI and API for accounts, users, streams, KV, monitoring). Synadia also sells Insights (monitoring). Commercial terms are not public.

2025 licensing dispute, resolved

In April 2025 Synadia sought to take NATS out of the CNCF and move future server releases to the Business Source License. After the CNCF contested the trademark, both sides announced on 2025-05-01 that Synadia would assign its NATS trademarks to the Linux Foundation, that the nats.io domain and GitHub organisation stay with the CNCF, and that NATS remains Apache-2.0. Details in Explanation.

Ecosystem

Compatibility and Requirements

Requirement Detail
OS / CPU Linux, macOS, Windows, FreeBSD; amd64 and arm64, plus 32-bit ARM builds for edge devices
Storage (JetStream) Local filesystem for store_dir; NVMe recommended for replicated file streams
Network 4222 clients, 6222 routes, 7222 gateways, 7422 leaf nodes, 8222 monitoring; MQTT and WebSocket ports set explicitly (see Reference)
Memory Small for Core NATS; JetStream sized to working set. Since 2.12 tune GOMEMLIMIT because filestore caches respond to GC pressure
Container Official nats images (for example nats:2.15.0-alpine)
Upgrades One minor line at a time; 2.15 requires all peers on 2.14.0+ (How-to)

Latest Versions

Line Status (2026-09-25) Highlights
2.15.0 (2026-09-17) Current Desired-state meta-layer, cancel stream move, evacuate and meta rescue endpoints, backup/restore v2, 1,000-consumer default per stream
2.14.7 (2026-09-15) Previous line, patched Fast batch publish, cron schedules, WorkQueue/Interest sourcing, consumer reset, feature flags, Raft overrun protection
2.12.15 (2026-08-12) Older line Atomic batch, counters, delayed scheduling, mirror promotion, strict JetStream API
2.11.17 (2026-04-27) Older line Message tracing, per-message TTL, priority groups, consumer pause
2.10.29 (2025-05-01) Out of support (no patches since 2025-05) Auth callout, stream compression, route pooling

Full matrix and upgrade rules: Reference. Track releases at github.com/nats-io/nats-server/releases.

Alternatives

  • Apache Kafka - log-structured stream with a much larger ecosystem and heavier operations. Wins on replayable analytic streams.
  • RabbitMQ - AMQP broker with richer routing primitives (exchanges) and dead-lettering.
  • Redpanda - Kafka-API compatible single binary. Competes with Kafka more than with NATS.
  • Apache Pulsar - separated compute and storage, tenants and namespaces, geo-replication. Heavier to run.
  • MQTT brokers (HiveMQ, EMQX, Mosquitto) - MQTT only, often MQTT 5; NATS speaks MQTT 3.1.1.
  • Redis Pub/Sub and Streams - convenient inside Redis deployments, without NATS' multi-site topology or account model.

Migration and Lock-in

  • Subject vocabulary - subject hierarchies (orders.created.us-east.123) spread through code and permissions; mapping them to Kafka topics is non-trivial.
  • JetStream data - nats backup and nats backup restore move streams between clusters; mirrors and sources allow staged migrations without dual writes.
  • Auth - nsc-managed operators and accounts are NKey-based; export and store keys and JWTs before migrating.
  • Protocol - clients use the NATS protocol; the MQTT and WebSocket listeners help integrate devices and browsers without custom bridges.

Community Health

  • CNCF Incubating since 2018; graduation application in TOC due diligence as of 2026-09. The application lists a Trail of Bits audit (May 2025) and more than 2,000 documented adopters.
  • nats-server had 5 active maintainers per the graduation application, from Synadia and other organisations; client repos have 1-3 maintainers each.
  • Steady releases: four minor lines between March 2025 and September 2026, frequent patch releases, and a public advisories site.
  • Synadia funds most core development.

Topic Map

  • How-to Guides: topology choice, clusters, gateways and leaf nodes, security, streams, KV and object stores, Kubernetes, monitoring, troubleshooting, upgrades (2.15).
  • Reference: release matrix, ports, defaults, server config keys, stream and consumer fields, headers, system subjects, tooling versions, advisories, hardening checklist.
  • Explanation: subject routing, request-reply, routes, superclusters, leaf nodes, JetStream Raft layers and file store, decentralized security, 2025 governance episode.

Sources

Questions

  • What is the practical ceiling for JetStream streams and consumers per cluster before meta-layer Raft load bites? Does the 2.15 desired-state meta-layer change it? The new 1,000-consumers-per-stream default hints at operational limits.
  • How does gateway bandwidth behave when many accounts switch to interest-only mode with wide subject filters? No public measurement against Kafka MirrorMaker 2 or Cluster Linking.
  • For Object Store, what object size makes chunking overhead dominate throughput compared with MinIO or S3?
  • What is the support window for older minor lines now that 2.15 is out? NATS publishes no EOL policy; 2.12 and 2.11 still received patches in 2026, but no 2.12 release has shipped since 2.15.0 (checked 2026-09-28).
  • For exactly-once via dedup + double ack, which failure modes remain (dedup window expiry, consumer state loss, manual purge, leader changes)?

Answered Questions

  • When does js_ack_fc_v2 become the default? In 2.16.0. The 2.14 guide had said 2.15, and 2.15.0 still ships the flag disabled. On the main branch, server/feature_flags.go now sets it to true with "Enabled: 2.16.0, when upgrading all servers should be 2.15.0+" and "To be removed in 2.17.0" (checked 2026-09-28). js_api_reply_v2 and js_snapshot_sources follow the same plan.