nats-server is the Go-based, Apache-2.0 licensed server at the heart of NATS, a simple, secure and performant communications system for digital systems, services and devices, aimed at teams building distributed systems, microservices, and cloud, edge or connected-vehicle deployments that need messaging without running heavyweight broker infrastructure.

What it is

nats-server is the server component of NATS, a messaging system for digital systems, services and devices. It is written in Go and released under the Apache-2.0 licence, and NATS is a project of the Cloud Native Computing Foundation (CNCF). The server runs on-premise, in the cloud, at the edge, and even on a Raspberry Pi, and it is paired with over 40 client language implementations, so the server itself is one half of a deliberately polyglot system. The topic list places it squarely in cloud-native, distributed-systems, messaging and microservices-architecture territory, with additional reach into edge computing, edge AI and connected vehicles.

The concrete problem it solves is the integration glue that accumulates when every service must talk to every other service directly. Rather than each team wiring and maintaining its own point-to-point channels, the project provides a shared message bus and message queue that services connect to instead. The README frames the goal as securing and simplifying the design and operation of modern distributed systems, which is the work that bespoke per-service messaging plumbing otherwise consumes.

Key capabilities

• A single server implementation written in Go, distributed under Apache-2.0, that runs on-premise, in the cloud, at the edge, and on Raspberry Pi class hardware.
• Over 40 client language implementations, listed at nats.io/download, connecting to the same server so polyglot fleets share one messaging fabric.
• CNCF project governance, with a published roadmap at nats.io/about/#roadmap.
• A Docker image published as nats on Docker Hub, and a Helm chart published as nats/nats on Artifact Hub.
• A third-party security audit performed by Trail of Bits following engagement by the Open Source Technology Improvement Fund (OSTIF), with the full report published in April 2025.
• A CII Best Practices badge and a GitHub Actions build and test workflow at .github/workflows/tests.yaml, covering release and coverage badges.
• Community channels including Slack at slack.nats.io, a Google Groups forum, and Twitter at @nats_io.

Who uses it and how

• Teams running microservices architectures that want service-to-service messaging without hand-written integration code between each pair of services.
• Edge and edge-AI deployments, because the server runs at the edge and on constrained hardware such as a Raspberry Pi, so the same messaging model reaches remote sites.
• Connected-vehicle and broader distributed-systems use cases, which appear in the project topic list, with a published adopter list at nats.io/#who-uses-nats.
• Hybrid topologies spanning on-premise and cloud, since the README states the server supports both environments.
• Polyglot engineering organisations, where services written in different languages join one messaging system through the 40-plus client implementations.

Getting started

Run the server from the Docker image published as nats on Docker Hub, or deploy it with the Helm chart published as nats/nats on Artifact Hub. Installation, configuration and operational detail live in the official documentation at docs.nats.io, with an FAQ and a video overview also linked from the README.

How it compares

The facts provided name no alternative messaging systems and no list of paid products that this project replaces, so no comparison on licence, self-hosting, data ownership or cost model can be drawn from the material supplied. On the evidence given, this entry stands alone in this registry.

When to use it — and when not

A self-hoster operates the server itself, which means owning the deployment, upgrades and monitoring that come with running infrastructure rather than consuming a managed service. The README excerpt is largely a set of pointers to documentation, community channels and videos, so operational specifics such as configuration, clustering and security setup must be read at docs.nats.io rather than in the repository front page. Teams that want a fully managed broker, or that cannot commit to running and updating a container or binary, should look elsewhere; the 472 open issues at the time of this snapshot also indicate a large and active surface that a small operations team will need to track.