How to Deploy Helm Chart

Helm is the package manager for Kubernetes, designed to simplify the deployment, management, and scaling of applications on Kubernetes clusters. A Helm chart is a collection of files that describe a related set of Kubernetes resources from deployments and services to config maps and secrets. Deploying a Helm chart allows you to install complex applications with a single command, eliminating the need to manually manage dozens of YAML files. Whether you're deploying a simple web application or a multi-tier microservice architecture, Helm streamlines the process, reduces human error, and ensures consistency across environments.

As Kubernetes adoption continues to grow across enterprises, the need for efficient, repeatable, and version-controlled deployment methods has never been greater. Helm fills this gap by providing templating, dependency management, and release lifecycle control. This tutorial will guide you through every step of deploying a Helm chart from setting up your environment to troubleshooting common issues with best practices, real-world examples, and essential tools to help you master the process.

Step-by-Step Guide

Prerequisites

Before deploying a Helm chart, ensure your environment meets the following requirements:

• Kubernetes Cluster: You must have a running Kubernetes cluster. This can be local (Minikube, Kind, Docker Desktop) or cloud-based (Amazon EKS, Google GKE, Azure AKS).
• kubectl: The Kubernetes command-line tool must be installed and configured to communicate with your cluster. Verify this by running kubectl cluster-info.
• Helm CLI: Install the latest stable version of Helm. You can download it from the official Helm installation page or use package managers like Homebrew (brew install helm) or apt (apt-get install helm).
• Basic Understanding of YAML: Helm charts are defined using YAML templates. Familiarity with Kubernetes resource definitions (Deployments, Services, ConfigMaps) is highly recommended.

Step 1: Verify Helm Installation

After installing Helm, verify the installation by checking the version:

helm version

You should see output similar to:

version.BuildInfo{Version:"v3.14.0", GitCommit:"...", GitTreeState:"clean", GoVersion:"go1.21.6"}

If you see an error, revisit the installation steps. Ensure Helm is in your systems PATH.

Step 2: Add Helm Repositories

Helm charts are distributed through repositories. The most popular public repository is artifacthub.io, which hosts thousands of charts from official and community sources. To access charts, you must first add the relevant repositories to your Helm client.

For example, to add the official Helm stable repository (now deprecated) or the newer Bitnami repository:

helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update

The helm repo update command refreshes your local cache of chart versions. To list all added repositories:

helm repo list

Common repositories include:

• Bitnami: https://charts.bitnami.com/bitnami reliable, well-maintained charts for databases, web servers, and messaging systems.
• Jetstack: https://charts.jetstack.io for cert-manager and other Kubernetes-native tools.
• Prometheus Community: https://prometheus-community.github.io/helm-charts for monitoring stacks.

Step 3: Search for a Helm Chart

Once repositories are added, search for a chart using:

helm search repo bitnami/nginx

This returns available versions of the Nginx chart from the Bitnami repository. Example output:

NAME              	CHART VERSION	APP VERSION	DESCRIPTION
bitnami/nginx     	15.4.2       	1.25.3     	Chart for the nginx server

You can also search globally:

helm search hub nginx

This queries Artifact Hub for all available charts with nginx in the name.

Step 4: Inspect the Chart

Before deploying, always inspect the charts contents, values, and dependencies. Use:

helm show chart bitnami/nginx

This displays metadata such as chart name, version, app version, dependencies, and keywords.

To view the default configuration values:

helm show values bitnami/nginx

This outputs a large YAML file containing all configurable parameters ports, replicas, resource limits, ingress settings, and more. Reviewing this helps you understand what can be customized before installation.

Step 5: Customize Values (Optional)

While Helm charts come with sensible defaults, most production deployments require customization. Create a custom values file to override defaults without modifying the original chart.

Create a file named nginx-values.yaml:

replicaCount: 3
service:
type: LoadBalancer
port: 80
ingress:
enabled: true
hostname: myapp.example.com
resources:
limits:
cpu: 500m
memory: 512Mi
requests:
cpu: 200m
memory: 256Mi

This configuration increases replicas to 3, exposes the service via a cloud LoadBalancer, enables ingress with a custom hostname, and sets resource constraints for efficiency and cost control.

Step 6: Install the Helm Chart

Now deploy the chart using the helm install command:

helm install my-nginx bitnami/nginx -f nginx-values.yaml

Breakdown of the command:

• my-nginx the release name. Choose a unique, descriptive name. This is how Helm tracks the deployment.
• bitnami/nginx the chart name (repository/chart-name).
• -f nginx-values.yaml applies your custom configuration.

Helm will output a summary of installed resources:

NAME: my-nginx
LAST DEPLOYED: Thu Apr  4 10:30:15 2024
NAMESPACE: default
STATUS: deployed
REVISION: 1
NOTES:
1. Get the application URL by running these commands:
export POD_NAME=$(kubectl get pods --namespace default -l "app.kubernetes.io/name=nginx,app.kubernetes.io/instance=my-nginx" -o jsonpath="{.items[0].metadata.name}")
echo "Visit http://127.0.0.1:8080 to use your application"
kubectl port-forward $POD_NAME 8080:80

At this point, Helm has created all Kubernetes resources defined in the chart Deployments, Services, ConfigMaps, and possibly Ingress rules.

Step 7: Verify the Deployment

Check the status of your release:

helm list

Output:

NAME      	NAMESPACE	REVISION	UPDATED                                	STATUS  	CHART       	APP VERSION
my-nginx  	default  	1       	2024-04-04 10:30:15.737123 +0000 UTC   	deployed	nginx-15.4.2	1.25.3

Verify Kubernetes resources:

kubectl get pods
kubectl get svc
kubectl get ingress

If ingress is enabled and you have a DNS record pointing to the LoadBalancer IP, access your application via the configured hostname. If not, use port-forwarding:

kubectl port-forward svc/my-nginx 8080:80

Then open http://localhost:8080 in your browser.

Step 8: Upgrade and Rollback

Helms real power lies in its ability to manage releases over time. To upgrade your chart:

• Modify your nginx-values.yaml file (e.g., increase replicas to 5).
• Run:

helm upgrade my-nginx bitnami/nginx -f nginx-values.yaml

Helm will apply the changes incrementally, preserving existing resources and updating only whats necessary.

To view the revision history:

helm history my-nginx

If an upgrade fails or introduces instability, rollback to a previous revision:

helm rollback my-nginx 1

This reverts the release to revision 1, restoring the previous working state.

Step 9: Uninstall the Chart

To remove the application and all associated resources:

helm uninstall my-nginx

Helm will delete all Kubernetes objects created by the chart. To list all releases (including deleted ones):

helm list --all

By default, Helm retains release history for audit and rollback purposes. To purge the release entirely (including history):

helm uninstall my-nginx --purge

Note: In Helm 3, --purge is the default behavior. The --keep-history flag can be used to retain history if needed.

Best Practices

Use Custom Values Files, Not Inline Overrides

Always use a dedicated values file (e.g., prod-values.yaml, staging-values.yaml) rather than passing overrides via --set on the command line. Inline overrides are difficult to version control, audit, and reuse across environments. Values files should be stored in your Git repository alongside your application code.

Version Control Your Charts and Values

Treat your Helm charts and values files as code. Store them in version control (Git) with meaningful commit messages. This enables:

• Change tracking
• Peer reviews
• CI/CD integration
• Rollback capability

Organize your repository structure like this:

my-app/
??? charts/
?   ??? nginx/
?   ?   ??? Chart.yaml
?   ?   ??? values.yaml
??? overlays/
?   ??? dev/
?   ?   ??? values.yaml
?   ??? staging/
?   ?   ??? values.yaml
?   ??? prod/
?       ??? values.yaml
??? README.md

Use Helmfile for Multi-Chart Deployments

For applications composed of multiple charts (e.g., frontend, backend, database, Redis), use Helmfile. Helmfile is a declarative specification for deploying multiple Helm charts at once. Define all releases in a single helmfile.yaml:

releases:
- name: my-nginx
namespace: default
chart: bitnami/nginx
values:
- values/nginx-values.yaml
- name: my-postgres
namespace: default
chart: bitnami/postgresql
values:
- values/postgres-values.yaml

Then deploy with:

helmfile sync

Implement Environment-Specific Values

Never use the same values file across environments. Create separate files for dev, staging, and production. Use tools like ytt or kustomize to overlay environment-specific changes on top of a base values file.

Set Resource Limits and Requests

Always define CPU and memory limits and requests in your values files. This prevents resource starvation and ensures fair scheduling across nodes. Example:

resources:
limits:
cpu: 1000m
memory: 1Gi
requests:
cpu: 200m
memory: 256Mi

Without these, Kubernetes may schedule pods inefficiently, leading to node overcommit and instability.

Use Labels and Annotations Consistently

Ensure all resources in your chart use consistent labels (e.g., app.kubernetes.io/name, app.kubernetes.io/instance) as per Kubernetes best practices. This enables better monitoring, service discovery, and automation.

Validate Charts Before Deployment

Use helm template to render templates locally without installing:

helm template my-nginx bitnami/nginx -f nginx-values.yaml

This outputs the final rendered YAML. Inspect it for errors, missing values, or misconfigurations before applying to the cluster.

Secure Your Helm Repositories

If using private Helm repositories (e.g., Harbor, ChartMuseum), authenticate using credentials or TLS certificates. Never expose private charts publicly. Use Helms --username and --password flags or configure credentials in ~/.helm/repositories.yaml.

