What Is Argo CD? How GitOps Sync and Drift Detection Work

Originally published in February 2025. Last updated August 2026.

Argo CD is an open-source, GitOps-based continuous delivery tool built natively for Kubernetes. It continuously compares the target state of a Kubernetes cluster with the live state present in the Git repository, using Git repositories as the single source of truth, to identify drift and automate synchronization.

Kubernetes adoption continues to grow, increasing the need to manage deployments at scale. CNCF's 2026 Annual Cloud Native Survey found that 82% of container users ran Kubernetes in production in 2025, up from 66% in 2023. The 2026 Argo CD User Survey also found that 66% of respondents have used Argo CD in production for more than two years, reflecting its maturity as a GitOps platform.

New to Argo CD? This guide covers the essentials, from how it syncs applications to how it catches drift.

TL;DR

1. Argo CD is an open-source, pull-based GitOps tool that uses Git, Helm or OCI sources to define the desired state of Kubernetes applications.

2. The Application Controller compares live resources with the target state and marks applications as Synced or OutOfSync.

3. Argo CD tracks synchronization separately from health states such as Healthy, Progressing and Degraded.

4. A configured syncPolicy can enable automated sync, self-healing, and pruning when live resources drift from the desired state.

5. The API Server, Repository Server and Application Controller form the three primary components of the Argo CD control plane.

6. For teams that need to move changes progressively across environments, Argo CD pairs with Kargo, an environment promotion tool.

What Is Argo CD?

Argo CD's core is a Kubernetes controller that continuously evaluates the live cluster state against the target state and supports manual or automated synchronization. Its pull-based GitOps model retrieves the desired configuration from its source rather than requiring a continuous integration pipeline to push changes directly to the cluster.

While Git repositories serve as the primary source of truth for version-controlled environment states, Argo CD natively retrieves application manifests from:

• Git Repositories: Raw YAML, Kustomize overlays, or Jsonnet templates

• Helm Repositories: Standard packaged Helm charts

• OCI Registries: Helm charts and generic OCI artifacts (raw manifests, Kustomize, and more) distributed through OCI-compliant registries

Argo CD continuously compares live cluster resources against the rendered target manifests. Whenever the two diverge because a new revision changed the desired state, or because live resources were modified out-of-band, it flags the application as OutOfSync.

What Are the Core Components of Argo CD?

Argo CD relies on three primary components to generate manifests, expose application controls and reconcile live Kubernetes resources with the target state. It also includes supporting components, such as the ApplicationSet controller, Redis, and optional services like Dex for identity management, that extend its capabilities.

Table: Argo CD Core Components

                                                 Argo CD Architecture - Source

For a deeper comparison of single-instance, per-cluster, and hybrid Argo CD deployment models and their effects on these components at scale, see "Which Argo CD Architecture Is Best?"

How Does Argo CD Implement GitOps?

Argo CD implements GitOps principles through an in-cluster Application Controller that continuously compares each application's live cluster state with the target state stored in Git. When the two states differ, Argo CD marks the application as OutOfSync and supports manual synchronization or automated synchronization when auto-sync is enabled.

When a developer merges an updated Kubernetes manifest into a tracked branch, Argo CD detects the new revision and compares the generated manifests with the resources running in the cluster. Argo CD then displays the differences or synchronizes the application according to its configured sync policy.

For a closer look at how these manifests actually get generated and rendered, including CI-based rendering, sourceHydrator, Kargo, and OCI artifacts, see the Rendered Manifests Pattern guide.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: guestbook
  # Applications live in the Argo CD namespace by default. To manage
  # Applications from other namespaces, the "apps-in-any-namespace"
  # feature must be enabled and the namespace allow-listed.
  namespace: argocd
  finalizers:
    # Triggers cascading deletion: removing this Application also prunes
    # the resources it deployed. Omit it and deleting the Application
    # leaves the managed resources orphaned in the cluster.
    - resources-finalizer.argocd.argoproj.io
