Helm Overview In Argocd

In the previous section, we completed our exploration of application sources, covering directories of manifests, Kustomize layouts, Jsonnet structures, and multi-source configurations. With those deployment formats clear, we will now start Module 5: Helm with ArgoCD, beginning with Helm Integration Overview.

Helm is the standard package manager for Kubernetes. However, the way ArgoCD manages Helm charts differs from traditional command-line workflows. Instead of running helm install or helm upgrade commands inside your cluster, ArgoCD uses a declarative, compilation-based model.

In this guide, we will cover the internal architecture of Helm compilation, analyze why ArgoCD does not use standard Helm releases, and review the benefits of this design.

1. How ArgoCD Integrates with Helm

When you deploy a Helm chart using ArgoCD, the argocd-repo-server pod handles the processing. Instead of connecting to the cluster and executing Helm installation scripts, the repo-server compiles the templates locally:

               Helm Compilation Lifecycle
┌────────────────────────────────────────────────────────┐
│  Phase 1: Fetch Chart                                  │
│  - Downloads the Helm chart from registry to cache     │
├────────────────────────────────────────────────────────┤
│  Phase 2: Render Templates                             │
│  - Executes: helm template <release-name> <chart>     │
│    passing value overrides and configuration maps.      │
├────────────────────────────────────────────────────────┤
│  Phase 3: Apply Manifests                              │
│  - Returns raw YAML payloads to Application Controller  │
│  - Controller applies resources via Kubernetes API     │
└────────────────────────────────────────────────────────┘

The Application Controller receives only raw Kubernetes manifests. It does not know that the resources were originally packaged as a Helm chart.

2. Why ArgoCD Does Not Create standard Helm Releases

If you run helm list inside your cluster namespaces after deploying a chart with ArgoCD, you will notice that the list is empty.

The Reasons Behind This Design:

• No Helm Secret Storage: Traditional Helm installations store release state metadata as secrets inside the target namespace. ArgoCD manages state tracking inside its own database and Redis cache, removing the need for Helm storage secrets.
• Declarative Drift Detection: Standard Helm only checks resources during install/upgrade commands. Because ArgoCD applies raw manifests, the controller loop tracks resource health and drift continuously, enforcing consistency.
• Unified UI Visualizations: By rendering charts to raw YAML, ArgoCD can display resource dependency trees in the dashboard, regardless of whether the resources are defined in plain YAML, Helm, or Kustomize.

3. Operational Best Practices: Helm Architecture

• Scale Repo Server: Helm template compilation is CPU-intensive. Increase the replica count of the argocd-repo-server deployment if you deploy many Helm charts.
• Configure caching: Verify that Redis caching is active to prevent the repo-server from downloading and compiling charts on every single reconciliation loop check.
• Avoid Tiller/Legacy Helm: Ensure your charts comply with Helm v3 standards, which remove server-side dependencies.

4. Helm Integration Reference Summary

Now that we have covered the architectural design of ArgoCD's Helm integration, the next step is deploying charts. In the next section, we will cover how to configure and deploy Helm charts.