bjw-s helm-charts publishes one operator's home cluster as a chart repo

Charts written for one home cluster, then published

Most public Helm chart repositories fall into one of two shapes. Either a maintainer team ships charts for a product they also maintain, or a big collection mirrors the upstream project's own packaging. This repository is a third shape, and the author is explicit about it: it contains Helm charts that he developed to run applications in his home Kubernetes cluster, and it is not intended to be a replacement for any of the large collections of Helm charts that are out there.

That sentence is the most useful line in the project documentation, and it should be read as a scope statement rather than as modesty. A chart built for one cluster encodes one operator's decisions: which ingress controller they run, how they name things, how secrets are handled, what persistence looks like, which version of an image was known to work. That is exactly what makes a home cluster chart useful, and exactly why it does not generalise to everyone else's cluster without edits.

The audience, then, is a person running Kubernetes at home or on a small personal cluster who wants a working reference for an application and is prepared to look at the values. It is also useful as a study of how a maintainer organises a collection, since the same repository shape can be read as a template for your own.

The home-cluster context also explains the supporting material. The documentation site sits at the repository's own pages host, the repository topics reference running Kubernetes at home, and the project points to a search service for public repositories containing the application you want to run, which is how a user finds the other repository that also charts that application.

Adding the repository and finding a chart

Using the charts requires Helm to be installed, and the repository itself is added with the standard repository command. The name you give it here is bjw-s, and the URL is the project's documentation host:

helm repo add bjw-s https://bjw-s-labs.github.io/helm-charts

After that, the charts in the repository are searched with the repo search command:

helm search repo bjw-s

That is the whole installation procedure, and its brevity is a fair signal about the kind of project this is. There is no credential to configure, no operator to install first, and no namespace to prepare before the charts are usable. The repository is a static index of packaged charts served over HTTP, and a chart is pulled and installed the way any other chart is.

What you do after the search is the part that matters. Because the charts are written around one cluster's conventions, the values file is where the real work is, and the documentation site is the place where that structure is described. The repository itself does not carry per chart documentation in its README, so a team evaluating a specific chart should read the chart's page on the documentation site before committing to it, and should expect to adjust resource limits, storage classes, ingress annotations and secret handling to match its own cluster.

One structural note for anyone automating deployments against this repository. The chart names carry their own versions, and the release history shows charts versioned independently of one another, so a value file pinned to one chart version does not automatically match the next one.

The release tags show a shared library chart and a template chart

The recent release list is short but informative, because it names three different charts and shows how they version. The most recent releases include multus-1.3.6, common-5.3.0 and app-template-5.3.0, all on 2026-10-10, with the common release tagged in the morning and the multus and app-template releases later in the day.

Two observations follow. First, a chart named common sits alongside a chart named app-template, and both carry the same version, 5.3.0. Whatever common is, it is released in lockstep with the template chart, which is the pattern you would expect from a shared library that the template depends on, where the two must agree on a set of values. Second, multus is versioned on its own line, 1.3.6, which is what a self-contained chart looks like: it does not move with the shared library.

This is the difference between a collection of per application charts and a collection built around a shared value structure. In the second case the charts are not independent, and the version numbers are the place where that dependency becomes visible. A consumer pinning app-template to a version should check what it expects from common, because a mismatched pair is a class of failure that shows up at install time rather than at development time.

The chart directory in the repository is where the sources live, and the fact that common and app-template are versioned together at 5.3.0 while multus sits at 1.3.6 also tells you the collection mixes at least two kinds of chart. The documentation site is where the catalogue and the value structure are described in full, and that is the reference to read before picking a chart.

Three consumption paths in the examples directory

The repository carries an examples directory with three subdirectories named flux, helm and kustomize. That is a design decision with a practical consequence: the same charts are expected to be usable through three different deployment workflows, and each has its own example.

