Deploy Helm Charts with ArgoCD (2026)

ArgoCD doesn’t just deploy Helm charts; it manages them as a GitOps-native, declarative application delivery system.

Let’s see ArgoCD in action managing a Helm chart. Imagine you have a simple Nginx deployment defined in a Helm chart.

First, you’ll need a Helm chart. Here’s a basic Chart.yaml:

apiVersion: v2
name: nginx-basic
version: 0.1.0
appVersion: 1.16.0

And templates/deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:

  name: {{ include "nginx-basic.fullname" . }}

  labels:

    app.kubernetes.io/name: {{ include "nginx-basic.name" . }}


    helm.sh/chart: {{ include "nginx-basic.chart" . }}


    app.kubernetes.io/instance: {{ .Release.Name }}


    app.kubernetes.io/managed-by: {{ .Release.Service }}

spec:

  replicas: {{ .Values.replicaCount }}

  selector:
    matchLabels:

      app.kubernetes.io/name: {{ include "nginx-basic.name" . }}


      app.kubernetes.io/instance: {{ .Release.Name }}

  template:
    metadata:
      labels:

        app.kubernetes.io/name: {{ include "nginx-basic.name" . }}


        app.kubernetes.io/instance: {{ .Release.Name }}

    spec:
      containers:
        - name: nginx

          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"


          imagePullPolicy: {{ .Values.image.pullPolicy }}

          ports:
            - name: http
              containerPort: 80
              protocol: TCP

And values.yaml:

replicaCount: 1

image:
  repository: nginx
  pullPolicy: IfNotPresent
  tag: "1.16.0"

Now, you’ll commit this chart to a Git repository. Let’s say it’s at https://github.com/your-username/my-helm-charts.git in the nginx-basic directory.

Next, you configure ArgoCD. You create an ArgoCD Application resource. This tells ArgoCD what to deploy and where.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: nginx-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/your-username/my-helm-charts.git
    targetRevision: HEAD
    path: nginx-basic # This is the directory containing your Chart.yaml
    helm:
      valueFiles:
      - values.yaml # You can specify multiple value files
  destination:
    server: https://kubernetes.default.svc
    namespace: default # The Kubernetes namespace to deploy into
  syncPolicy:
    automated: # Optional: enable automated sync
      prune: true
      selfHeal: true

When you apply this Application manifest to your Kubernetes cluster where ArgoCD is running, ArgoCD will:

1. Detect the change: It sees a new Application resource.
2. Fetch the source: It clones your Git repository and navigates to the nginx-basic path.
3. Render the Helm chart: It uses Helm to render the templates in that directory, applying the values.yaml.
4. Compare with desired state: It compares the rendered Kubernetes manifests with the actual state in the default namespace of your cluster.
5. Apply changes: If there’s a difference, it applies the necessary Kubernetes API calls to create, update, or delete resources to match the rendered state.

In this case, it would create a Deployment named nginx-basic-nginx-basic (based on Helm’s naming conventions) with 1 replica, using the nginx:1.16.0 image.

The real power here is that ArgoCD continuously monitors both your Git repository and your live Kubernetes cluster. If you update values.yaml in Git (e.g., change replicaCount to 3), ArgoCD will automatically detect this drift and update your deployment to match the new desired state. It’s not just a one-time deployment; it’s ongoing synchronization.

ArgoCD treats Helm charts as just another form of declarative configuration, like raw Kubernetes YAML. The source block in the Application manifest is where you specify how to obtain and process this configuration. For Helm, you point to the Git repository, the path to the chart, and optionally list valueFiles or provide inline values.

What most users don’t realize is that ArgoCD can also take over the Helm release management itself. Instead of ArgoCD just rendering your chart and applying the resulting YAML, you can tell ArgoCD to use Helm’s native install and upgrade commands under the hood. This is done by adding helm.releaseName to the source block:

  source:
    repoURL: https://github.com/your-username/my-helm-charts.git
    targetRevision: HEAD
    path: nginx-basic
    helm:
      valueFiles:
      - values.yaml
      releaseName: my-nginx-release # <-- This tells ArgoCD to manage this as a Helm Release

When releaseName is specified, ArgoCD will use helm install my-nginx-release ... or helm upgrade my-nginx-release ... on the first sync and subsequent syncs. This means the Helm release metadata will be stored in Kubernetes (typically as a Secret or ConfigMap in the target namespace, depending on your Helm version and configuration), and ArgoCD will manage the lifecycle of that Helm release object. This is crucial if your chart includes NOTES.txt that you want to see or if you need to leverage Helm’s built-in hooks.

The next logical step is exploring how to manage Helm chart dependencies with ArgoCD.