[Helm] Publish the chart to a public Helm repository

[mhorcajada]

Problem

The Helm chart at packages/twenty-docker/helm/twenty can only be installed by cloning the monorepo and pointing helm install at the local path. This causes a few practical issues for self-hosters:

• The chart cannot be added with helm repo add, so it is left out of GitOps tools that rely on HelmRepository sources (Flux). The choice is either to fork and re-package the chart on your own infrastructure, or to fall back to manual helm install outside of GitOps, which breaks fleet uniformity.
• Renovate and Dependabot cannot track new chart versions automatically, so version bumps depend on whoever is maintaining the local clone.
• The Chart.yaml appVersion is not bumped on release. It currently points to v1.14.0 while the product is on v2.16.x, so anyone who does not override image.tag in their values.yaml ends up running a very outdated image without noticing.

The community chart at AMecea/helm-twentycrm is the workaround some users take today. It is not affiliated with TwentyHQ, which fragments the ecosystem and puts the maintenance burden on an unrelated contributor.

We believe lowering the friction of self-hosting on Kubernetes would meaningfully increase k8s adoption of Twenty. Today the cluster-based installation path is significantly less polished than the Docker Compose one, which leaves a part of the technical audience (the segment most likely to dogfood AI-native CRMs) on the sidelines.

Proposed solution

Publish the chart on each tagged release through a classic Helm repository hosted on GitHub Pages at https://twentyhq.github.io/charts/. Same approach as cert-manager, ingress-nginx, longhorn, and many other widely adopted CNCF projects.

End user experience would be the standard one:

helm repo add twentyhq https://twentyhq.github.io/charts
helm repo update
helm install twenty twentyhq/twenty --version 2.16.1 -f values.yaml

The setup is essentially a GitHub Action that runs on tagged releases and pushes the packaged chart plus an updated index.yaml to a gh-pages branch. helm/chart-releaser-action does this out of the box and is the de facto standard for this workflow.

To follow the recommended practices for Helm chart publishing, each release should also ship:

• A bumped version field in Chart.yaml following SemVer for the chart itself (independent from the product version, as cert-manager and ingress-nginx do).
• A populated artifacthub.io/changes annotation in Chart.yaml, or a CHANGELOG.md next to the chart, so the per-version changelog is rendered automatically by Artifact Hub and by helm/chart-releaser-action GitHub Releases.
• An artifacthub.io/category, home, icon, and maintainers block in Chart.yaml so the chart is discoverable on Artifact Hub.

Bonus: align Chart.yaml appVersion with the release tag

Update appVersion in packages/twenty-docker/helm/twenty/Chart.yaml as part of the release process so the default image.tag matches the released product version. This avoids the silent regression where new users end up running v1.14.0.