GitOps: Episode Five — Managing Apps with Helm Charts

As we advance on our GitOps journey, it’s time to introduce one of the most powerful tools for Kubernetes deployments: Helm charts.

In this post, we’ll explore what Helm charts are, why they’re useful in a GitOps workflow, and how you can manage Helm-based applications with FluxCD — keeping everything declarative and Git-driven.

Let’s build on everything we’ve learned so far.

1. What Are Helm Charts, and Why Use Them with GitOps?

At its core, Helm is a package manager for Kubernetes.

Instead of manually writing multiple YAML files for a complex application — deployments, services, ingresses, config maps — you can use a Helm chart to bundle them all together in a reusable, customizable package.

Think of a Helm chart like a recipe:

• It defines what you need to deploy
• It allows you to customize how it’s deployed using values files without editing the core templates

This fits naturally into GitOps because:

• You can store your Helm releases (and their values) in Git
• FluxCD knows how to pull and apply Helm charts automatically
• Upgrading an app becomes as simple as updating a Git commit

In short: Helm simplifies app management, and GitOps simplifies app delivery. Together, they’re a powerful combo.

2. Installing a Helm Controller with FluxCD

Flux uses a component called the Helm Controller to manage Helm charts declaratively.

If you installed FluxCD recently with bootstrapping commands, the Helm Controller may already be present.

You can check if it’s running:

kubectl get pods -n flux-system

Look for a pod like helm-controller-xxxxx.

If it’s missing, you can add the Helm Controller manually by enabling it through Flux installation or applying its manifest.

Once the Helm Controller is active, your cluster is ready to manage Helm releases through Git.

3. Deploying a Helm Chart with FluxCD

Let’s go through the basic flow of managing an application using a Helm chart.

First, we define a HelmRepository — this tells Flux where to find the chart we want.

Example: setting up Bitnami’s NGINX chart repository.

apiVersion: source.toolkit.fluxcd.io/v1
kind: HelmRepository
metadata:
  name: bitnami
  namespace: flux-system
spec:
  interval: 10m
  url: https://charts.bitnami.com/bitnami

This tells Flux to regularly pull Helm charts from Bitnami’s public repository.

Next, we define a HelmRelease — this tells Flux what chart to install, what version to use, and what custom values to apply.

apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
  name: my-nginx
  namespace: default
spec:
  interval: 5m
  chart:
    spec:
      chart: nginx
      sourceRef:
        kind: HelmRepository
        name: bitnami
      version: "13.2.19"
  values:
    service:
      type: LoadBalancer

This example will deploy the Bitnami nginx chart into your cluster, customized to use a LoadBalancer service.

Both the HelmRepository and HelmRelease files should live in your Git repo (for example under clusters/dev/apps/ if you’re using a multi-environment setup).

Once you push these files to Git, Flux automatically detects the change and deploys the app into your cluster!

4. Advantages of Helm + GitOps Together

Using Helm with GitOps offers several major benefits:

• Reusability: You don’t need to rewrite YAML for every deployment. Charts can be reused across projects and environments.
• Version Control: Upgrading an app is as simple as updating the chart version inside your Git repo and pushing the change.
• Consistency: Helm charts ensure that applications are deployed the same way every time.
• Customization: Each environment (dev, staging, prod) can have its own customized values, while still relying on the same chart.

By combining Helm’s flexibility with GitOps automation, you create highly maintainable, scalable deployment workflows.

5. What’s Next

Now that you know how to integrate Helm charts into GitOps with FluxCD, you’re ready for even bigger steps.

In the next post, we’ll dive into automating image updates using GitOps — setting up automation so that new container versions can trigger Git commits and automatic deployments.

This takes GitOps from being just about applying YAML to becoming a true continuous delivery powerhouse.

Stay tuned — you’re building real production-grade GitOps skills now!

Previous Posts in the Series

• Episode Zero — Why You Should Care and What to Expect
• Episode One — GitOps vs. Traditional CI/CD
• Episode Two — Setting Up a GitOps-Ready Kubernetes Cluster
• Episode Three — Deploying Your First App with GitOps
• Episode Four — Managing Multi-Environment Deployments with GitOps

Want to keep leveling up your GitOps skills? Subscribe to get future posts, tutorials, and hands-on guides delivered straight to your inbox!