# goharbor/harbor-helm: Installing Harbor on Kubernetes > goharbor/harbor-helm is the official Helm chart for deploying Harbor on Kubernetes. It supports Ingress, ClusterIP, NodePort, LoadBalancer, Gateway APIs, persistent storage, external object storage, and documented upgrade paths. **goharbor/harbor-helm** — The helm chart to deploy Harbor - Repository: https://github.com/goharbor/harbor-helm - Stars: 1,532 · Forks: 869 - Language: Mustache - License: Apache-2.0 - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/goharbor-harbor-helm ## What harbor-helm manages goharbor/harbor-helm packages the Harbor deployment as a Helm chart for Kubernetes. The problem it addresses is installation and configuration of Harbor in a cluster, rather than the internal behavior of Harbor itself. The repository README directs functional Harbor issues to goharbor/harbor, while this repository focuses on issues involving deployment through Helm. The chart is aimed at operators who already have a Kubernetes cluster and want Harbor exposed according to the cluster's networking model. Its documented prerequisites are Kubernetes 1.20 or later and Helm v3.2.0 or later. The repository contains Chart.yaml, templates/, values.yaml, test/, and documentation for upgrades and high availability. That layout indicates that the chart renders Kubernetes resources from configurable values and includes repository-level tests, but the README excerpt does not describe the rendered resource inventory in full. ## Exposure modes and the Harbor URL The most consequential installation choice is `expose.type`. The documented values are `ingress`, `clusterIP`, `nodePort`, and `loadBalancer`. Ingress requires an ingress controller in the cluster. ClusterIP keeps the service reachable only inside the cluster. NodePort exposes the service on each Kubernetes node at a static port, so clients use `NodeIP:NodePort`. LoadBalancer uses a cloud provider's load balancer and normally requires a DNS record mapping a domain to the assigned address. The chart also documents Gateway APIs exposure using HTTPRoute and says that this path requires Gateway API CRDs version v1.0.0 or later. The values table shown in the README lists four values for `expose.type`, so the Gateway API description should be checked against the complete chart values before relying on it. `externalURL` is not merely cosmetic. The README says Harbor uses it to populate Docker and Helm commands shown in the portal and the token service URL returned to Docker clients. Its format is `protocol://domain[:port]`. The correct domain depends on exposure mode: an Ingress host, the ClusterIP service name, a Kubernetes node address for NodePort, or a custom domain associated with a cloud load balancer. If Harbor is behind a proxy, the README says to configure the proxy URL. ## Persistence, TLS, and external storage Harbor data has different lifecycle choices. The `Disable` storage option means data does not survive termination of a pod. The default is a Persistent Volume Claim, which requires a default `StorageClass` if volumes are to be provisioned dynamically. Operators can select another storage class or provide an existing claim. For images and charts, the README also lists external storage backends: `azure`, `gcs`, `s3`, `swift`, and `oss`. That support is limited to images and charts according to the documentation, so it should not be interpreted as external storage for every Harbor data category. TLS is enabled by default according to the values table. When TLS is disabled for an Ingress deployment, the README specifically calls out two consequences: the `ssl-redirect` annotation should be removed from `expose.ingress.annotations`, and clients must include the port in image pull and push commands. These are operational requirements, not optional refinements. They also show that installation and client access must be configured as one workflow. ## Installing the chart for a first deployment The README provides a short Helm-based installation path. First add the Harbor chart repository. The command below registers the repository under the local name `harbor`. ```bash helm repo add harbor https://helm.goharbor.io ``` Before installing, choose the exposure mode, persistence behavior, external URL, and TLS settings. The README says values can be supplied with the `--set` flag or by editing `values.yaml` after downloading the chart. No single complete production configuration is given in the excerpt, so the values should be selected for the cluster rather than copied from an unspecified example. Install the chart with a Helm release name of `my-release`: ```bash helm install my-release harbor/harbor ``` After installation, the expected next check is access through the configured exposure type and URL. For Ingress, the reader should have an ingress controller and should use the configured core host. For ClusterIP, access is internal. For NodePort, the client needs the node IP and allocated port. For LoadBalancer, the domain must resolve to the provider-assigned load balancer address. The README does not document a post-install health check command, so no such command should be inferred. ## Upgrades and the stable-branch warning The README warns that the `master` branch is in heavy development and recommends using other stable versions instead. That warning matters for operators using the `master` branch while planning an installation. The repository provides an upgrade guide at `docs/Upgrade.md`, and the top-level `docs/` directory includes a high-availability guide at `docs/High%20Availability.md`. Recent releases listed for the repository are `v1.19.2` with `v2.15.2` on 2026-08-03, `v1.19.1` on 2026-05-27, and `v1.18.4` on 2026-05-27. These release labels show that chart versions and corresponding Harbor versions are not always identical. The parentheses around `v2.15.2` are part of the release information, so an operator should confirm which chart and Harbor version pairing is intended before deploying. The repository was not archived, and its last push was on 2026-10-16. That is a recent repository activity signal, but the README's branch warning still applies when choosing between development and stable versions. Upgrade planning should use the documented guide rather than assuming that a new chart release can be applied without reviewing Harbor data and configuration changes. ## Operational boundaries of the chart The main limitation is scope. This repository is for deploying Harbor through Helm. It does not replace the Harbor project for questions about registry behavior, image operations, or other Harbor functionality, because the README directs those questions elsewhere. There is also a deployment-level constraint around storage. Choosing `Disable` loses image and chart data when a pod terminates, which is unsuitable for a deployment where persistence is required. Using the default PVC mode introduces a dependency on Kubernetes storage provisioning. External storage narrows the supported data scope to images and charts. Networking introduces further operational decisions. An Ingress deployment without TLS changes the commands clients must use. A ClusterIP service cannot serve external clients directly. NodePort requires access to a node IP and the assigned port. A LoadBalancer deployment depends on the cloud provider and DNS mapping. Gateway API exposure has a separate CRD version requirement. These are not necessarily chart defects, but they make the chart unsuitable for clusters that cannot satisfy the selected network and storage prerequisites. ## Harbor Helm chart versus direct Harbor deployment The documented alternative is to use the Harbor project directly, at `goharbor/harbor`, for Harbor functionality and Harbor-specific issues. The difference is not an independent implementation of the registry described here. This repository packages deployment for Kubernetes through Helm, while goharbor/harbor is the project to consult for Harbor features and operational questions outside Helm chart deployment. For a Kubernetes operator, the chart offers configuration through `values.yaml` and `--set`, multiple service exposure modes, storage choices, and a documented upgrade path. A direct Harbor installation would not use this chart's Helm release, values, templates, or Kubernetes exposure settings. The README does not provide a direct-install procedure. ## Conclusion Adopt goharbor/harbor-helm when the deployment target is Kubernetes and the team can manage Helm release values, storage, ingress, and Harbor upgrades. Do not choose it for Helm-independent Harbor installations or for questions about Harbor application functionality, which belong in goharbor/harbor. Verify the chart version, exposure type, external URL, TLS settings, persistence configuration, and upgrade documentation before installing a production release. ## FAQ ### What are the prerequisites for installing goharbor/harbor-helm? The README requires Kubernetes 1.20 or later and Helm v3.2.0 or later. Ingress exposure also requires an ingress controller, while Gateway APIs exposure requires Gateway API CRDs version v1.0.0 or later. ### How do I install Harbor with goharbor/harbor-helm? Add the chart repository with `helm repo add harbor https://helm.goharbor.io`, then install the chart with `helm install my-release harbor/harbor`. The README says chart settings can be supplied with `--set` or configured in `values.yaml`. ### Which storage and exposure options does goharbor/harbor-helm support? The README documents disabled storage, Persistent Volume Claims, and external storage for images and charts through `azure`, `gcs`, `s3`, `swift`, and `oss`. Exposure options described include Ingress, ClusterIP, NodePort, LoadBalancer, and Gateway APIs using HTTPRoute. ### Where should I report a Harbor functionality issue rather than a Helm chart issue? The README says functional Harbor issues should be opened in `goharbor/harbor`. This repository focuses on deploying the Harbor chart through Helm. ## Sources - [goharbor/harbor-helm on GitHub](https://github.com/goharbor/harbor-helm) - [Issues](https://github.com/goharbor/harbor-helm/issues) - [License: Apache-2.0](https://github.com/goharbor/harbor-helm/blob/main/LICENSE) - [README](https://github.com/goharbor/harbor-helm/blob/main/README.md) - [Releases](https://github.com/goharbor/harbor-helm/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/goharbor-harbor-helm