spec:
  # The Argo CD AppProject this Application belongs to. Projects scope
  # which repos, destinations, and resource kinds are permitted.
  # "default" is the built-in, unrestricted project.
  project: default
  source:
    # Where the desired state lives. Can be a Git repo, a Helm repo,
    # or an OCI registry (oci://...).
    repoURL: https://github.com/argoproj/argocd-example-apps.git
    # The revision to track. For Git: a branch, tag, or commit SHA
    # (e.g. HEAD, main, v1.2.3). For Helm/OCI: a chart version or
    # semver constraint (e.g. 1.2.* or >=1.0.0 <2.0.0).
    targetRevision: HEAD
    # Directory within the repo containing the manifests. Argo CD
    # auto-detects the tool (plain YAML, Kustomize, Helm, Jsonnet).
    path: guestbook
    # Tool-specific config is optional. Example for Helm:
    # helm:
    #   valueFiles:
    #     - values-prod.yaml
    #   parameters:
    #     - name: image.tag
    #       value: v2.0.0
  destination:
    # The target cluster. Use the in-cluster API endpoint for the
    # cluster Argo CD runs in, or a registered cluster's URL.
    server: https://kubernetes.default.svc
    # Alternatively, reference a cluster by its registered name
    # (mutually exclusive with `server`):
    # name: prod-us-east
    # The namespace resources are applied to when a manifest doesn't
    # specify its own. Cluster-scoped resources ignore this.
    namespace: guestbook
  syncPolicy:
    # Omit this whole block for manual syncs (drift is still detected
    # and surfaced as OutOfSync, just not reconciled automatically).
    automated:
      # Delete resources that exist in the cluster but no longer in
      # the target state. Defaults to false as a safety guard.
      prune: true
      # Automatically revert out-of-band changes to live resources
      # back to the target state.
      selfHeal: true
      # Allow a sync that would leave zero resources (e.g. everything
      # was pruned). Defaults to false to prevent accidental wipes.
      allowEmpty: false
    syncOptions:
      # Create the destination namespace if it doesn't exist.
      - CreateNamespace=true
      # Use server-side apply instead of client-side (helps with
      # large resources and field-manager conflicts).

The syncPolicy block determines how Argo CD responds to detected drift or new revisions. The top-level control is the automated block, which enables unattended synchronization; prune and selfHeal are options within it that refine that behavior:

Automated Sync (automated): Automatically synchronizes the application when a new revision changes the desired state, bringing live resources in line with the target manifests without manual intervention.

Self-Healing (selfHeal): Extends automated sync to live-state drift. Without it, an out-of-band change to a live resource is surfaced as OutOfSync but left in place until a human or a Git change acts on it; with selfHeal: true, Argo CD reverts the resource back to the state defined in Git, preserving it as the authoritative source of truth.

Automated Pruning (prune): Deletes cluster resources that are no longer defined in the desired application state. It is disabled by default as a safeguard against accidental removal.

How Does Argo CD Monitor and Sync Applications?

Argo CD manages applications through a continuous reconciliation loop. Rather than checking cluster status only when a pipeline runs, the Application Controller continuously evaluates two independent statuses for every managed application:

Sync Status (Synced vs. OutOfSync): Evaluates whether live Kubernetes resource definitions match the target manifests in Git, Helm, or OCI.

Health Status (Healthy, Progressing, Degraded, and others such as Suspended or Missing): Evaluates whether Kubernetes resources are operating as expected (for example, completing rollouts or passing readiness checks where applicable).

An application can be Synced but unhealthy, or OutOfSync while still serving traffic, which is why Argo CD tracks synchronization and health independently.

Configuring the reconciliation interval

Argo CD detects drift either through periodic reconciliation (120 seconds by default, plus jitter) or Git webhooks that trigger immediate reconciliation when changes are pushed. The interval is configurable in the argocd-cm ConfigMap:

# argocd-cm ConfigMap
apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-cm
  namespace: argocd
data:
  timeout.reconciliation: "120s"
  timeout.reconciliation.jitter: "60s"

Shortening the interval surfaces drift faster at the cost of more frequent polling load; setting timeout.reconciliation to 0disables polling entirely, relying solely on Git webhooks to trigger reconciliation.

For example, suppose an engineer changes a Deployment directly in the cluster using kubectl, increasing the replica count from three to five. Argo CD detects that the live resource no longer matches the version stored in Git and marks the application as OutOfSync. With selfHeal enabled, Argo CD reverts the count back to three on the next reconciliation.

What Are the Key Features of Argo CD?

• Argo CD provides the following capabilities for managing Kubernetes application delivery:

• Declarative GitOps Management: Uses Git as the source of truth for application definitions, environments and deployment configuration.

• Automated and Manual Synchronization: Synchronizes live Kubernetes resources with the desired state defined in version-controlled source manifests, either automatically or manually.

• Multi-Cluster and Multi-Tenant Management: Manages applications across multiple Kubernetes clusters from a single control plane with role-based access control (RBAC).

• Deployment History and Rollbacks: Maintains deployment history and enables rollbacks to previously deployed application revisions.

• Native Manifest Support: Evaluates application configurations defined in Kustomize, Helm, Jsonnet, plain YAML or custom configuration management plugins.

• Application Health and Drift Detection: Evaluates application health alongside synchronization status and configuration drift, including pod readiness and rollout status.

• SSO and Enterprise Access Control: Integrates with third-party identity providers through OpenID Connect (OIDC), OAuth 2.0 and Lightweight Directory Access Protocol (LDAP) for single sign-on and granular user access management.

What Are the Benefits of Using Argo CD?

Beyond the mechanics, Argo CD's GitOps model translates into concrete outcomes for engineering teams and the business:

• Fewer Deployment Errors, Faster Recovery: Because every deployment traces back to a Git commit, mistakes are easier to catch and roll back. Deployment history and rollback support mean recovering from a bad release takes minutes rather than a scramble.

• Less Manual Toil for Engineering Teams: Automated synchronization and self-healing remove the need for engineers to manually reconcile cluster state, freeing up time that would otherwise go to firefighting drift.

• Clearer Accountability and Traceability: Commit histories and pull requests give teams a shared, auditable record of who changed what and when, which shortens the time it takes to review changes or investigate an incident.

• Confidence at Scale Across Multi-Cluster Environments: ApplicationSets let teams generate consistent Argo CD Applications across many clusters from a shared template rather than managing each one by hand. According to the 2026 Argo CD User Survey, 79% use ApplicationSets, reflecting the value of this approach as deployments scale.

• A Foundation for Progressive Delivery: Argo CD handles deployment to a given environment, but many teams need to move changes progressively across environments and clusters as well. For that, Argo CD pairs with Kargo, a continuous promotion tool, that manages how changes advance from one environment to the next.

How Can I Get Started With Argo CD?

To get started with Argo CD, follow the steps below. For full installation and configuration instructions, see the official Argo CD Getting Started documentation.

1. Set up an Argo CD control plane.

2. Connect a Git repository containing the application manifests.

3. Create an Argo CD Application to manage deployment and synchronization.

Watch this video below to learn more about GitOps fundamentals and how Argo CD and Kargo work together to manage Kubernetes deployments at scale.

For more guidance on security, deployment strategy, and GitOps implementation, explore these resources:

1. Argo CD: Up and Running (O'Reilly): A free ebook covering GitOps fundamentals and hands-on Argo CD usage for teams managing Kubernetes clusters without deep Kubernetes expertise.

2. Akuity Academy: Introduction to GitOps and Argo CD: A self-paced course on GitOps fundamentals and core Argo CD concepts.

3. GitOps Best Practices Whitepaper: A whitepaper on GitOps implementation patterns — templating, repo structure, CI/CD integration, and promotion with Kargo — from the creators of Argo CD and Kargo.