Helm is the de facto package manager for Kubernetes, allowing you to define, install, and upgrade complex applications using reusable chart packages. On RHEL 8, Helm integrates cleanly with an existing kubectl configuration, making it straightforward to deploy and manage workloads across your cluster. This tutorial walks you through installing Helm, working with chart repositories, and understanding the chart structure used to template Kubernetes manifests. By the end you will be able to install, upgrade, roll back, and remove applications on Kubernetes using Helm charts.

Prerequisites

  • RHEL 8 host with a working kubectl context pointed at a running Kubernetes cluster
  • Internet access from the host to reach get.helm.sh and chart repositories
  • A non-root user with sudo privileges or a root shell
  • curl and tar installed (dnf install -y curl tar)

Step 1 — Install Helm via the Official Install Script

The Helm project provides a convenience script that detects your OS and architecture, downloads the correct binary, and places it in /usr/local/bin.

curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

helm version

You should see output similar to version.BuildInfo{Version:"v3.x.x", ...}. If you prefer a manual install, download the tarball from https://github.com/helm/helm/releases, extract it, and move the helm binary to /usr/local/bin/helm.

Step 2 — Add Chart Repositories

Helm charts are distributed through HTTP repositories. The Bitnami repository is one of the most popular and contains hundreds of production-ready charts.

helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update
helm search repo bitnami/nginx
helm search repo bitnami/ --output table | head -20

helm repo update refreshes the local cache from all configured repositories. Use helm search hub <keyword> to search the public Artifact Hub if you are looking for community charts beyond your configured repos.

Step 3 — Install, Upgrade, and Roll Back a Release

A Helm release is a named instance of a chart deployed to a namespace. The following commands deploy NGINX, upgrade it, and demonstrate a rollback.

# Install a release named "my-nginx" into the default namespace
helm install my-nginx bitnami/nginx --namespace default

# List all releases
helm list -A

# Upgrade the release (e.g., change the replica count)
helm upgrade my-nginx bitnami/nginx --set replicaCount=2

# View release history
helm history my-nginx

# Roll back to revision 1
helm rollback my-nginx 1

# Uninstall the release
helm uninstall my-nginx

Every helm upgrade creates a new revision, so helm rollback can target any previous revision number shown in helm history.

Step 4 — Override Values with --set and Custom Value Files

Every chart exposes configurable parameters through its values.yaml. You can override individual keys inline or supply a complete override file.

# Inspect default values
helm show values bitnami/nginx > default-values.yaml

# Install with an inline override
helm install my-nginx bitnami/nginx --set service.type=NodePort --set replicaCount=3

# Create a custom values file
cat > custom-values.yaml <<'EOF'
replicaCount: 2
service:
  type: LoadBalancer
  port: 8080
EOF

# Install using the custom file
helm install my-nginx bitnami/nginx -f custom-values.yaml

When both -f and --set are used together, --set values take precedence. This allows a base values file to be shared across environments while environment-specific tweaks are passed inline.

Step 5 — Dry-Run Rendering with helm template

helm template renders the Kubernetes YAML that Helm would apply, without sending anything to the cluster. This is invaluable for debugging and for GitOps pipelines that need plain manifests.

# Render manifests to stdout
helm template my-nginx bitnami/nginx -f custom-values.yaml

# Render and save to a file for review
helm template my-nginx bitnami/nginx -f custom-values.yaml > rendered.yaml

# Lint the chart for common errors
helm lint bitnami/nginx -f custom-values.yaml

Step 6 — Understanding Chart Anatomy

If you need to create or inspect a chart, use helm create to scaffold the standard directory layout.

helm create mychart
tree mychart/

# Key files:
# mychart/Chart.yaml         — chart metadata (name, version, appVersion)
# mychart/values.yaml        — default configurable values
# mychart/templates/         — Go-template Kubernetes manifests
# mychart/templates/NOTES.txt — post-install instructions printed to the user
# mychart/charts/            — sub-chart dependencies

# Package the chart into a .tgz for distribution
helm package mychart/

# Install directly from the local chart directory
helm install my-release ./mychart -f custom-values.yaml

The Chart.yaml file must include at minimum a name, version (SemVer), and apiVersion. The appVersion field is informational and typically tracks the version of the application the chart deploys, separate from the chart’s own version.

Conclusion

You have installed Helm on RHEL 8, added chart repositories, and deployed a real application through the full lifecycle of install, upgrade, rollback, and uninstall. You also explored value overrides and the helm template dry-run workflow, which is essential for maintaining reproducibility in CI/CD pipelines. Understanding chart anatomy gives you the foundation to build your own charts for internal applications.

Next steps: How to Set Up ArgoCD for GitOps on RHEL 8, How to Build a Jenkins CI/CD Pipeline on RHEL 8, and How to Install and Configure SonarQube on RHEL 8.