nextcloud/helm is the community Helm chart for running Nextcloud on Kubernetes

What this repository is, and the warning that comes with it

nextcloud/helm is described as a Helm repo for different charts related to Nextcloud which can be installed on Kubernetes. It lives under the nextcloud GitHub organisation, the primary language is recorded as Go Template, which is what Helm chart rendering is written in, and the licence is AGPL-3.0.

The repository README opens with a warning that is not decorative. The project is maintained by community volunteers and designed for expert use, and for quick and easy deployment that supports the full set of Nextcloud Hub features, the README points you to the Nextcloud All-in-One project maintained by Nextcloud GmbH.

That warning shapes the whole decision. This chart is for people who already know how to run Kubernetes and want a Nextcloud instance expressed as a Helm release. It is not a one-command installer for someone who wants a file sync server working this afternoon.

The distinction the README draws is between community maintenance and vendor support, and it repeats the point later in the support section, stating that the chart is community maintained and not supported by Nextcloud GmbH. A project that says this in its first paragraph is being more useful to a reader than one that leaves the distinction for the footer.

For comparison, the All-in-One project takes a different approach to the same problem. It is an application you run rather than a chart you render, and it is maintained by the vendor, which means the Nextcloud Hub feature set is the target rather than something you enable yourself.

Adding the repository and installing the chart

Installation is a standard Helm repository setup followed by a normal release install, and the README gives both commands.

Adding the repo:

helm repo add nextcloud https://nextcloud.github.io/helm/
helm repo update

And then installing the chart, with the release name first and the chart reference after:

  helm install my-release nextcloud/nextcloud

Two things in the second command are worth reading carefully. The release name is yours to choose, here my-release, and Helm uses it as the prefix for every object it creates, which is how you end up with more than one Nextcloud in the same cluster. And the chart reference, nextcloud/nextcloud, is the repo name followed by the chart name, which is what tells Helm to look in the repository you just added rather than a local directory.

The chart itself is linked from the repository README at the chart index page on the Helm repository site, so the published artefacts and the source in the repository are the same thing seen from two angles.

For anything beyond the happy path, the README points to the chart level README.md in the charts/nextcloud directory and says to check that out for more information. That is the file to read before your first install, because the root README covers the repository rather than the chart's values, its dependencies and its configuration surface.

How the chart is versioned and how it is tested

The chart ships as its own release series, and the version numbers are the chart version rather than a Nextcloud application version.

The listed releases are nextcloud-9.3.0 from 2026-09-19, nextcloud-9.4.0 from 2026-09-30 and nextcloud-9.4.1 from 2026-10-18. The tag prefix is nextcloud-, which is how you can tell a chart release from an application release at a glance, and the patch-level bump on 9.4.1 is the sort of change that usually means a template or values fix rather than a new application version.

The repository layout explains the release process. There is a charts/ directory holding the chart sources, a ct.yaml file at the root, which is the configuration for chart-testing, the linter and installer used to validate charts in CI, and a .github/ directory holding the workflows. A ct.yaml file is the clearest signal in the tree that the chart is checked automatically rather than only tested by whoever runs the install.

There is also a .gitignore, a CODE_OF_CONDUCT.md, a CONTRIBUTING.md and the LICENSE file at the root, alongside the README. The chart-testing setup and the separate values documentation are what make this more than a single template file: a chart that has to survive linting across Kubernetes versions has to be written to a stricter standard than a template you write for yourself.

For an operator, the practical consequence of chart versioning is that a rollback is a Helm operation rather than a re-implementation. Upgrading to a new chart version and going back to the previous one are both release operations, and the chart release list tells you which versions exist.

Contributing, and the DCO requirement

The contribution path is short and has one hard requirement.

The README says the maintainers are always happy to review a pull request, and asks contributors to check the pull request template to make sure all the required checks are fulfilled, most importantly the DCO. The Developer Certificate of Origin is a sign-off mechanism, and the README links to the probot DCO app.

The DCO requirement is a meaningful difference from many community chart repositories, and it is worth understanding before writing a patch. Instead of assigning copyright to a foundation or a company, each contributor asserts that they have the right to submit the code and that the contribution is made under the project's licence. For a chart that carries AGPL-3.0, that is a coherent pairing.

Two other community rules are named. Contributors are asked to review the official Nextcloud Code of Conduct, and the README asks you to review this repo's contributing doc before contributing. The Code of Conduct is linked at nextcloud.com/contribute/code-of-conduct/, which puts the chart under the wider Nextcloud community's expectations rather than only the chart's own.

The support channels follow the same split. Questions go to GitHub Discussions, bugs and feature requests go to the GitHub Issues tracker, and the README suggests searching the issues first before opening a new one.

Where this chart is the wrong choice

There are two cases where this repository is the wrong answer, and the README itself names both.

The first is a non-expert who wants a working Nextcloud quickly. The chart is designed for expert use, and the all-in-one route exists precisely for the other case. Choosing the Helm chart when you wanted the simple path means owning storage, ingress, TLS and the upgrade sequence yourself.

The second is a deployment that needs the full set of Nextcloud Hub features out of the box, which the README explicitly points at All-in-One for. A chart that renders Kubernetes objects gives you Nextcloud, and the surrounding applications in the Hub are a different matter.

There is a third, quieter cost that the README does not spell out. A community maintained chart means the upstream application version, the chart version and the Kubernetes version are three moving parts, and when something breaks the question of whether the fault is in the chart or in Nextcloud is one you answer yourself, since there is no vendor support behind the chart. The GitHub Discussions board is where that question gets asked, and it is a volunteer resource.

The licence is AGPL-3.0, which is the same licence Nextcloud server itself uses. For an internal deployment that is unremarkable. For anyone who modifies the chart templates and then offers the result as a service, the AGPL obligations are the thing to think about before shipping, and they are the same considerations the Nextcloud server licence produces.

What the repository does not tell you

It is worth being explicit about the gaps, because the repository README is short and a reader who installs from it without checking further will be guessing.

The root README does not describe the chart's values, its dependencies, its persistence model or its ingress configuration. It links to charts/nextcloud/README.md for that, which means the documentation you need is one level down and a reader who arrives from the Helm repository site rather than the GitHub page may not find it. The published chart index page is a separate document again.

The root README also does not state which Kubernetes versions the chart supports, which Nextcloud server versions it deploys, or how the chart maps application upgrades to chart upgrades. The chart-testing configuration in ct.yaml implies that some version matrix is enforced during CI, but the matrix itself is not written down in the root README.

None of this makes the chart bad. It makes it a repository that assumes you will read the chart documentation, and it is a reminder of what a community chart can and cannot promise. What you get is the template, the tooling to validate it and a release series with a history you can pin and roll back to. What you do not get is a support contract, and the README is honest about that in its opening line.

Editorial conclusion

Adopt nextcloud/helm if you run Kubernetes as a platform team, want Nextcloud managed as a Helm release with versioned upgrades and rollbacks, and are prepared to read the chart level README.md for the values you need to set. Do not adopt it if you want a supported deployment path, since the README says the chart is not supported by Nextcloud GmbH and that the All-in-One project is the route for quick deployments with the full set of Nextcloud Hub features. Before you install, read charts/nextcloud/README.md rather than relying on the repository README, and confirm your Kubernetes and Helm versions and your storage and ingress choices against the chart's own documentation. The licence is AGPL-3.0, the latest chart release is nextcloud-9.4.1 from 2026-10-18, and the last push was on 2026-10-20.

Frequently asked questions

Official sources

1. Issues
2. License: AGPL-3.0
3. nextcloud/helm on GitHub
4. README
5. Releases