A plain Helm installation is the first path, and it is the one the README covers, with the repository add command and the search command. Flux is the second, which matters because Flux is a GitOps controller that pulls desired state from a repository rather than applying it from a workstation, and a chart used that way is installed by a controller on a schedule rather than by a person at a terminal. Kustomize is the third, which is the case where the chart is treated as a source of rendered manifests that are then patched by an overlay rather than installed as a release.

Supporting all three means the chart values have to be written so they survive being consumed as a template, rendered and then patched, or pulled by a controller. That constraint is not free. It is the reason the values structure of such a collection is often flatter and more explicit than a single purpose chart, and it is worth reading the examples for the deployment path you actually use rather than assuming the other two behave the same way.

For an evaluator, the three examples are a good shortcut. They show the intended consumption of a chart in each of the three styles, which tells you more about the real integration than a values schema does.

The tooling around the charts, and the agent instructions

The root of the repository lists the infrastructure that produces the charts, and it is a fairly complete one for a chart collection. There is a Justfile, so the routine tasks have a task runner with named recipes rather than a list of shell commands in a wiki page. There is a .mise.toml, which pins the tool versions used for the work, and a .vscode/ directory for editor configuration. There are two linting and formatting tools for the YAML that charts are made of, .yamllint.yml and .yamlfmt.yaml, so chart YAML is checked and formatted consistently. A .ci/ directory holds the continuous integration definitions, and a tools/ directory holds helper scripts.

Two more files are worth noticing. There is a .editorconfig and an AGENTS.md. The latter is a document addressed to automated coding agents working in the repository, and its presence says something about how the project expects changes to be made to it: the maintainer wants an agent to follow the repository's own conventions rather than improvise a chart structure. If you plan to contribute a chart, that file is part of the reading, alongside the CONTRIBUTING.md that the README links to.

The docs/ directory at the root is what generates the documentation site, so the site is versioned with the charts. That is a better arrangement than a separate documentation repository, because a value change and the description of that change land in the same pull request. The .github/ directory at the root holds the repository templates and workflow definitions that drive releases and contributions.

Apache 2.0, active releases and a single maintainer

The licence is Apache 2.0, and the README points to the LICENSE file in the repository root rather than restating the terms. Apache 2.0 is a permissive licence with an explicit patent grant, which matters for chart collections because the values files, templates and helper scripts are the part people copy between clusters, and a permissive licence with a patent grant is a comfortable basis for that kind of reuse. Any organisation with a compliance process should still read the LICENSE file itself, since the README does not summarise the obligations.

The maintenance picture is healthy. The repository is not archived, and the last push was on 2026-10-10, the same day the three most recent releases were tagged, which is the sign of an active chart collection rather than a dormant one. Releases carry a per chart version, so a consumer can pin the exact chart version that was tested against a given cluster.

The concentration risk is structural rather than technical. This is one maintainer's repository, with a Discord community and a sponsorship page for support, and the charts originate in a single home cluster. That means quality and compatibility are tied to one person's cluster and one person's upgrade schedule. It also means the charts tend to reflect what a home cluster actually needs, which is a coherent design point and the reason the project does not attempt to be a general purpose collection.

For anyone deploying from it, the sensible habit is to read the values, pin the chart version, and expect to maintain your own copy of the values once you diverge from the author's assumptions about ingress, storage and secrets.

Editorial conclusion

bjw-s helm-charts suits a home lab or a small cluster operator who wants a working configuration for a particular application rather than a generic upstream chart, and it suits anyone comfortable reading the chart values to adapt them. It is the wrong choice as a production platform catalogue, because the author describes the repository as charts developed for his own home Kubernetes cluster and says explicitly that it is not intended to replace the large collections, and it is a poor match if you need per chart documentation in the repository, since the detail lives on the documentation site. Before adopting, add the repository with helm repo add, run helm search repo bjw-s to see the current catalogue, and read the documentation for the specific chart rather than assuming the values structure matches other charts.

Frequently asked questions

Official sources

1. bjw-s-labs/helm-charts on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases