Document HelmForge chart as a third-party Kubernetes installation option

[mberlofa]

Hi openHAB team,

I maintain charts in the HelmForge ecosystem and wanted to share that openHAB is available as a third-party Helm chart for Kubernetes users:

• Chart documentation: https://helmforge.dev/docs/charts/openhab
• Chart source: https://github.com/helmforgedev/charts/tree/main/charts/openhab
• Helm repository: https://repo.helmforge.dev
• OCI package: oci://ghcr.io/helmforgedev/helm/openhab

Example installation:

helm repo add helmforge https://repo.helmforge.dev
helm repo update
helm install openhab helmforge/openhab

OCI installation:

helm install openhab oci://ghcr.io/helmforgedev/helm/openhab

The chart uses the official openhab/openhab container image and supports common Kubernetes deployment needs, including a single-instance StatefulSet, persistent volumes for userdata, conf, and addons, ConfigMap-managed openHAB configuration files, Ingress, Gateway API HTTPRoute, External Secrets Operator integration, optional Karaf Service, Prometheus metrics/ServiceMonitor, S3-compatible backup, probes, resource settings, and scheduling options.

The chart explicitly documents that openHAB is deployed as a single instance and should not be treated as a horizontally scalable workload.

Would you be open to adding this to the openHAB documentation as an unofficial / third-party Kubernetes installation method? This could help users who already operate Kubernetes clusters discover a maintained Helm-based deployment path, while keeping ownership clear that the chart is maintained by HelmForge and not by the upstream openHAB project.

If preferred, I can open a small documentation PR with a short third-party Kubernetes/Helm section linking to the HelmForge chart.

[rkoshak]

This sounds great! But this issue needs to be moved to the openhab-docs repo. That's where the installation docs are maintained.

I won't speak for the project as a whole, but we usually like to have some abiltity to keep this up to date as a project rather than relying on third parties. We've had important third party stuff like this just become abandonded in the past (e.g. jython helper library) or have people complaining on our forum when stuff breaks which we have no control over (e.g. Snap, proxmox LXC) and it becomes a huge hassle to clean it up.

We recently went through a similar situation with FreeBSD support. You can look at https://github.com/openhab/openhab-bsdpkg for how we ultimately handled that.