ArgoCD Applications

Managing Application manifests, sync policies, health checks, waves, hooks, and app-of-apps.

8 min readCI/CD & GitOpsPlatform

ArgoCD Overview

ArgoCD is a GitOps continuous delivery controller for Kubernetes. It monitors Git repositories for changes and automatically synchronizes the desired state to the cluster. If the cluster state drifts from the repository state, ArgoCD detects and corrects it.

ArgoCD supports Helm, Kustomize, Jsonnet, and plain YAML manifests. It provides a web UI for visualization, a CLI for automation, and a REST API for integration. It is the most popular GitOps controller for Kubernetes.

Application Manifest

ArgoCD Application


apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp
  namespace: argocd
  annotations:
    argocd.argoproj.io/sync-wave: "1"
spec:
  project: default
  source:
    repoURL: https://github.com/myorg/gitops-repo.git
    targetRevision: main
    path: applications/myapp/overlays/production
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
      allowEmpty: false
    syncOptions:
      - CreateNamespace=true
      - PrunePropagationPolicy=foreground
      - PruneLast=true
    retry:
      limit: 5
      backoff:
        duration: 5s
        factor: 2
        maxDuration: 3m
  ignoreDifferences:
    - group: apps
      kind: Deployment
      jsonPointers:
        - /spec/replicas

The Application resource tells ArgoCD where to find the manifests (source) and where to deploy them (destination). Automated sync with selfHeal corrects manual changes. The retry policy handles transient failures.

Sync Policies

Policy	Behavior	Use Case
automated + selfHeal	Auto-sync and correct drift	Production with confidence
automated without selfHeal	Auto-sync on Git changes only	Staging environments
manual	Require manual sync trigger	Critical production systems
automated + prune	Auto-delete removed resources	Dynamic environments

Health Checks

Custom health check for CRDs


apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp
spec:
  syncPolicy:
    syncOptions:
      - RespectIgnoreDifferences=true
  ignoreDifferences:
    - group: flagger.app
      kind: Canary
      jsonPointers:
        - /status

---
# Custom health check Lua script
apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-cm
  namespace: argocd
data:
  resource.customizations.health.flagger.app_Canary: |
    hs = {}
    hs.status = "Progressing"
    hs.message = "Canary is progressing"
    if obj.status ~= nil then
      if obj.status.phase == "Succeeded" then
        hs.status = "Healthy"
        hs.message = "Canary promotion succeeded"
      elseif obj.status.phase == "Failed" then
        hs.status = "Degraded"
        hs.message = "Canary analysis failed"
      end
    end
    return hs

ArgoCD uses health checks to determine if resources are healthy. Custom health checks handle CRDs like Flagger Canary. The Lua script maps CRD status phases to ArgoCD health statuses.

Sync Waves

Sync wave ordering


# Wave -1: Namespace
apiVersion: v1
kind: Namespace
metadata:
  name: production
  annotations:
    argocd.argoproj.io/sync-wave: "-1"

---
# Wave 0: ConfigMaps and Secrets
apiVersion: v1
kind: ConfigMap
metadata:
  name: myapp-config
  namespace: production
  annotations:
    argocd.argoproj.io/sync-wave: "0"

---
# Wave 1: Database
apiVersion: apps/v1
kind: Deployment
metadata:
  name: postgres
  namespace: production
  annotations:
    argocd.argoproj.io/sync-wave: "1"

---
# Wave 2: Application
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
  namespace: production
  annotations:
    argocd.argoproj.io/sync-wave: "2"

---
# Wave 3: Ingress
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp
  namespace: production
  annotations:
    argocd.argoproj.io/sync-wave: "3"

Sync waves define the order in which resources are synced. Lower numbers sync first. Resources in the same wave sync in parallel. This ensures dependencies are created before dependents.

App of Apps Pattern

App of Apps pattern


# Root application that manages all other applications
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: root
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/myorg/gitops-repo.git
    targetRevision: main
    path: applications
  destination:
    server: https://kubernetes.default.svc
    namespace: argocd
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

---
# Individual application managed by the root
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/myorg/gitops-repo.git
    targetRevision: main
    path: apps/myapp/overlays/production
  destination:
    server: https://kubernetes.default.svc
    namespace: production

The root application points to a directory containing Application manifests. When you add a new Application manifest to that directory, ArgoCD automatically creates and syncs it. This enables managing hundreds of applications declaratively.

Use ApplicationSets for dynamic applications

ApplicationSets generate Application manifests from templates and parameter lists. They support git directory, git file, matrix, and merge generators. Use them to manage fleet-wide deployments without manually creating each Application.

Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.

Stage 5 · Platform

GitOps & Progressive Delivery