Skip to content
Back to glossary
Kubernetes Tools

What is Helm?

Helm is the Kubernetes package manager. It turns a multi-file application (Deployment, Service, Ingress, ConfigMap) into a single, parameterised and versioned chart.

What Helm does

Helm is the standard packaging tool of the Kubernetes ecosystem, equivalent to apt for Debian or npm for Node.js. It solves a simple problem: a typical Kubernetes application consists of several resources (Deployment, Service, Ingress, ConfigMap, Secret, PVC, ServiceAccount, NetworkPolicy), spread across 5 to 15 YAML files. Hand-managing those files is viable for one application, unmanageable for fifty.

Helm solves this by wrapping a coherent set of manifests in a chart: a structured directory containing template files, default values, dependencies and version metadata. The chart becomes the deployment unit.

The chart concept

A Helm chart has three central elements:

  • Templates: Kubernetes manifests parameterised with Go-template syntax, e.g. {{ .Values.image.tag }} instead of 1.2.3 hard-coded.
  • values.yaml: the chart's default values (image, CPU/RAM resources, replicas, annotations).
  • Chart.yaml: metadata (name, version, dependencies, maintainers).

At install time, the operator passes a values-prod.yaml or values-staging.yaml file that overrides the defaults. The same chart can therefore deploy a service in dev with 1 replica and 100 Mi of memory, or in production with 10 replicas and 2 Gi.

Why Helm became a standard

Industrial reuse. Artifact Hub lists more than 12,000 public charts (Prometheus, Grafana, PostgreSQL, ArgoCD, cert-manager, ingress-nginx, etc.). Installing a full observability stack on Kubernetes is a single helm install, not a day of YAML.

Versioning and rollback. Every helm upgrade is versioned as a release. helm rollback my-app 3 brings the application back to the state of its 3rd release. The typical time to roll back a broken deployment drops from minutes to seconds.

Standard for software distribution. Open Source vendors almost always ship official charts. For a proprietary product, distributing a private chart has become the norm for on-premise installations at customer sites.

Helm 2 vs Helm 3

An important historical nuance: Helm 2 (deprecated in 2020) included a server-side component (Tiller) with major security issues (cluster-wide privileges, no identity management). Helm 3 removed Tiller: the tool is now purely client-side, with no daemon and no dedicated RBAC. All new deployments must use Helm 3.

When Helm is not optimal

For very environment-specific configurations (a single cluster, few variations), Kustomize offers a more declarative, less template-heavy syntax. Many teams combine the two: Helm for third-party components, Kustomize for internal overlays.

For very dynamic applications where configuration changes at runtime (feature flags, A/B testing), Helm remains a deployment tool, not a runtime configuration tool. Solutions like ConfigMaps + custom operators take over.

In practice at Hidora

On Kubernetes engagements, we systematically deploy clients on Helm 3 with a standardised structure:

  • Internal charts for client applications (versioned in Git)
  • Public charts for third-party components (Prometheus, ingress-nginx, cert-manager)
  • ArgoCD configured to reconcile Applications pointing at the charts

Related Hidora services

  • Consulting: internal chart design, training the development team to produce maintainable charts.
  • Managed Services: chart operation and updates in production with pre-deployment validation.
  • Kubernetes, GitOps, ArgoCD: associated bricks in the delivery chain.