2026
Argo CD: GitOps Continuous Delivery for Kubernetes
When the cluster state and the repository state start diverging quietly, nobody notices until something breaks in a way that is hard to explain. Argo CD keeps them in sync by treating Git as the single source of truth.
Deploying to Kubernetes by hand works fine for a single cluster and a handful of services. You write the manifests, apply them with kubectl and move on. The problems start when the number of services grows, when multiple teams share a cluster, when someone patches something directly in production without updating the repository. At that point the cluster state and the repository state start diverging quietly and nobody notices until something breaks in a way that is hard to explain.
Argo CD is a GitOps controller for Kubernetes. It treats a Git repository as the single source of truth for what should be running in a cluster. It watches that repository continuously. When the cluster drifts from what Git says it should look like, Argo CD flags it. When a change is pushed to Git, Argo CD can apply it to the cluster automatically. The cluster is always a reflection of the repository, not of whoever ran kubectl last.
What GitOps actually means in practice
GitOps is a word that gets used loosely, but the core idea is specific. The desired state of the system lives in a version-controlled repository. An automated agent continuously reconciles the actual state of the system with that desired state. Changes happen by updating the repository, not by running commands against the system directly.
The practical consequence is that the Git history becomes an audit trail for every change that has ever been deployed. A rollback is a revert commit. A diff between two points in time tells you exactly what changed in the cluster between those points. The question of what is running in production has a clear answer: whatever is in the main branch of the repository.
This matters most when something goes wrong. If you can answer the question of what changed, when and who approved it, you have a much shorter path to understanding why something broke. Teams that run Kubernetes without a tool like Argo CD often find that question surprisingly hard to answer when the pressure is on.
Core concepts
Argo CD has a small number of concepts that everything else builds on. Understanding them makes the rest of the tool straightforward.
Application
The central unit in Argo CD. An Application links a source — a Git repository path — to a destination cluster and namespace. Argo CD watches that source continuously. Any drift between what is in Git and what is running in the cluster gets flagged immediately.
Sync
The act of reconciling the cluster state with the desired state in Git. A sync can be triggered manually or configured to happen automatically whenever a change is detected. Argo CD applies the manifests in the correct order, respecting resource dependencies where they exist.
Application Health
Argo CD evaluates the health of every resource it manages. A Deployment that is rolling out, a pod that is crash-looping, a PVC that is stuck in pending — each of these surfaces in the UI with a clear status. Health checks are built in for common resource types and can be extended with custom Lua scripts.
Project
A logical boundary around a group of Applications. Projects control which source repositories are allowed, which destination clusters a team can deploy to, which resource kinds are permitted. They are the access control layer above individual Applications.
Repository
Argo CD reads from Git repositories, Helm chart repositories. Multiple repositories can be registered and used across different Applications. Credentials for private repositories are stored in Kubernetes secrets and managed separately from the Application definitions.
What an Application looks like
An Argo CD Application is itself a Kubernetes resource. It lives in the cluster and can be managed like anything else. The spec names the source repository, the path within that repository, the destination cluster and namespace and the sync policy.
Example Application manifest
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: payments-service
namespace: argocd
spec:
project: platform
source:
repoURL: https://github.com/org/k8s-config
targetRevision: main
path: services/payments
destination:
server: https://kubernetes.default.svc
namespace: payments
syncPolicy:
automated:
prune: true
selfHeal: true
Because the Application is a Kubernetes resource, it can itself live in a Git repository. This is the App of Apps pattern: a root Application that points to a directory of other Application manifests. Bootstrapping a new environment becomes a single kubectl apply that registers the root Application. Argo CD does the rest.
Sync strategies
How aggressively Argo CD reconciles the cluster with Git is configurable per Application. The right choice depends on the environment and how much confidence the team has in the pipeline upstream of the repository.
Manual sync
Changes in Git do not automatically apply to the cluster. An operator reviews the diff and clicks sync, or runs the CLI command. Useful when a team wants a human gate before anything reaches production. The cluster drifts from Git until the sync is deliberately triggered.
Automated sync
Argo CD applies changes as soon as it detects a difference between Git and the cluster. No human step. Combined with a mature CI pipeline and good test coverage, automated sync gives you continuous delivery in practice rather than just in theory.
Automated sync with self-healing
If someone modifies a resource directly in the cluster outside of Git — an emergency kubectl edit, a manual patch — Argo CD detects the drift and reverts it. Git is the authority. Manual changes do not survive. This enforces GitOps strictly rather than relying on convention.
Automated sync with pruning
When a resource is removed from Git, Argo CD deletes it from the cluster. Without pruning enabled, removed manifests are simply ignored and the orphaned resources remain. Pruning keeps the cluster clean but requires confidence in what is being removed, since the deletion is automatic.
What Argo CD can deploy from
Argo CD does not require a specific manifest format. Teams that already use Helm, Kustomize or plain YAML do not need to change tooling to adopt it.
Plain Kubernetes YAML
Raw manifests committed directly to the repository. Argo CD applies them as-is. Simple, transparent, easy to review in a pull request.
Kustomize
Argo CD has native Kustomize support. Point the Application at a directory containing a kustomization.yaml and Argo CD runs the build step before applying. Overlays, patches and name prefixes all work without any pipeline configuration.
Helm
Argo CD can deploy a Helm chart from a chart repository or from a Git path. Values can be specified inline in the Application spec or in separate values files. The rendered manifests are what Argo CD tracks for drift, not the Helm release state.
Jsonnet
Argo CD supports Jsonnet for teams that generate manifests programmatically. Less common but useful when the templating requirements go beyond what Helm and Kustomize can comfortably express.
Drift detection
Argo CD polls the source repository at a configurable interval. It also supports a webhook from Git, which triggers an immediate check on push rather than waiting for the next poll cycle. When a difference is found between the live cluster state and the desired state from Git, the Application is marked as OutOfSync.
Sync status breakdown
Synced
Cluster matches Git. No action required.
OutOfSync
Difference detected. Pending sync or awaiting manual approval.
Unknown
Argo CD cannot determine state. Usually a connectivity issue.
The diff view in the UI shows exactly which fields changed between the live state and the desired state. For teams doing code review on infrastructure changes, this is a useful second check: what Argo CD will actually apply matches what the pull request said it would change. Surprises from implicit defaults or controller mutations show up here.
Access control
Argo CD has its own RBAC system built on top of Casbin. Authentication is either local users or an external identity provider via OIDC. For organisations that already have a central IdP this means teams log in with credentials they already manage.
User authenticates
Via the built-in local user system or an external identity provider through OIDC. GitHub, Google Workspace and Okta all work. Groups from the provider are passed through to Argo CD.
Groups mapped to roles
Argo CD's RBAC maps identity provider groups to internal roles. A member of the platform-team group in your IdP becomes an admin in Argo CD. The mapping is defined in a ConfigMap.
Roles scoped to Projects
Roles can be global or scoped to specific Projects. A team can have full control over their own Project while having read-only access to others. The boundary is enforced at the Project level.
Actions permitted
Permissions cover sync, create, delete, override and action. Fine-grained enough to allow a team to trigger syncs without being able to delete Applications or modify Project configuration.
Managing multiple clusters
A single Argo CD installation can manage many clusters. Each cluster is registered by adding its kubeconfig credentials to Argo CD. Applications then target a specific cluster by its registered server address. A centralised Argo CD instance becomes the control plane for the entire fleet.
This is common at organisations running separate clusters for staging and production. The same repository structure drives both environments, with environment-specific values supplied through Kustomize overlays or Helm values files. A change merged to main syncs automatically to staging. Promotion to production is a separate commit or a separate branch, depending on the team's workflow.
At larger scale, some teams run an Argo CD instance per cluster. This avoids a single control plane becoming a dependency for every cluster in the fleet. The tradeoff is more instances to maintain and no single pane of glass across all clusters unless a tool like Argo CD ApplicationSets is used to coordinate across them.
Notifications
Argo CD has a notifications controller that watches Application events and sends messages to external systems. Slack, Teams, PagerDuty, email and webhooks are all supported. The trigger conditions are configurable: sync failed, health degraded, Application became OutOfSync. Teams typically wire this up so that a deployment failure in any environment shows up in a Slack channel immediately rather than waiting for someone to check the UI.
Where it fits
Argo CD does not replace a CI system. It picks up where CI leaves off. The CI pipeline builds images, runs tests, updates the manifest repository with the new image tag. Argo CD watches that repository and makes sure the cluster reflects what CI produced. The two responsibilities are cleanly separated.
The argument for adopting it is not complexity reduction. Argo CD adds a component to operate. The argument is visibility and consistency. Without something like it, the actual state of a production cluster accumulates undocumented changes over time. Some of those changes were intentional. Some were emergency patches that never made it back into the repository. The longer this goes on the harder it becomes to reason about what is actually running.
Argo CD does not prevent drift by making it impossible. It makes drift visible the moment it happens and, with self-healing enabled, corrects it automatically. The operational model shifts from hoping the cluster matches the repository to having a tool that guarantees it does.