> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.

# ArgoCD Overview Applications Sync Policies and Helm Integration

> Guide to Argo CD Applications, sync policies for GitOps automation, Helm chart deployment, and using ApplicationSets to scale application provisioning across clusters and environments

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.](https://mintcdn.com/kodekloud-c4ac6d9a/8pYzlc1aD6cgTw8b/images/Prep-Course-Certified-Cloud-Native-Platform-Engineering-CNPE/GitOps-and-Continuous-Delivery/ArgoCD-Overview-Applications-Sync-Policies-and-Helm-Integration/argocd-learning-objectives-sync-helm-applicationsets.jpg?fit=max\&auto=format\&n=8pYzlc1aD6cgTw8b\&q=85\&s=f6edb586ba103cea6c9400228ba89de3)

Why enable automation? A short story

A logistics platform team had Argo CD installed but kept auto-sync disabled. Their process:

1. Developer pushes a change to Git.
2. Argo CD marks the Application OutOfSync.
3. 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.](https://mintcdn.com/kodekloud-c4ac6d9a/8pYzlc1aD6cgTw8b/images/Prep-Course-Certified-Cloud-Native-Platform-Engineering-CNPE/GitOps-and-Continuous-Delivery/ArgoCD-Overview-Applications-Sync-Policies-and-Helm-Integration/manual-sync-drift-argocd-git-push.jpg?fit=max\&auto=format\&n=8pYzlc1aD6cgTw8b\&q=85\&s=075bfbedcd53cac6101f7ea3ade34587)

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).](https://mintcdn.com/kodekloud-c4ac6d9a/8pYzlc1aD6cgTw8b/images/Prep-Course-Certified-Cloud-Native-Platform-Engineering-CNPE/GitOps-and-Continuous-Delivery/ArgoCD-Overview-Applications-Sync-Policies-and-Helm-Integration/manual-sync-drift-deployment-orphaned-states.jpg?fit=max\&auto=format\&n=8pYzlc1aD6cgTw8b\&q=85\&s=e757de22455ec35edee5b61dbc80c265)

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

```yaml theme={null}
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

```yaml theme={null}
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

```yaml theme={null}
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.](https://mintcdn.com/kodekloud-c4ac6d9a/8pYzlc1aD6cgTw8b/images/Prep-Course-Certified-Cloud-Native-Platform-Engineering-CNPE/GitOps-and-Continuous-Delivery/ArgoCD-Overview-Applications-Sync-Policies-and-Helm-Integration/applicationsets-generators-list-git-cluster-matrix.jpg?fit=max\&auto=format\&n=8pYzlc1aD6cgTw8b\&q=85\&s=5387648d8fb89ca192d0c1aa5b68d1fc)

Example ApplicationSet (list generator for `dev` and `prod`)

```yaml theme={null}
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

* [Argo CD Documentation](https://argo-cd.readthedocs.io/)
* [ArgoCD Application CRD reference](https://argo-cd.readthedocs.io/en/stable/operator-manual/declarative-setup/#application)
* [ApplicationSet Controller](https://argocd-applicationset.readthedocs.io/)
* [Helm Charts Best Practices](https://helm.sh/docs/chart_best_practices/)

> **[Watch Video](https://learn.kodekloud.com/user/courses/prep-course-certified-cloud-native-platform-engineer-cnpe/module/dff5382b-dbe7-4cac-bd2b-d5a47028945e/lesson/1598b9d8-b455-4f9c-8656-583a06cf8a39)**


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.