Disclosure: Some links in this article are affiliate links. We may earn a small commission at no extra cost to you.

ArgoCD with Helm Charts: The Complete Guide (2026)

Helm is the package manager for Kubernetes, and ArgoCD has first-class Helm support. This guide covers deploying Helm charts with ArgoCD — from basic usage to advanced patterns like values file overrides, multiple environments, and chart repositories.

Why Helm + ArgoCD?

Helm packages your application into reusable charts with templated values
ArgoCD deploys those charts via GitOps — every change tracked in Git
Together, you get repeatable, auditable deployments across environments

Method 1: Helm Chart from a Git Repository

Store your Helm chart in Git alongside your application code:

my-app-repo/
├── src/
├── Dockerfile
└── charts/
    └── my-app/
        ├── Chart.yaml
        ├── values.yaml
        └── templates/
            ├── deployment.yaml
            ├── service.yaml
            └── ingress.yaml

ArgoCD Application:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
  namespace: argocd
spec:
  source:
    repoURL: https://github.com/yourorg/my-app.git
    targetRevision: main
    path: charts/my-app
    helm:
      valueFiles:
        - values.yaml
        - values-production.yaml
  destination:
    server: https://kubernetes.default.svc
    namespace: production

Method 2: Helm Chart from a Chart Repository

Deploy community or private Helm charts directly:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: prometheus
  namespace: argocd
spec:
  source:
    repoURL: https://prometheus-community.github.io/helm-charts
    chart: kube-prometheus-stack
    targetRevision: 56.6.2
    helm:
      releaseName: monitoring
      values: |
        grafana:
          enabled: true
          adminPassword: changeme
        prometheus:
          prometheusSpec:
            retention: 30d
            storageSpec:
              volumeClaimTemplate:
                spec:
                  storageClassName: do-block-storage
                  resources:
                    requests:
                      storage: 50Gi
  destination:
    server: https://kubernetes.default.svc
    namespace: monitoring

Multi-Environment with Helm Values

The most common pattern: one chart, different values per environment.

k8s-manifests/
├── base/
│   └── my-app/
│       ├── Chart.yaml
│       ├── values.yaml          # Defaults
│       └── templates/
├── environments/
│   ├── staging/
│   │   └── values.yaml          # Staging overrides
│   └── production/
│       └── values.yaml          # Production overrides

Staging Application:

spec:
  source:
    path: base/my-app
    helm:
      valueFiles:
        - ../../environments/staging/values.yaml

Production Application:

spec:
  source:
    path: base/my-app
    helm:
      valueFiles:
        - ../../environments/production/values.yaml

Helm Parameters via ArgoCD

Override individual values without changing files:

spec:
  source:
    helm:
      parameters:
        - name: image.tag
          value: "v2.1.0"
        - name: replicas
          value: "3"
        - name: ingress.enabled
          value: "true"

Or via CLI:

argocd app set my-app -p image.tag=v2.1.0 -p replicas=3

Private Helm Repositories

# Add a private Helm repo
argocd repo add https://charts.example.com \
  --type helm \
  --name my-charts \
  --username admin \
  --password secret

# OCI registry (Helm 3.8+)
argocd repo add oci://registry.example.com/charts \
  --type helm \
  --enable-oci \
  --username admin \
  --password secret

Common Pitfalls

Values file paths are relative to the chart directory — use ../../ carefully
Chart version pinning — always pin targetRevision in production
Helm hooks — ArgoCD handles most hooks but pre-install can behave differently
CRDs — use skipCrds: true and manage CRDs separately for safety
Secret management — never store secrets in values files; use Sealed Secrets or External Secrets Operator

Let's Talk DevOps