Argo CD continuously compares Git with Kubernetes
Argo CD watches application definitions in Git and compares them with resources running in Kubernetes. The application controller marks drift as OutOfSync and can apply the desired manifests. A repository server caches Git content and generates Kubernetes manifests from a repository URL, revision, path, and Helm settings. The API server supplies the web interface, CLI, status, operations, authentication, RBAC, repository credentials, cluster credentials, and webhook handling. The architecture is understandable because each service has a narrow delivery role.
That model changes the pipeline boundary. CI can build an image and update a manifest in Git without holding direct access to the Argo CD API or the target cluster. Argo CD observes the commit and performs the deployment. Reviews and Git history become part of the audit trail, while the interface shows resource health and differences. This works well when a platform team already treats configuration repositories as controlled production inputs. It feels ceremonial when one operator applies a handful of manifests to one cluster.
Automatic sync is safe only with deliberate deletion rules
Applications can sync manually or automatically. Automatic sync handles new desired state without a separate deployment command. Self-heal can reverse live changes that differ from Git. Pruning removes resources deleted from the repository, but it is disabled by default. A further allow-empty setting is required before automation can remove every resource in an application. Those defaults reduce the chance that one empty render wipes a workload.
ApplicationSet-managed applications have another wrinkle: changing the child application's auto-sync field has no effect because the parent controls it. Rollback is unavailable while automatic sync is enabled. The controller also limits repeat attempts for the same commit and parameters, while retry behavior has its own backoff settings. Teams should test these semantics with a failed render, an intentionally deleted resource, an emergency live patch, and a bad repository revision before enabling self-heal or pruning across production.
What happened when we ran it
Our Go sandbox installed 686 packages in 109 seconds at commit 4d09b7b. The source build succeeded in 253 seconds. Tests ran for 391 seconds and failed with exit code 1: 37 passed and 3 failed out of 40. The 238.5 MB checkout contained 5,544 files and roughly 550,767 lines of source, so both the build time and dependency count are reasonable for a delivery controller of this size.
The supplied tail of the test log showed successful packages for Swagger, labels, TLS, versions, webhooks, and workload identity, along with several packages that had no test files. It ended with FAIL but did not contain the names or error messages of the 3 failing cases. We cannot tell from that excerpt whether the failures came from code, missing cluster services, or the unprivileged sandbox. A production evaluation should retain the first error and rerun the affected packages.
Our scan found 16 CI workflow files, a Dockerfile, and a tests directory. The measured environment had 3 CPUs, 8 GB of RAM, Go 1.24 on Debian, no secrets, and no Kubernetes cluster. We therefore did not install Argo CD, reconcile an application, verify container signatures, or test disaster recovery. The result establishes that the source built and that the selected test run was not clean. It says nothing about reconciliation speed or cluster scale.
The first install creates security work immediately
The quick start creates an argocd namespace and applies official manifests. Documentation recommends a pinned version for production. The default installation uses a self-signed certificate and is not exposed outside the cluster, so operators must choose trusted TLS, ingress, a load balancer, or temporary port forwarding. An initial administrator password is stored in clear text inside a Kubernetes secret until the password is changed and that secret is deleted.
Registering an external cluster creates an argocd-manager service account and binds it to an administrator-level cluster role. The permissions can be narrowed for create, update, patch, and delete operations, but cluster-scope get, list, and watch remain required. That access is why repository approval, Argo CD RBAC, SSO, secret storage, audit logs, and controller network paths deserve threat modeling. A compromised delivery controller is a cluster incident, not a broken dashboard.
Version 3.5.1 has signed release artifacts
Release v3.5.1 arrived on August 12, 2026. Its notes say container images are signed with cosign and provenance is generated for images and CLI binaries meeting SLSA Level 3. The patch includes fixes for ApplicationSet loops, reconciliation cache behavior, secret masking, and manifest cache keys. The release page also tells users crossing minor versions to read the upgrade guide instead of applying new manifests blindly.
GitHub recorded 24,003 stars, 4,401 open issues and pull requests, and a last push on August 26, 2026. The combined open count reflects a large user and contributor base, not 4,401 confirmed defects. Community support includes GitHub Discussions, Slack, weekly contributor office hours, and a monthly user meeting under the CNCF code of conduct. Current releases and same-day repository activity support a high maturity score despite our failed test run.
Flux is the closest decision, not a generic CI server
Flux follows the same GitOps idea with a more controller- and custom-resource-centered experience. Argo CD is easier to choose when teams want one visible application interface, CLI, API, and operational control plane. Fleet is worth comparing for Rancher users managing many clusters. Spinnaker belongs in the discussion only when staged delivery spans additional infrastructure and the organization accepts a larger pipeline platform.
Argo CD earns adoption when Kubernetes delivery is already a platform responsibility. The build passed, the release process includes signed artifacts, and the reconciliation model is well documented. Our 3 failed tests keep commit 4d09b7b from a clean lab verdict, while the broad cluster permissions keep installation from being a casual add-on. Start with manual sync, a pinned v3.5.1 manifest, limited destinations, and recovery drills. Turn on self-heal and pruning after the team can explain exactly what each will delete.