Monitor Releases and Set Alerts

Use tools like Prometheus and Grafana to monitor Helm-deployed applications. Track metrics such as pod restarts, memory usage, and HTTP error rates. Set up alerts for failed releases or degraded performance.

Regularly Update Charts

Charts and their underlying applications evolve. Regularly check for chart updates:

helm repo update
helm search repo --versions bitnami/nginx

Upgrade only after testing in a non-production environment. Avoid deploying untested versions to production.

Tools and Resources

Core Tools

• Helm CLI: The primary tool for managing charts. Download from GitHub Releases.
• kubectl: Essential for inspecting deployed resources. Ensure its compatible with your cluster version.
• Helmfile: For managing multiple Helm releases across environments. GitHub: roboll/helmfile.
• Kustomize: A native Kubernetes configuration management tool. Often used alongside Helm for patching and overlays.
• ytt: A templating tool from Carvel that works well with Helm for advanced YAML manipulation.

Chart Repositories

• Artifact Hub: https://artifacthub.io the central hub for discovering Helm charts, operators, and OLM packages.
• Bitnami: https://github.com/bitnami/charts widely trusted, frequently updated charts for common applications.
• Jetstack: https://github.com/jetstack/cert-manager for TLS certificate automation.
• Prometheus Community: https://github.com/prometheus-community/helm-charts for monitoring stacks.
• HashiCorp: https://github.com/hashicorp/helm-charts for Vault, Consul, Nomad.

CI/CD Integration

Integrate Helm into your CI/CD pipeline for automated deployments:

• GitHub Actions: Use the helm/actions-helm action to install charts on push to main.
• GitLab CI: Use Helm in your .gitlab-ci.yml with the helm Docker image.
• Argo CD: A GitOps tool that can natively deploy Helm charts from Git repositories.
• Flux CD: Another GitOps operator that supports HelmRelease custom resources.

Validation and Linting Tools

• helm lint: Built-in command to validate chart structure and syntax.
• kubeval: Validates Kubernetes YAML against schemas.
• kube-score: Analyzes Kubernetes manifests for best practices and potential issues.
• checkov: Infrastructure-as-code scanner that supports Helm charts.

Documentation and Learning

• Helm Documentation: https://helm.sh/docs/ official, comprehensive guide.
• Helm Chart Best Practices: https://helm.sh/docs/chart_best_practices/ essential reading for developers.
• YouTube Tutorials: Search for Helm Chart Deployment Tutorial for visual walkthroughs.
• Books: Kubernetes Up and Running by Kelsey Hightower et al. includes Helm chapters.

Real Examples

Example 1: Deploying WordPress with MySQL

Deploying a full-stack application like WordPress requires two charts: one for the web application and one for the database.

Step 1: Add the Bitnami repository:

helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update

Step 2: Create a values file wordpress-values.yaml:

wordpressUsername: admin
wordpressPassword: mysecretpassword123
wordpressEmail: admin@example.com
service:
type: LoadBalancer
ingress:
enabled: true
hostname: wordpress.example.com
annotations:
cert-manager.io/cluster-issuer: letsencrypt-prod
database:
mariadb:
auth:
rootPassword: mydbrootpass
database: wordpress_db
username: wp_user
password: wp_password
persistence:
enabled: true
size: 10Gi
resources:
limits:
cpu: 500m
memory: 1Gi
requests:
cpu: 200m
memory: 512Mi

Step 3: Install the chart:

helm install my-wordpress bitnami/wordpress -f wordpress-values.yaml

Step 4: Wait for the LoadBalancer IP and access WordPress via the configured hostname.

This example demonstrates multi-chart dependency, secure credential handling, and ingress configuration all managed through Helm.

Example 2: Deploying a Custom Internal Application

Suppose you have a Node.js microservice packaged in a Docker image and want to deploy it using a custom Helm chart.

Step 1: Create a chart structure:

my-app/
??? Chart.yaml
??? values.yaml
??? templates/
?   ??? deployment.yaml
?   ??? service.yaml
?   ??? ingress.yaml
?   ??? NOTES.txt
??? charts/

Step 2: Define Chart.yaml:

apiVersion: v2
name: my-app
description: A custom Node.js microservice
type: application
version: 1.0.0
appVersion: "1.0"

Step 3: Define values.yaml:

image:
repository: myregistry.example.com/my-app
tag: latest
pullPolicy: IfNotPresent
replicaCount: 2
service:
type: ClusterIP
port: 80
ingress:
enabled: true
hostname: myapp.internal.company.com
resources:
limits:
cpu: 1000m
memory: 1Gi
requests:
cpu: 200m
memory: 512Mi

