nats-io/k8s: Helm charts for running NATS on Kubernetes

Three charts, and the repository is the delivery mechanism

The README is short because this repository does one thing: it is the place where the NATS ecosystem's Kubernetes deployment examples live. You can find several examples of how to deploy NATS, NATS Streaming and other tools from the NATS ecosystem on Kubernetes, and the three linked charts are the NATS Helm Chart, the NATS Surveyor Chart, and the NATS JetStream Controller Chart. The directory listing backs that up. There is a helm/ directory holding the charts, a kine-nats/ directory, and a set of governance files at the root: GOVERNANCE.md, MAINTAINERS.md, CODE-OF_CONDUCT.md, CLAUDE.md and dependencies.md, plus a LICENSE and the usual .github directory. The Helm 3 based charts are the installable artefact, and the repository is where the chart sources and their release process live. The primary language is recorded as Go, the default branch is main, and the licence is Apache-2.0 with the README noting that unless otherwise noted the NATS source files are distributed under the Apache Version 2.0 license found in the LICENSE file.

Installing the chart from the published repository

The getting started path is the standard Helm repository dance, and the README gives it in full so you can copy it exactly. You add the chart repository, update it, list to confirm it registered, and then install the chart under a name of your choosing:

> helm repo add nats https://nats-io.github.io/k8s/helm/charts/
> helm repo update

> helm repo list
NAME          	URL 
nats          	https://nats-io.github.io/k8s/helm/charts/

> helm install my-nats nats/nats

```

The install command takes two arguments that are worth reading carefully. The first, my-nats, is the release name Helm will use for the resources it creates, and the second, nats/nats, is the chart reference, which is the repository name followed by the chart name. The repo list output in the README is a table with a NAME column and a URL column, and the nats entry maps to the same URL you added. What the README does not do is walk through the values, so if you need JetStream enabled, or a specific cluster domain, or a different persistence backend, you are expected to read the chart's own values file rather than to find a documented flag here. That is the main gap between this repository and a full deployment guide.

The three charts cover three different jobs

Reading the three chart names tells you what the NATS ecosystem expects to run on Kubernetes, and it is worth separating them because they are not three ways of doing the same thing. The nats chart is the broker itself. The nack chart is the JetStream Controller, which is a separate component that watches Kubernetes resources and reconciles them into JetStream configuration, so it is a deployment in its own right with its own permissions. The surveyor chart is for Surveyor, which is a monitoring and metrics component in the NATS ecosystem. The naming convention follows the usual Helm practice of prefixing the chart with the project it belongs to, so surveyor and nack are distinguished from nats by their prefix, and the release tags in the repository follow the same convention: surveyor-0.20.10, nats-2.15.1 and nats-2.15.0, where the first part is the chart and the second is the chart version. That naming is the practical clue for anyone automating a rollout, since the tag tells you which chart moved.

kine-nats exists because persistence is a separate choice

The kine-nats directory at the repository root is the one entry that the README does not link a chart for, and its presence is informative. Kine is the piece that lets JetStream use an external SQL database for its persistence, so a directory named kine-nats in a NATS Kubernetes repository points at running Kine on top of NATS, which is the arrangement for teams that want JetStream's stream semantics with a database their operators already know how to back up. The reason the README does not present it alongside the three charts is probably that it is a different kind of artefact, an example rather than a published chart, and the repository also carries a docker-compose.yml at the top level for running the same stack outside Kubernetes. The practical reading is that the JetStream deployment story in this ecosystem has more than one path, and the chart repository covers the NATS-native one while the SQL-backed one lives beside it.

What a chart repository does and does not give you

The mechanism has a specific benefit worth naming, because it is the reason the NATS maintainers publish here rather than asking users to copy YAML. A Helm chart repository is a versioned, indexable source of installable packages, so a cluster can add it with helm repo add and then upgrade or pin a chart version the same way it would any other dependency. That means the deployment definition is versioned alongside the code, and an operator can reproduce a known-good broker configuration on a new cluster without hand-editing manifests. The trade is that the chart abstracts the configuration behind values, and the README here documents none of them, so the abstraction is only as transparent as the chart's own documentation and your ability to read its values file and templates. A chart that is convenient to install is also convenient to accept without reading, and for a broker whose persistence, authentication and TLS settings are the parts that matter, that is a real gap in the documentation rather than a stylistic one.

Where the charts stop being the right tool

The limits are structural. The first is that a chart is a default, and defaults are not the same as a fit. A production broker has specific requirements around cluster domains, TLS material, authentication, resource limits and storage class, and the README's install command gives you the chart's opinion rather than yours. Second, the repository covers the NATS ecosystem's Kubernetes side only. If you need NATS on a different orchestrator, or you need the broker's behaviour rather than its deployment, you are looking at the wrong repository. Third, the README still describes the scope as deploying NATS, NATS Streaming and other tools, while the linked charts are for NATS, Surveyor and the JetStream controller, so a reader who arrives expecting a streaming-server chart should verify what is actually published before planning an install. Fourth, and most simply, none of the configuration detail is in the README at all, so the chart's own values file and the documentation site are the sources of truth for every parameter you will actually need to set.

Editorial conclusion

nats-io/k8s suits an engineer who wants NATS on Kubernetes with the chart the NATS maintainers publish, rather than assembling a StatefulSet, a Service and a ConfigMap by hand, and the fact that the charts are published to a Helm repository means a cluster can add them the same way it adds any other chart. It is the wrong tool if you need the old streaming server specifically, since the README still mentions NATS Streaming while the charts listed are for NATS, Surveyor and the JetStream controller, and it is the wrong tool if you want a single command that configures persistence for you, because the kine-nats directory exists precisely because that choice is separate. Verify first which chart you actually need, since the repository publishes three, and check the chart's own values against your cluster before you install, because the README documents the install command and not the parameters.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. nats-io/k8s on GitHub
4. README
5. Releases