ArgoCD Overview Applications Sync Policies and Helm Integration

Get hands-on with Argo CD’s most important resources. By the end of this lesson you’ll be able to:

Define an Argo CD Application that maps Git or Helm sources to a target cluster and namespace.
Configure sync policies to enable true GitOps automation (auto-sync, self-heal, prune).
Deploy Helm charts through Argo CD (server-side rendering, values overrides).
Scale application provisioning using ApplicationSets and generators.

A slide titled "Learning Objectives" with a blue gradient panel on the left. On the right are four numbered points about ArgoCD: creating Application resources, configuring sync policies (automated, selfHeal, prune), deploying Helm charts through ArgoCD, and using ApplicationSets to generate applications at scale.

Why enable automation? A short story A logistics platform team had Argo CD installed but kept auto-sync disabled. Their process:

Developer pushes a change to Git.
Argo CD marks the Application OutOfSync.
A platform engineer must manually open the UI and click Sync to deploy.

A three-step flow diagram titled "Manual Sync and Drift" showing: developer pushes changes to Git, Argo CD detects the change and marks the app "Out of Sync" (with an Argo CD octopus icon), and the platform team manually clicks a "Sync" button to reconcile.

One Friday a developer pushed a critical hotfix. Argo CD detected the change and flagged the application as OutOfSync, but because auto-sync was disabled and the platform team had gone home, the hotfix was not deployed until Monday. That weekend the service charged customers incorrectly — a real cost of manual steps in an automation-first workflow. Common problems with manual sync

Deployment bottleneck: someone must click Sync, delaying urgent fixes.
Drift accumulates: manual kubectl edits persist until reconciled.
Orphaned resources: deleted manifests in Git are not removed automatically from clusters.
Inconsistency: mixed auto/manual sync leads to unpredictable environments.

A slide titled "Manual Sync and Drift" that lists four problems on a timeline: Deployment bottleneck, Drift accumulates, Orphaned resources, and Inconsistent states. Each item has a short explanation about manual sync issues (someone must click sync, kubectl changes persist, deleted resources still running, and mixed auto-sync behavior).

Application CRD — the core concept The Application CRD is Argo CD’s primary resource: it bridges a source (where manifests or Helm charts live) to a destination (which cluster and namespace to deploy to). Applications are organized into Projects for RBAC and policy boundaries. Key fields:

source: for Git-based apps this includes repoURL, targetRevision (branch/tag/commit), and path. For Helm charts it uses repoURL + chart (or an OCI registry + chart).
destination: server (cluster API URL) and namespace.
project: logical grouping to apply policies and RBAC.
spec.syncPolicy: controls automation behavior.

Minimal Git-backed Application example

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/example-org/myapp-configs.git
    targetRevision: HEAD
    path: overlays/prod
  destination:
    server: https://kubernetes.default.svc
    namespace: myapp
  # syncPolicy is optional — configure it to automate reconciliation and manage drift

Sync policies — enable true GitOps automation Three flags matter for production-grade automation:

automated: apply changes automatically when Git changes are detected.
selfHeal: revert manual cluster drift back to the Git-defined state.
prune: delete resources that were removed from Git.

Table — sync policy flags and behavior

Flag	What it does	Typical production setting
`automated`	Automatically apply changes on Git updates	`enabled`
`selfHeal`	Reconcile manual/cluster drift back to Git desired state	`enabled`
`prune`	Remove resources that no longer exist in Git	`enabled`

Recommended production sync policy

spec:
  syncPolicy:
    automated: {}
    prune: true
    selfHeal: true

Enable automated with selfHeal: true and prune: true in production to achieve true GitOps: automatic reconciliation, removal of resources deleted from Git, and automatic correction of manual drift.

Helm integration — server-side rendering and overrides Argo CD can render Helm charts server-side, so you do not need to run helm install from CI or developer workstations. For Helm-based Applications the source block points to a chart repository (or an OCI chart), and you can supply values through:

helm.values: inline YAML string for small or simple overrides.
helm.valueFiles: reference value files stored in a Git repo for more complex, version-controlled overrides.

Example Helm Application with inline values

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:
      values: |
        replicaCount: 3
        image:
          tag: "2.1.0"
      # valueFiles:
      #   - values-prod.yaml
  destination:
    server: https://kubernetes.default.svc
    namespace: my-helm-app
  syncPolicy:
    automated: {}
    prune: true
    selfHeal: true

When to use helm.values vs helm.valueFiles:

Use helm.values for one-off, small overrides (e.g., bump replicas).
Use helm.valueFiles for larger configuration sets or when you want overrides tracked as files in Git.

Scaling Applications with ApplicationSets ApplicationSets generate Argo CD Application resources at scale by combining a generator with a template. When the generator yields entries, the ApplicationSet controller renders the template and creates an Application for each entry. Common generators:

Generator	Use case
`list`	Static set of entries (useful for a small fixed set like `dev`/`prod`)
`git`	One Application per directory in a Git repo (create a new directory to add an app)
`cluster`	One Application per registered cluster (deploy same app across all clusters)
`matrix` / `merge`	Combine multiple generators (e.g., every app × every cluster)

A presentation slide titled "ApplicationSets" showing a template to generate multiple applications with four numbered generator cards: List, Git Directory, Cluster, and Matrix/Merge, each with a short description. A use-case note at the bottom mentions deploying the same app to multiple clusters.

Example ApplicationSet (list generator for dev and prod)

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/example-org/myapp-configs.git
        targetRevision: HEAD
        path: overlays/{{cluster}}
      destination:
        server: '{{url}}'
        namespace: '{{namespace}}'
      syncPolicy:
        automated: {}
        prune: true
        selfHeal: true

Note: metadata.name in the template uses placeholders such as myapp-{{cluster}} which will render to myapp-dev and myapp-prod for each generator element. Recap — what to remember

The Application CRD maps a source (Git or Helm) to a destination (cluster + namespace) and belongs to a Project for policy boundaries.
For reproducible GitOps automation, enable automated together with selfHeal: true and prune: true.
Use Argo CD’s server-side Helm rendering. Prefer helm.values for small inline overrides and helm.valueFiles for larger, version-controlled overrides.
Use ApplicationSets + generators to create many Applications programmatically (multi-environment or multi-cluster deployments).
Mastering the Application spec, syncPolicy, and Helm settings enables reliable Argo CD operations and helps answer exam or interview questions about GitOps workflows.

Links and references

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