Step 4: Create templates/deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
name: {{ include "my-app.fullname" . }}
labels:
{{- include "my-app.labels" . | nindent 4 }}
spec:
replicas: {{ .Values.replicaCount }}
selector:
matchLabels:
{{- include "my-app.selectorLabels" . | nindent 6 }}
template:
metadata:
labels:
{{- include "my-app.selectorLabels" . | nindent 8 }}
spec:
containers:
- name: {{ .Chart.Name }}
image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
imagePullPolicy: {{ .Values.image.pullPolicy }}
ports:
- containerPort: {{ .Values.service.port }}
resources:
{{ toYaml .Values.resources | indent 12 }}

Step 5: Install the chart locally:

helm install my-app ./my-app

This example shows how to create your own Helm chart a critical skill for teams building internal tools or proprietary software.

Example 3: CI/CD Pipeline with GitHub Actions

Automate Helm deployments using GitHub Actions. Create .github/workflows/deploy.yml:

name: Deploy to Kubernetes
on:
push:
branches: [ main ]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Set up Helm
uses: azure/setup-helm@v3
with:
version: v3.14.0
- name: Add Helm Repository
run: |
helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update
- name: Install WordPress
run: |
helm install my-wordpress bitnami/wordpress -f values/prod-values.yaml --namespace default --create-namespace

This pipeline triggers on every push to the main branch, ensuring your application is always in sync with your codebase.

FAQs

What is the difference between Helm and kubectl apply?

kubectl apply deploys individual YAML manifests directly to Kubernetes. Its simple but lacks features like templating, dependency management, and release history. Helm, on the other hand, packages multiple YAML files into a chart, allows dynamic templating with Go templates, tracks releases, and supports upgrades and rollbacks. Use kubectl apply for simple, static deployments; use Helm for complex, version-controlled applications.

Can I use Helm with any Kubernetes cluster?

Yes. Helm works with any conformant Kubernetes cluster whether its running on-premises, in the cloud (EKS, GKE, AKS), or locally (Minikube, Kind). Helm is a client-side tool; it communicates with the Kubernetes API server via kubectl context, so as long as your cluster is accessible, Helm can deploy to it.

How do I create my own Helm chart?

Use the helm create command:

helm create mychart

This generates a directory structure with default templates, values, and metadata. Customize the templates, add your own resources, and update Chart.yaml and values.yaml to match your application. Test with helm lint and helm install --dry-run before publishing.

What happens if a Helm installation fails?

Helm performs a rollback automatically if the deployment fails (e.g., pods crashlooping). You can check the status with helm list and view logs with helm history. Use helm rollback to revert to a previous working revision. Always test charts in staging before deploying to production.

Are Helm charts secure?

Helm charts themselves are not inherently secure theyre just YAML templates. Security depends on how theyre configured. Always:

• Use non-root users in containers
• Set resource limits
• Validate image sources
• Use secrets instead of hardcoded credentials
• Scan charts with tools like Trivy or Checkov

Can Helm manage stateful applications like databases?

Yes. Helm charts for databases (PostgreSQL, MySQL, Redis) are widely available and handle persistent volumes, init containers, and cluster configurations. However, stateful applications require careful planning around backups, replication, and data persistence. Always use persistent volume claims and test recovery procedures.

How do I share my Helm chart with my team?

Package your chart with helm package ./mychart, which creates a mychart-1.0.0.tgz file. Share this file or host it in a private Helm repository using tools like Harbor, ChartMuseum, or GitHub Packages. Alternatively, store the chart source in your Git repository and use helm install ./mychart to install directly from source.

What is the difference between Helm 2 and Helm 3?

Helm 3 removed Tiller (the server-side component), making it client-only and more secure. It also introduced namespace-scoped releases, improved chart structure, and better dependency handling. Helm 2 is deprecated. Always use Helm 3 for new deployments.

Conclusion

Deploying Helm charts is a foundational skill for modern Kubernetes operations. By abstracting complexity into reusable, version-controlled packages, Helm empowers teams to deploy applications faster, more reliably, and with greater consistency. From installing pre-built charts like Nginx and WordPress to creating custom charts for internal microservices, the patterns and practices outlined in this guide provide a comprehensive roadmap for success.

Remember: Helm is not a magic bullet. Its power comes from disciplined use version-controlled values, environment-specific configurations, automated testing, and CI/CD integration. Treat your Helm charts as production-grade code, not temporary scripts. Invest time in learning chart structure, templating, and best practices. The upfront effort pays off in reduced deployment errors, faster rollouts, and increased team productivity.

As Kubernetes continues to evolve, Helm remains its most trusted companion for application deployment. Whether you're a developer, DevOps engineer, or platform operator, mastering Helm chart deployment is not optional its essential. Start small, experiment in non-production environments, and gradually adopt advanced patterns like Helmfile and GitOps. The future of application delivery is declarative, automated, and chart-driven and youre now equipped to lead it.