CloudPirates publishes one Helm chart per application, released on its own version line

Each chart is released on its own version line

The repository is a collection of Helm charts rather than a single application, and that changes how you consume it. There is no umbrella version to track. Instead each chart carries its own version and is released on its own schedule.

The three most recent releases show this clearly: redis-0.37.3 on 2026-10-19, mongodb-0.20.1 on 2026-10-19 and rustfs-0.12.0 on 2026-10-18. A Redis chart at version 0.37 and a MongoDB chart at version 0.20 are on independent trajectories, and a Redis chart bump tells you nothing about the MongoDB chart.

The catalog covers a wide but recognizable set of infrastructure software. Etcd is described as a distributed reliable key-value store. Kafka is listed as a distributed event streaming platform for high-performance data pipelines and streaming analytics, running in KRaft mode with no ZooKeeper. MinIO is an object storage service compatible with the Amazon S3 APIs. Postgres, MariaDB, MongoDB and Memcached cover the data tier, RabbitMQ the messaging tier, Keycloak the identity tier, Nginx the ingress tier, and Ghost sits there as a publishing platform. There is also a Common chart, which is described as a library chart holding common templates and helper functions, and a ClusterPirate chart, which is a client agent for the CloudPirates managed observability platform.

So the repository is best read as a curated catalogue with a house style, where the Common chart is the shared foundation the others build on.

A library chart is the shared base for the rest

The Common chart is the piece of internal architecture that explains the rest. In Helm, a library chart is not installable itself. It exists to be depended on by other charts so that they can share templates and helper definitions rather than copying them.

That is the reason the CloudPirates collection lists it alongside installable applications in the same catalogue table. It is a build time dependency of the other charts, a shared set of template fragments that presumably encode the house conventions the project describes as cloud-native best practices.

The practical effect for a user is that the chart you install pulls in shared templates from the Common library chart. If you vendor a chart into your own repository, or pin it in an internal mirror, you need to handle that dependency, and the Common chart becomes part of your upgrade surface even though you never install it as an application.

The catalogue also shows a RabbitMQ Cluster chart listed next to the plain RabbitMQ entry, which suggests some applications are maintained as more than one variant. The listing is truncated in the project documentation, so the full set of variants is not visible from the repository summary alone.

Chart testing and lint configuration live in the repository

The repository root carries the files you would expect from a collection that treats charts as released artefacts. There is a ct.yaml, which is the configuration file for chart-testing, a well known Helm community tool that installs candidate charts into a throwaway Kubernetes cluster and runs their test hooks. There is a lintconf.yaml, the configuration for Helm lint, which is what a chart repository uses to exclude specific lint rules that do not fit its style.

Alongside those sit TESTING.md and a script named test-charts.sh. The presence of both a configuration file and a shell script means the testing story is documented and scripted rather than left to manual review, which is the main reason to trust a third party chart repository at all.

Then there is renovate.json, the configuration for a dependency update bot, and three more scripts: update-charts.sh, update-dependencies.sh and generate-changelog.sh. Those names describe a maintenance routine that bumps chart versions, refreshes pinned dependency versions and produces changelog entries.

None of this is application logic. It is release engineering for the charts themselves, and it is the part that determines whether a chart upgrade will be a small diff or a surprise.

Signing keys and contribution rules in the root

Two root files point at how images are trusted. There is a cosign.pub, which by Sigstore convention is the public key used to verify container image signatures, and a COSIGN.md that presumably documents how verification is performed. For a chart repository that deploys database and identity software, signed images are the difference between knowing where a container came from and trusting the tag name.

The naming convention here is a public key file plus a document, rather than a key management service, so the public key is committed to the repository. That is the straightforward arrangement for a single organisation publishing charts: consumers pin the key, and the repository history shows when it changed. It also means the trust anchor is a file in a git repository, and reviewing its history is part of your due diligence.

The other governance files are CODE_OF_CONDUCT.md and CONTRIBUTING.md, and the project README points at the contributions-welcome badge. The CONTRIBUTING.md file is referenced directly by the badge link in the README, which suggests the document is maintained as the place where external chart contributions are described.

The licence is Apache-2.0, which is the usual choice for infrastructure templates: permissive, with a patent grant, and comfortable for both open and closed distribution.

Changelogs moved to GitHub release notes in April 2026

There is a dated note in the project README that anyone upgrading should know about. As of April 15, 2026, all changelogs exist only in the GitHub release description, and older changelog files are kept for backwards compatibility.

That is a small change with a large consequence for upgrade workflows. If your process reads a changelog file from the repository to decide whether a version bump is safe, that process stops working from April 2026 onward and you have to read the release description on GitHub instead. The convention of a per chart CHANGELOG.md, which most Helm consumers expect and many tooling scripts assume, is gone.

The release notes themselves are also where the per chart versions live. Since the versions advance independently, a team that upgrades several charts at once ends up comparing release descriptions across several chart repositories rather than reading one consolidated history.

This is the concrete upgrade cost to plan for. The repository was pushed to on 2026-10-22 and is not archived, so charts continue to move, and the versions you pin today will have newer siblings next month. If your cluster has restricted egress or an air-gapped promotion process, the pull rate of this repository is a property you should measure before standardising on it.

When a curated chart repository is the wrong choice

The honest alternative to this repository is the upstream project's own chart, if one exists. Many of the applications listed here are large enough to publish their own Helm charts. The difference in approach is straightforward: an upstream chart is written by the people who know the application's flags and upgrade paths, while a curated chart is written by an operator who knows Kubernetes well and the application less well.

That trade cuts both ways. The curated chart usually has better defaults for a Kubernetes deployment, since it is written from the deployment side, and it gives you one place to look for consistent values keys across a catalogue. The upstream chart usually encodes application specifics more faithfully, and it is released in step with the application.

The other alternative is writing the template yourself, which is what the people who want a curated chart were trying to avoid. That is a reasonable position for a platform team with a few applications and chart review capacity, and a poor one for a team with fifteen services and no interest in maintaining templates.

Two concrete failure modes to keep in mind. First, the templates here are CloudPirates work, so an upstream application's breaking change in configuration flags reaches you as a chart version bump that you have to read the release description to understand. Second, a curated collection is a set of opinions: defaults for persistence, resource limits, ingress and backups are chosen for you, and if those choices do not match your platform's conventions, you are maintaining values overrides across every chart rather than one upstream.

Editorial conclusion

The CloudPirates helm-charts repository fits an operator who runs several open source data services on Kubernetes and would rather consume a maintained chart than write templates for each one, with the caveat that chart versions advance independently of each other. It does not fit a team whose security review requires a chart it can trace to the upstream project, since the templates here are CloudPirates work rather than upstream releases, and it does not fit a team that needs a chart for software the repository does not cover. Before adopting one of these charts, read the chart's own values file and template rather than the repository summary, check the chart's version history in its GitHub release descriptions now that changelogs live there, and verify the image references and signing key in the chart against the upstream release you intend to run.

Frequently asked questions

Official sources

1. CloudPirates-io/helm-charts on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases