ArgoCD Curriculum
Sync Policies
Sync Waves and Hooks
Sync Windows
On this page
Subtopic•Sync Policies

Sync Policy Overview

In the previous module, we completed our exploration of Kustomize configurations, detailing base and overlay directory structures, strategic merges, JSON patches, and best practices. With those templates clear, we will now start Module 7: Sync Policies and Waves, beginning with Sync Policies Overview.

When you deploy applications with ArgoCD, you must configure how the controller synchronizes resources when changes are detected in Git or when configuration drift occurs in the cluster.

In this guide, we will cover the synchronization reconciliation loops, compare manual and automated sync policies, and review execution rules.

1. The Synchronization Reconciliation Loop

ArgoCD maintains a continuous execution loop to monitor application states:

Reconciliation Sync Loop
        │
        ▼ (1. Pull latest commit from Git)
  Git Repository (Desired State)
        │
        ▼ (2. Compare with active resources)
  Cluster API (Actual State)
        │
        ▼ (3. Set Sync Status)
  Sync Status Code: Synced / OutOfSync
        │
        ▼ (4. Evaluate Sync Policy)
  Sync Action: Manual approval or Automatic update
  1. Pull State: The controller fetches the latest commit from Git and compiles the desired state.
  2. Compare State: It queries the cluster API to retrieve active resources.
  3. Compare Diff: It runs comparisons to check for differences.
  4. Apply Policy: Depending on your configuration, it waits for manual approval or applies changes automatically.

2. Manual vs. Automated Sync Policies

You can configure your application to use one of two synchronization models:

Manual Sync Policy (Default)

When a developer pushes changes to Git, ArgoCD flags the application as OutOfSync in the dashboard but takes no action. An administrator must log in to the web console or execute a CLI command to trigger the synchronization run:

# Sync application changes manually
argocd app sync production-payment-api
  • Pros: Safe, controlled deployments. Fits environments that require manual approval before changes go live.
  • Cons: Introduces human delay.

Automated Sync Policy

ArgoCD automatically detects changes in Git and applies the manifests to the cluster in real time:

spec:
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
  • Pros: Fast deployments, zero human intervention. Guarantees that the cluster matches Git.
  • Cons: A broken config commit in Git will deploy immediately to production.

3. Operational Best Practices: Sync Policies

  • Use manual syncs in production: For mission-critical databases or core services, keep manual syncs enabled to ensure updates run during scheduled maintenance.
  • Enable auto-sync in staging: Configure automated syncs in development and staging environments to speed up testing feedback loops.
  • Monitor out-of-sync states: Set up notifications to alert the operations team if an application remains out-of-sync for more than 30 minutes.

4. Sync Policies Reference Summary

Sync PolicyTrigger SourceCore Use CaseOperational Benefit
ManualAdmin CLI / Web ConsoleProduction clusters, high-risk databases.Maximum control, zero risk of auto-failures.
AutomatedGit push webhookStaging clusters, microservices.Zero human delay, continuous parity.

Now that we have covered the conceptual framework of ArgoCD's sync policies, the next step is automated syncs. In the next section, we will cover how to configure and manage automated synchronization policies.

←Previous ModuleKustomize with ArgoCD