What Is Helm in Kubernetes? Charts and values.yaml on EKS

Helm explained simply

Running a real application on Kubernetes means creating a Deployment, a Service, possibly an Ingress, a ConfigMap, and more. That is many YAML files to write, keep in sync, and apply in the right order.

Helm solves this by:

• Packaging all those YAML files into a single chart you can share and reuse
• Configuring the chart for your environment using a values.yaml file
• Installing the chart as a named release and recording everything it created
• Upgrading the release when you change config or move to a newer chart version
• Rolling back to any previous state if something breaks

You interact with Helm through the helm CLI. It communicates with the Kubernetes API using your existing kubeconfig, with no extra cluster-side component required.

Core Helm concepts

There are four ideas worth understanding clearly before running your first command.

Chart: a directory of YAML templates and a default values.yaml file. A chart describes how to deploy an application or tool. Charts are versioned and shareable; thousands are published on Artifact Hub and in vendor-maintained repositories.

Release: a running instance of a chart in your cluster. If you install the same chart twice under different names, you get two independent releases, each with their own Kubernetes resources and revision history. Upgrading or rolling back one release does not affect the other.

Repository: a collection of charts, similar to a package registry. You add repos by URL using helm repo add, then pull charts from them by name.

Values: the variables that configure a chart. Every chart ships with defaults in values.yaml. You override them with your own values file or --set flags at install time. Values are what make a single chart work across development, staging, and production without duplicating templates.

Why teams use Helm on Amazon EKS

A fresh EKS cluster ships with very little pre-installed. Teams use Helm to add the components their clusters need:

• AWS Load Balancer Controller: manages Application Load Balancers for Kubernetes Services and Ingress resources. The official AWS installation method is Helm.
• cert-manager: automates TLS certificate issuance and renewal. Distributed as a Helm chart from the Jetstack repository.
• Prometheus and Grafana: the standard Kubernetes monitoring stack. The kube-prometheus-stack chart brings up the whole setup in minutes. See Monitoring EKS Clusters.
• Fluent Bit: ships container logs to CloudWatch or OpenSearch. Available from the EKS charts repository. See Logging in Kubernetes on AWS.
• Argo CD, External Secrets, External DNS: popular GitOps and platform tools, all distributed as Helm charts.

Beyond third-party tools, teams use Helm for their own applications when the same deployment needs to run across multiple environments with different configuration: different image tags, replica counts, or hostnames. A single chart with per-environment values files handles this cleanly.

Install Helm

Before using Helm you need a working Kubernetes cluster with kubectl configured. If you have not done that yet, start with creating your first EKS cluster.

# macOS
brew install helm

# Linux (official install script)
curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

# Windows (Chocolatey)
choco install kubernetes-helm

# Verify the installation
helm version

Helm uses your existing kubeconfig context to communicate with the cluster, the same context that kubectl uses. There is no server-side component to install on the cluster.

Add repositories and search for charts

# Add common repositories
helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo add eks https://aws.github.io/eks-charts
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo add cert-manager https://charts.jetstack.io

# Update the local cache of chart metadata
helm repo update

# Search charts in your added repositories
helm search repo nginx

# Search Artifact Hub (the public Helm chart registry)
helm search hub cert-manager

helm search repo searches the repositories you have added locally using a cached index. helm search hub searches Artifact Hub directly, which indexes charts from hundreds of publishers.

Install and configure a chart

The recommended flow is: install a chart, then customise it with a values file stored in version control.

Step 1: install a chart into a dedicated namespace

# helm install <release-name> <repo/chart>
helm install my-nginx bitnami/nginx \
  --namespace web \
  --create-namespace

Step 2: override a value inline (quick tests only)

helm install my-nginx bitnami/nginx \
  --set replicaCount=3 \
  --set service.type=ClusterIP \
  --namespace web \
  --create-namespace

Step 3: use a values file (recommended for everything else)

First, inspect the chart’s available options:

helm show values bitnami/nginx

Create a my-values.yaml overriding only what you need:

# my-values.yaml
replicaCount: 3

service:
  type: ClusterIP

resources:
  requests:
    cpu: 100m
    memory: 128Mi
  limits:
    cpu: 500m
    memory: 256Mi

ingress:
  enabled: true
  hostname: myapp.example.com
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing

Install using the file:

helm install my-nginx bitnami/nginx \
  --values my-values.yaml \
  --namespace web

Store your values files in Git alongside your application code. They are the auditable record of how a release is configured in each environment.

Common Helm commands

Inspect releases

# List releases in the current namespace
helm list

# List across all namespaces
helm list --all-namespaces

# Check the status of a specific release
helm status my-nginx --namespace web

# See all revisions of a release
helm history my-nginx --namespace web

Upgrade a release

# Upgrade with updated values
helm upgrade my-nginx bitnami/nginx \
  --values my-values.yaml \
  --namespace web

# Upgrade to a specific chart version
helm upgrade my-nginx bitnami/nginx \
  --version 18.1.0 \
  --values my-values.yaml \
  --namespace web

Roll back

# Roll back to the previous revision
helm rollback my-nginx --namespace web

# Roll back to a specific revision number
helm rollback my-nginx 2 --namespace web

Each helm upgrade creates a new revision. helm rollback restores the Kubernetes resources to exactly the state they were in at the target revision, including reverting configuration changes made during the upgrade. When upgrading EKS clusters, you may also need to upgrade chart versions for compatibility with the new Kubernetes version.

Uninstall

helm uninstall my-nginx --namespace web

This removes all Kubernetes resources Helm created for the release. You do not need the original YAML files because Helm tracks what it created in a Kubernetes Secret.

Helm vs kubectl vs Kustomize

All three tools apply configuration to a Kubernetes cluster. They solve different problems.

Most EKS clusters use all three: kubectl for inspection and debugging, Helm for third-party tools, and Kustomize or plain YAML for in-house applications.

When to use Helm and when not to

Use Helm when:

• Installing third-party tools that are already distributed as charts: the AWS Load Balancer Controller, Prometheus, cert-manager, Argo CD, Fluent Bit.
• You need the same application deployed across development, staging, and production with different configuration per environment.
• You want versioned releases with upgrade and rollback history.

Skip Helm when:

• Your application has simple, stable configuration that does not change between environments.
• You own the base manifests and prefer per-environment patches over templating. Kustomize is a better fit.
• You want every byte of YAML visible and reviewable without a rendering step.

Real-world EKS example

A platform team manages three EKS clusters: development, staging, and production. Each cluster needs the same infrastructure components: the AWS Load Balancer Controller, External DNS, cert-manager, Prometheus and Grafana, and Fluent Bit.

The team maintains a cluster-platform Git repository with one directory per component, each containing a values file per environment:

cluster-platform/
  aws-load-balancer-controller/
    values-dev.yaml
    values-staging.yaml
    values-prod.yaml
  cert-manager/
    values.yaml
  kube-prometheus-stack/
    values-dev.yaml
    values-prod.yaml
  fluent-bit/
    values.yaml

A bootstrap script runs helm upgrade --install for each component in order, using the matching values file. Setting up a new cluster takes under 30 minutes, and every component version and configuration value is tracked in Git.

When a chart needs upgrading, the team bumps the version in the values file, opens a pull request, and applies with helm upgrade. If the upgrade breaks something, helm rollback restores the previous state while they investigate.

For security practices that apply to this setup, see Securing EKS Clusters.