Git becomes the deployment contract
Argo CD gives Kubernetes teams a clear answer to a messy question: which configuration should the cluster actually be running? An Application points to manifests in Git and a destination cluster. Argo CD renders those manifests, compares them with live resources, reports whether they are synchronized and healthy, and applies changes during a sync. Git history becomes the reviewable record, while the controller keeps checking whether reality still matches it.
That model removes deployment credentials from many CI pipelines. A build system can publish an image and update a manifest; Argo CD, already inside the delivery environment, performs the cluster operation. Operators get a browser interface, CLI, and API for examining resources, events, logs, health, differences, and sync history. Manual sync is available for guarded environments, while automated sync can continuously correct drift.
Argo CD understands plain Kubernetes YAML and common generators such as Helm and Kustomize. ApplicationSet can produce many Applications from templates, which is useful for repeating a service across clusters or environments. AppProjects limit permitted source repositories, destinations, and resource kinds. These pieces make it more than a manifest applier: it is a control plane for who may deploy what, from where, and to which cluster.
A quick install with a long production checklist
The getting-started path is honest enough for a local trial. Create an argocd namespace and apply the official manifest. The resulting API server is not exposed outside the cluster, uses a self-signed certificate, and stores an initial administrator password in a Kubernetes Secret. Port forwarding gets the UI open quickly, and a sample Application demonstrates the first sync. The documentation recommends pinning a version instead of using the moving stable branch in production.
Moving beyond that example is platform work. You need trusted TLS and an ingress or load balancer, repository credentials, SSO, RBAC, Projects, secret handling, notifications, metrics, backups, and an upgrade process. Adding an external cluster creates a service account that is initially bound to an administrator-level ClusterRole. The docs explain how to narrow write access, but Argo CD still requires cluster-wide read access for get, list, and watch. That privilege model deserves threat modeling, especially when one Argo CD installation manages several production clusters.
The default AppProject is suitable for testing, not a safe tenancy boundary. Project documentation recommends dedicated projects with explicit sources, destinations, and resource permissions. Teams should define those boundaries before onboarding application owners, then give pipelines narrowly scoped project roles instead of broad administrator tokens. Git access is also a security boundary because write access to a trusted repository can translate into deployed resources.
The operational payoff is real
Argo CD is strongest when a platform has enough applications that manual kubectl and bespoke release scripts stop being auditable. Its resource tree turns a deployment into a visible set of Deployments, Services, Jobs, and related objects. Drift is explicit rather than discovered during an incident. Sync waves and hooks can order work, while health assessments help an operator see whether applied objects became usable. Multi-cluster registration keeps the same application model across environments.
The HA manifests run more replicas and Redis in HA mode, but require at least three different Kubernetes nodes because of pod anti-affinity. IPv6-only HA clusters are explicitly unsupported. At scale, repo-server behavior matters: it clones repositories, executes generators, caches results, and uses local temporary storage. Large monorepos or too many concurrent render jobs can exhaust disk, memory, or process limits. The application controller also needs queue and shard tuning as application and cluster counts rise. The project documents these bottlenecks well, which does not make them disappear but does make capacity planning possible.
Helm compatibility has boundaries
Argo CD uses Helm as a template engine, then owns deployment through its own synchronization model. It does not perform a conventional Helm install and later Helm upgrades. The documentation warns that every action looks like a sync, so pre-install and pre-upgrade hooks can run together. Some Helm hooks are ignored, and defining an Argo CD hook causes all Helm hooks to be ignored. Hook deletion also follows Argo CD semantics. Charts that depend heavily on Helm's release lifecycle need deliberate adaptation and testing.
There is a long-standing UI issue too: when values files or inline values override a chart, the parameters panel does not display the complete effective values. The manifests can still render correctly, but the interface is not a perfect source of truth for Helm input. Keep configuration in Git, inspect rendered differences, and do not ask an operator to reconstruct precedence from the UI during an incident.
Health, releases, and the decision
Argo CD was pushed on August 13, 2026, and v3.5.1 was released the previous day. The maintainers also shipped patches for the 3.4 and 3.3 lines on August 12, strong evidence of active branch maintenance. GitHub counted 3,494 open issues and 845 open pull requests. That queue reflects a very large project and user base, not 4,339 verified defects, but upgrades still need staging because changes span controllers, APIs, authentication, generators, and the UI.
The v3.5.1 patch fixed tight reconciliation loops and several secret-masking paths, among other bugs. Current pull-request activity covers controllers, ApplicationSet, OIDC, caches, and newer Kubernetes behavior. Documentation is excellent, including security, scaling, disaster recovery, release provenance, and version-specific upgrade notes. Signed images and SLSA Level 3 provenance add useful supply-chain controls.
Choose Argo CD when Kubernetes delivery is a platform capability, not a side script. It gives teams a strong shared language for desired state, drift, health, and promotion. For one tiny cluster, its components and security surface may be more service than you need. For a growing Kubernetes estate with engineers ready to operate it properly, Argo CD is the benchmark other GitOps systems have to beat.