CloudNativePG ships three Helm charts, and the operator chart only tracks the latest point release

Three charts on three independent release tracks

The repository publishes the official Helm charts for CloudNativePG, and the project description names the three things it covers: the operator, database clusters, and the Barman Cloud plugin.

Each chart has its own version line, and the release badges are filtered separately, which is the clearest signal that they are released independently rather than as a set. The recent releases show that: cluster-v0.9.0 came out on 2026-10-01, plugin-barman-cloud-v0.8.1 on 2026-09-30, and cloudnative-pg-v0.29.1 on 2026-09-23. The operator chart is on a 0.x track of its own, the cluster chart is on a 0.9 track, and the plugin is on a 0.8 track. None of them share a version number, and none of them are versioned to match the operator's release numbering.

The top level of the repository reflects a project with real release engineering behind it. There is a RELEASE.md, a SECURITY.md, a CODEOWNERS file, a COMPONENT_OWNERS.md, a CODE-OF-CONDUCT.md, a Makefile, and a provenance.gpg file. A provenance key in the repository is how a chart source is signed, and having one checked in is a meaningful signal for anyone who cares where a chart came from.

The licence is Apache-2.0, and the repository states it plainly: Helm charts for CloudNativePG are distributed under the Apache License 2.0.

The primary language is listed as Go Template, which is an accurate description of a chart repository. There is no application code here. The behaviour lives in the operator image the chart deploys.

The operator chart only supports the latest point release

There is one constraint stated in bold in the project text, and it changes how you plan upgrades.

The operator chart supports only the latest point release of the CloudNativePG operator. Not the latest minor version, not the previous point release. The latest point release.

The practical consequence is that you cannot pin the operator chart to an older operator build to hold back a change. If a new point release of the operator ships and the chart is updated to match, taking the chart update means taking the operator update, because the chart is the only supported way to install that operator. A patch to the operator, which is normally the least risky kind of release, is something you receive whenever you update the chart, and you receive it as soon as the chart update is available.

This is a deliberate trade rather than an oversight. Pinning a chart to one specific operator build would mean the chart has to be released for every operator release, and a chart that lags behind the operator is a chart that nobody wants to use. The cost is that the operator version and the chart version move together, and the granularity of your control is the chart, not the operator.

The operator chart installs the CloudNativePG operator, which was originally created and sponsored by EDB, to manage PostgreSQL workloads on any supported Kubernetes cluster running in private, public, or hybrid cloud environments. Each chart has its own document under the charts directory, and those files are the place to look for installation steps and advanced configuration.

The cluster chart and the plugin chart do different jobs

The cluster chart installs a CloudNativePG database cluster. That is the chart most teams will actually use day to day, since the operator itself is a one-time installation per cluster.

The plugin-barman-cloud chart installs the CNPG-I Barman Cloud Plugin, which is the piece that handles backup and, given the name, hands that off to object storage. It is released on its own track at 0.8.1, which means it moves independently of both the operator and the cluster chart. That is worth understanding for upgrade planning: a backup path change is a separate decision from an operator upgrade and from a cluster spec change, and the three versions in your cluster need not move together.

The plugin is also the reason the repository carries a COMPONENT_OWNERS.md alongside the usual CODEOWNERS. A repository where several products share one chart repository needs an explicit statement of who owns which component, otherwise a change to the backup plugin gets reviewed by the operator maintainers by default.

The repository also has a .gitvote.yml file and a .github directory, plus a Makefile that regenerates the docs and the schemas. Nothing here needs a database to work. The charts are templates that produce Kubernetes objects, and the objects they produce are reconciled by the operator, which is where the actual PostgreSQL lifecycle management happens.

Docs and JSON schemas are generated, not written by hand

The Makefile is the clearest window into how this repository is maintained, and the tooling choice is specific.

Two external tools do the work. helm-docs generates the charts' docs, pinned at version v1.14.2, and helm-schema generates the charts' JSON schema, pinned at 0.23.5. Both are installed locally into a bin directory inside the project, and both are versioned with renovate comments that point at the GitHub releases datasource, which is how they get bumped.

The docs target is a single rule with a single command:

docs: helm-docs ## Generate charts' docs using helm-docs
	@$(HELM_DOCS) --skip-version-footer

The schema target fans out into one rule per chart, and the flags are shared:

schema: cloudnative-pg-schema cluster-schema plugin-barman-cloud-schema ## Generate charts' schema using helm-schema

	@$(HELM_SCHEMA) $(HELM_SCHEMA_FLAGS) -c charts/cloudnative-pg

The schema flags are set to -a --no-dependencies --skip-auto-generation title,required,additionalProperties. Skipping automatic generation of the title, required, and additionalProperties properties is a deliberate choice, because it means the schema reflects what the chart maintainers decided should be required and constrained, rather than a machine inferring it from the values file. That is the difference between a schema that documents the contract and one that merely describes the file.

The rest of the Makefile is a help target, which is the default goal, and it prints the available commands with a short description for each. The project directory is resolved with dirname and abspath so the behaviour is identical regardless of the caller's working directory, which is the kind of detail that saves a confused afternoon in CI.

What the charts repository is not, and where the real documentation lives

Two boundaries are worth stating, because the top level page is short and it is easy to mistake it for a complete guide.

The first is that the top level README is an index, not a manual. It names the three charts, gives the operator chart a paragraph of context, and then points at three per chart documents under the charts directory, one for the operator chart, one for the Barman Cloud plugin chart, and one for the cluster chart. Each of those is where installation, advanced configuration, and for the operator chart, monitoring information lives.

The second is that this repository does not contain the operator. It contains the packaging. The CloudNativePG operator was originally created and sponsored by EDB, and the behaviour of the operator, including how a cluster reconciles, is documented on the project's own site at cloudnative-pg.io. A team evaluating CloudNativePG needs both: this repository to install it, and the operator docs to understand it.

The contribution path is also explicit. The project asks you to read the code of conduct and the guidelines in CONTRIBUTING.md before contributing, and the repository carries a SECURITY.md, which tells you where security issues should go rather than into the public issue tracker.

The comparison with a plain set of manifests comes down to who owns the upgrade. A hand maintained manifest set is fully under your control and has to be updated by hand, including the operator image tag and every value change between versions. These charts package the operator version, the defaults, and the schema, so a `helm upgrade` is the intended path. What you give up is the ability to hold a specific operator build, because of the point release rule, and what you gain is a documented, versioned, signed source for the packaging.

Signing, release notes, and how the three charts are shipped

The repository carries a provenance.gpg file at the top level, which is the key used to sign chart packages. Combined with the RELEASE.md file at the root, that tells you the release process is documented and the artefacts are signed, and it is the reason a team with a supply chain policy can consume these charts at all.

The release tracks are visible in the badge filters. The operator chart badge filters on cloudnative-pg-*, the plugin badge on plugin-barman-cloud-*, and the cluster badge on cluster-*. Those prefixes are also the chart names in the charts directory, which is where the per chart READMEs, values files and templates live.

The three-way split also tells you where to look when something breaks. A cluster that will not start is a cluster chart or operator problem, and a backup that stops working is a plugin problem, and the plugin has its own version line that moves on a different schedule. Conflating them during an incident is how people end up upgrading the operator when the backup plugin was the actual fault.

The last push to the repository was on 2026-10-17, which is recent, and the three most recent releases in the list fall in late September and early October 2026. The maintenance picture is therefore straightforward: an active repository with three release trains running at a pace of roughly monthly or better on the cluster and plugin charts, and a longer lived operator chart track on 0.29.x.

One thing the project text does not state is a compatibility matrix between the operator chart version and the cluster chart version. The charts are released independently, so the supported combinations are not published in this repository, and if you are pinning versions across the three you should confirm the pairing rather than assuming the latest of each works together.

Editorial conclusion

The CloudNativePG charts fit a team running PostgreSQL on Kubernetes who wants the vendor's own packaging rather than a hand rolled manifest set, and who will read the per chart documentation before changing values. They do not fit a team that needs an older operator point release pinned, because the operator chart supports only the latest point release. Before adopting the cluster chart, read charts/cluster/README.md and the generated values schema, since the chart exposes many knobs and the schema is what tells you which of them are required.

Frequently asked questions

Official sources

1. cloudnative-pg/charts on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases