• TechOps Examples
  • Posts
  • How to Use Helm to Deploy a Kubernetes Application to Multiple Environments

How to Use Helm to Deploy a Kubernetes Application to Multiple Environments

Author

Govardhana M K
September 18, 2025

In partnership with

TechOps Examples

Hey — It's Govardhana MK 👋

Welcome to another technical edition.

Every Tuesday – You’ll receive a free edition with a byte-size use case, remote job opportunities, top news, tools, and articles.

Every Thursday and Saturday – You’ll receive a special edition with a deep dive use case, remote job opportunities, and articles.

👋 Before we begin... a big thank you to today's sponsor GUIDDE

Create How-to Videos in Seconds with AI

Stop wasting time on repetitive explanations. Guidde’s AI creates stunning video guides in seconds—11x faster.

  • Turn boring docs into visual masterpieces

  • Save hours with AI-powered automation

  • Share or embed your guide anywhere

How it works: Click capture on the browser extension, and Guidde auto-generates step-by-step video guides with visuals, voiceover, and a call to action.

👀 Remote Jobs

📚️ Resources

🔴 Get my DevOps & Kubernetes ebooks! (free for Premium Club and Personal Tier newsletter subscribers)

Looking to promote your company, product, service, or event to 52,000+ Cloud Native Professionals? Let's work together. Advertise With Us

🧠 DEEP DIVE USE CASE

How to Use Helm to Deploy a Kubernetes Application to Multiple Environments

Managing Kubernetes applications with plain YAML files works only until you add more environments. Each one needs its own configuration, and copying YAML files for production, staging, and dev quickly becomes repetitive and error prone.

Helm solves this by packaging manifests into a reusable chart and letting you inject environment specific values through separate files. This way you maintain a single chart and deploy consistently across environments.

Helm Architecture

Helm’s architecture is built around a few moving parts that together replace ad hoc YAML management with a clean, layered system:

  • Helm CLI (Client layer): The entry point where operators run helm install, helm upgrade, or helm rollback. It talks directly to the cluster’s API server.

  • Charts (Packaging layer): Versioned bundles that hold templates, default values, and metadata. These capture how an app should run, not just static manifests.

  • Chart Repositories (Distribution layer): Centralized storage and discovery for charts. Think of it like a package registry for Kubernetes apps.

  • Templating Engine (Rendering layer): The piece that merges chart templates with the supplied values.yaml to generate manifests tailored to an environment.

  • Kubernetes API (Execution layer): The endpoint where Helm pushes the rendered manifests for actual deployment on the cluster.

Helm Structure BreakDown

A Helm chart is a package of files that define how an application runs on Kubernetes. It brings structure and reusability.

  • Chart.yaml → Metadata about the app (name, version, dependencies).

  • values.yaml → Default configuration values that can be overridden per environment. You can also add a schema for validation.

  • templates/ → Kubernetes resource templates (e.g., deployment, service, PVC) that get rendered with values.

  • Special Case specific values → Separate files like values-eks.yaml or values-gke.yaml let you adapt the same chart for different cloud providers or clusters without duplicating templates.

Every time you install a chart, Helm creates a release (a versioned instance of your app). This makes upgrades, rollbacks, and multi environment deployments predictable and consistent.

With this basic understanding, let us look at how a CI/CD pipeline for Helm works in most production systems.

I am giving away 25% OFF on all annual plans of membership offerings.

A membership will unlock access to read these deep dive editions on Thursdays and Saturdays.

Get greater value at a fractional price

Upgrade to Paid to read the rest.

Become a paying subscriber to get access to this post and other subscriber-only content.

Already a paying subscriber? Sign In.

Paid subscriptions get you:

  • • Access to archive of 200+ use cases
  • • Deep Dive use case editions (Thursdays and Saturdays)
  • • Access to Private Discord Community
  • • Invitations to monthly Zoom calls for use case discussions and industry leaders meetups
  • • Quarterly 1:1 'Ask Me Anything' power session