MeteorOps | DevOps Dictionary

Helm Chart

Helm Chart is a packaged set of Kubernetes resource definitions, templates, default values, and metadata used to install, configure, upgrade, and remove an application in a Kubernetes cluster. In practical terms, it gives you a repeatable way to deploy Kubernetes workloads without copying and editing raw YAML for every environment.

What a Helm Chart does

A Helm Chart describes what Kubernetes should run and how it should be configured. It can include resources such as Deployments, Services, ConfigMaps, Secrets, Ingress objects, ServiceAccounts, and custom resources.

Instead of maintaining separate static manifests for each environment, you define templates once and pass different values for development, staging, or production.

Install an application into a cluster
Set environment-specific configuration
Upgrade an application with a new image tag or resource setting
Roll back to a previous release when needed
Package related Kubernetes resources as one deployable unit

How Helm Charts work

Helm is the package manager commonly used with Kubernetes. A chart contains templates and values. When you run a Helm command, Helm renders the templates into standard Kubernetes YAML and applies them to the cluster through the Kubernetes API.

A typical install command looks like this:

helm install my-app ./my-chart -f values-prod.yaml

Helm creates a release, which is a specific installed instance of a chart. The same chart can be installed multiple times with different release names and values.

You can learn more about Helm if you want broader context on how it fits into Kubernetes delivery workflows.

Key files in a Helm Chart

Chart.yaml: Metadata for the chart, including name, version, description, and dependencies.
values.yaml: Default configuration values used by the templates.
templates/: Kubernetes manifest templates, usually written with Go template syntax.
charts/: Optional directory for dependent charts.
README.md: Documentation for chart users, common values, and install examples.

Common use cases

Application deployment: Package a web service, worker, API, or internal tool with its Kubernetes resources.
Environment configuration: Use one chart with separate values files, such as values-dev.yaml, values-staging.yaml, and values-prod.yaml.
Third-party software installation: Install tools such as ingress controllers, monitoring agents, certificate managers, or databases when a maintained chart is available.
Release management: Track deployed versions and roll back failed upgrades using Helm release history.
Platform standards: Create internal charts that enforce common labels, probes, resource limits, security contexts, and service configuration.

Benefits

Repeatability: Teams can deploy the same application structure consistently across clusters.
Configuration reuse: Templates reduce duplicated YAML while keeping environment-specific values separate.
Release tracking: Helm records installed releases and revisions.
Rollback support: You can revert to an earlier release revision if an upgrade fails.
Dependency management: Charts can declare dependencies on other charts.

Tradeoffs and limitations

Template complexity: Large charts can become hard to read when they contain many conditionals and nested values.
Rendered output matters: Kubernetes only sees the final YAML, so teams should inspect rendered manifests with helm template or use CI checks.
Secret handling needs care: Plain Helm values can expose sensitive data if stored in Git without encryption or a secrets workflow.
Chart upgrades can be risky: Changes to immutable Kubernetes fields, CRDs, or stateful workloads may require manual planning.
Not a full deployment system: Helm packages and applies manifests, but teams often pair it with GitOps tools, CI/CD pipelines, policy checks, and observability.

Simple example

A team runs a Node.js API on Kubernetes. They create a Helm Chart that includes a Deployment, Service, Ingress, ConfigMap, and HorizontalPodAutoscaler.

For staging, they set:

replicaCount: 2
image:
  tag: "1.8.0-rc1"
resources:
  requests:
    cpu: "250m"
    memory: "256Mi"

For production, they use the same chart with different values:

replicaCount: 6
image:
  tag: "1.8.0"
resources:
  requests:
    cpu: "500m"
    memory: "512Mi"

This keeps the deployment structure consistent while allowing each environment to use the right image tag, replica count, and resource settings.

Helm Chart vs Kubernetes manifest

A Kubernetes manifest is a YAML or JSON file that defines one or more Kubernetes resources directly. A Helm Chart is a package that can generate those manifests using templates and values.

Use raw manifests when the configuration is small and rarely changes.
Use a Helm Chart when you need reusable templates, environment-specific values, release history, or dependency management.

Helm Chart vs Helm release

A chart is the package. A release is an installed instance of that package in a Kubernetes cluster.

For example, you might install the same web-api chart twice:

web-api-staging in the staging namespace
web-api-prod in the production namespace

Both releases can use the same chart but different values.

DevOps Dictionary