ArgoCD Overview Applications Sync Policies and Helm Integration

In this lesson you’ll get hands-on with Argo CD’s core resources and patterns for production-grade GitOps. We’ll cover how to:

Define an Argo CD Application CRD that maps Git/Helm sources to target clusters.
Configure sync policies for automated GitOps (auto-sync, self-heal, prune).
Deploy Helm charts through Argo CD and manage Helm value overrides.
Use ApplicationSets to scale many Applications across clusters and environments.

The image lists four learning objectives related to ArgoCD, including creating application resources, configuring sync policies, deploying Helm charts, and using ApplicationSets for scaling.

Why automation matters — a short story A logistics platform team had Argo CD installed but left auto-sync disabled. The workflow became:

Developer pushes a change to Git.
Argo CD detects the change and marks the Application “Out of Sync”.
A platform engineer must manually open the Argo CD UI and click Sync to deploy.

The image illustrates a manual sync process with three steps: a developer pushes changes to Git, ArgoCD detects the change and marks the app as "Out of Sync," and the platform team manually clicks "Sync."

When a critical hotfix was pushed late on Friday, the change remained undeployed until Monday because the platform team was off-site and auto-sync was disabled. The cluster drifted from Git and caused real business impact.

The image illustrates a workflow labeled "Manual Sync and Drift," where a developer applies a critical hotfix to address a bug, while Argo CD detects that the system is "Out of Sync."

Manual sync creates operational risk

Hotfixes and deployments are delayed by manual steps.
Manual kubectl edits introduce drift until reconciled.
Resources removed from Git are not pruned and can become orphaned.
Mixed sync modes cause inconsistent environment behavior.

The image is an infographic titled "Manual Sync and Drift," illustrating potential issues in a system: deployment bottleneck, drift accumulation, orphaned resources, and inconsistent states.

Application CRD — the core resource An Argo CD Application CRD bridges two ends:

Source: where manifests originate (Git repo path/revision or Helm chart + repo/OCI).
Destination: where manifests are deployed (cluster server/cluster name and namespace).

Applications are grouped into Projects for RBAC, quota, and tenant isolation (e.g., restrict which namespaces a team can deploy to). A minimal Application manifest:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/org/repo
    targetRevision: main
    path: apps/my-app
  destination:
    server: https://kubernetes.default.svc
    namespace: my-app
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Quick reference: core Application spec fields

Field	Purpose	Example
`spec.source`	Where to fetch manifests (Git path or Helm chart).	`repoURL: https://github.com/org/repo`
`spec.destination`	Target cluster and namespace for deployment.	`server: https://kubernetes.default.svc`
`spec.project`	Project for grouping and RBAC isolation.	`project: default`
`spec.syncPolicy`	Controls automation: automated, selfHeal, prune.	See table below

Sync policies — automation for true GitOps Argo CD supports automation options you should enable in production. The main options:

Option	Behavior	When to enable
`automated`	Apply changes from Git automatically (no UI click).	Enable for continuous delivery.
`selfHeal`	Continuously reconcile cluster to match Git (revert manual edits).	Enable to prevent configuration drift.
`prune`	Delete resources removed from Git to avoid orphaned resources.	Enable to keep cluster state clean.

Example concise snippet to enable production-grade automation:

spec:
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Enable automated with selfHeal: true and prune: true in production to ensure Git changes are applied automatically, manual edits are reverted, and removed resources are pruned.

Helm integration — server-side rendering and overrides Argo CD renders Helm charts server-side — you do not need a Helm client inside the cluster. For Helm-based Applications, the source includes chart and repoURL (or an OCI reference). Argo CD caches the rendered manifests for diffs and drift detection, but it does not commit rendered manifests back to Git. Two primary ways to supply Helm values:

helm.values — inline YAML embedded directly in the Application (good for small overrides).
helm.valueFiles — reference files inside the repo (preferred for many or environment-specific overrides).

Example Helm-based Application with both approaches:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-helm-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://charts.example.com
    chart: mychart
    targetRevision: 1.2.3
    helm:
      valueFiles:
        - values-prod.yaml
      values: |
        replicaCount: 3
        image:
          tag: "1.2.3"
  destination:
    server: https://kubernetes.default.svc
    namespace: my-helm-app
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Key Helm tips

Use helm.valueFiles to keep overrides versioned and environment-specific.
Use helm.values for small, quick overrides (but prefer files for consistency).
Argo CD’s server-side rendering supports chart dependencies, templating, and helpers as a local Helm client would.

The image outlines Helm integration options for ArgoCD, detailing four key components: chart + repoURL, releaseName, values (inline), and valueFiles. It highlights ArgoCD's ability to render Helm charts server-side without Tiller, storing outputs in Git for drift detection.

ApplicationSets — scale Application management Managing dozens or hundreds of Application manifests by hand is error-prone. ApplicationSets generate many Application CRs from a single template using a generator. Common generators:

list — static list of elements (good for a small, fixed set).
git — one application per directory found in a Git repo (add a directory to create a new Application).
cluster — one application per registered cluster (register a cluster to deploy to it).
matrix/merge — combine generators (e.g., app × cluster combinations).

Example: deploy the same app to dev and prod using a list generator. The template uses placeholders like myapp-{{cluster}} to stamp unique Application names per element.

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: myapp
  namespace: argocd
spec:
  generators:
    - list:
        elements:
          - cluster: dev
            url: https://kubernetes.default.svc
            namespace: myapp-dev
          - cluster: prod
            url: https://prod.example.com
            namespace: myapp-prod
  template:
    metadata:
      name: "myapp-{{cluster}}"
    spec:
      project: default
      source:
        repoURL: https://github.com/org/repo
        targetRevision: main
        path: apps/my-app
      destination:
        server: "{{url}}"
        namespace: "{{namespace}}"
      syncPolicy:
        automated:
          prune: true
          selfHeal: true

The image describes "ApplicationSets," a template to generate multiple applications, with four common generators: List, Git Directory, Cluster, and Matrix/Merge. Each generator is briefly explained under its label.

Add a third cluster (by adding another element to the list or registering another cluster), and the ApplicationSet will automatically create a third Application—no manifest duplication required. Recap — four key takeaways

Application CRDs map a source (Git or Helm chart) to a destination (cluster/namespace) and are grouped into Projects for RBAC.
For production GitOps, enable automated plus selfHeal and prune to apply Git changes automatically, revert manual edits, and remove orphaned resources.
Argo CD renders Helm charts server-side. Use helm.values for small inline overrides and helm.valueFiles for versioned environment overrides.
ApplicationSets let you scale Application creation using generators (list, git, cluster, matrix), avoiding manual duplication.

Course Introduction

Platform Architecture and Infrastructure

GitOps and Continuous Delivery

Platform APIs and Self-Service Capabilities

Observability and Operations

Security and Policy Enforcement

Conclusion

ArgoCD Overview Applications Sync Policies and Helm Integration

Watch Video