Argo CD: GitOps Continuous Delivery for Kubernetes, Reviewed for Adoption

What Argo CD is for, and who it is actually for

Argo CD watches a Git repository that describes the desired state of a Kubernetes cluster, and it makes the cluster match. The README states the project's two design positions plainly: application definitions, configurations and environments should be declarative and version controlled, and deployment and lifecycle management should be automated, auditable and easy to understand. That is the whole thesis. The unit of work is not a build job or a release pipeline; it is the difference between what Git says and what the API server currently holds.

The audience is therefore narrow and specific. You need a Kubernetes cluster, a Git repository holding manifests, and a team willing to treat that repository as the source of truth. Helm charts, Kustomize overlays and plain YAML all qualify, and the builder image in the repository's Dockerfile installs helm, kustomize and git-lfs, which tells you which manifest tooling the project expects to encounter. If your deployment process is a shell script that runs kubectl apply from a CI runner and nobody records the resulting state anywhere, Argo CD has nothing to reconcile against and will not help you.

The Application object and the reconciliation loop

The central abstraction is the Application, a Kubernetes custom resource that names a source (a Git repository, a revision, a path) and a destination (a cluster and a namespace). You create Applications, and the controller does the rest on a loop. The repository layout reflects this split: controller/ holds the reconciliation logic, reposerver/ handles fetching and rendering manifests from Git, applicationset/ generates Applications from templates, and gitops-engine/ contains the diff and sync machinery, vendored in go.mod as github.com/argoproj/argo-cd/gitops-engine/v3.

Data flow runs in one direction. The repo server clones the repository at the requested revision and renders it, the controller compares the rendered result against live objects in the destination cluster, and any difference shows up as OutOfSync. A sync applies the rendered manifests. Because the comparison is continuous rather than triggered once, a manual kubectl edit that diverges from Git becomes visible instead of silently persisting.

The repository also carries cmpserver/ and resource_customizations/, which are the extension points for rendering formats the built-in tooling does not cover and for teaching the diff engine how to compare custom resources. That is where a team with in-house templating ends up, and it is more work than the README's two design principles suggest.

Installing Argo CD and syncing a first application

The README does not restate installation steps. It points to the complete documentation at argo-cd.readthedocs.io and to a live demo at cd.apps.argoproj.io, and the repository ships a manifests/ directory and a Helm chart published on Artifact Hub. The chart is the path most platform teams take, because it keeps the control plane itself under the same version control discipline the tool enforces elsewhere. The chart is published as argo/argo-cd; consult the Artifact Hub page for the current values schema rather than copying flags from a blog post.

Once the control plane is running, the CLI is the fastest way to see whether the model fits. The binary is named argocd, per the Makefile's CLI_NAME and BIN_NAME variables. The README does not document CLI installation or the exact flag set for creating an Application, so treat the documentation as the source for both rather than copying commands from a third-party post.

What the repository does confirm is the shape of the project you are adopting. The Makefile defines CLI_NAME and BIN_NAME as argocd, and the Dockerfile installs helm, kustomize and git-lfs into the builder image, which is the tooling the manifest pipeline expects to find. The controller, repo server and application set controller live in separate top-level directories, so a deployment of Argo CD is several workloads, not one binary.

Before you sync anything, decide which revision of the repository the Application will track and what the destination cluster and namespace are. Those two decisions are what the Application resource encodes, and getting them wrong is the most common reason a first sync produces a diff nobody expected.

Where Argo CD stops being the right tool

Argo CD does not build or test code. It has no concept of a compile step, a unit test suite or an artifact registry in the delivery path. Teams arriving from Jenkins often expect a single system that runs tests and then deploys; Argo CD covers only the second half, and only for Kubernetes. The project's own README lists a comparison of Argo CD, Spinnaker, Jenkins X and Tekton as background reading, which is an implicit acknowledgement that it sits in a category of its own rather than replacing a general CI server.

The second boundary is Kubernetes itself. The destination is a cluster and a namespace. Anything that must be provisioned outside a cluster, or any deployment target that is not a Kubernetes API server, falls outside the model.

The third limitation is operational and worth stating plainly: the control plane is itself a set of workloads running in a cluster, and it needs credentials to reach every destination cluster and every Git repository you point it at. That makes it a high-value target and a component whose own availability matters. The repository carries a SECURITY.md and a SECURITY_CONTACTS file, which is the right place to look before you decide how much access to grant it. Nothing in the README describes a rollback procedure, so treat the documentation as the source for that rather than assuming one exists.

Argo CD compared with Flux, and with a Jenkins pipeline

Flux is the comparison that matters most, and the difference is architectural rather than feature-level. Flux is built as a set of Kubernetes controllers that each own a piece of the problem, and its configuration is expressed as custom resources you write and commit. Argo CD ships a single control plane with a first-class Application resource and a web UI, and it separates the repository server from the reconciliation controller so that manifest rendering happens in a distinct component. That separation is why cmpserver/ exists as its own directory: rendering is a pluggable concern, not a library call inside the controller.

The practical consequence is where you spend your time. Argo CD gives you a UI and a CLI to inspect sync status, which shortens the loop for teams who need to see drift without reading controller logs. Flux keeps more of the surface inside the cluster's own API. Neither is a superset of the other, and the choice usually follows from whether your team wants a dashboard as part of the delivery path.

Against Jenkins the comparison is simpler and less useful. Jenkins runs jobs; Argo CD reconciles state. A Jenkins pipeline that ends in kubectl apply and an Argo CD Application that syncs the same manifests can coexist, and in many organisations they do, with Jenkins producing images and Argo CD consuming the manifests that reference them.

Maintenance, release cadence and licence

The last push to the default branch was on 2026-08-27, and the most recent release, v3.5.2, carries the same timestamp, with v3.4.8 published alongside it and v3.5.1 on 2026-08-12. Two maintained minor lines moving in parallel is the pattern to plan around: upgrade cost is not a single jump but a decision about which line you track, and the presence of a v3.4.x series alongside v3.5.x means backports are part of the project's release process.

Argo CD is licensed under Apache-2.0, which permits commercial use and modification and includes an explicit patent grant. That is permissive and unremarkable for internal platform tooling. It does mean that if you fork and redistribute, you carry the notice and attribution obligations that come with the licence; read LICENSE and your own legal counsel rather than treating this paragraph as advice.

The build itself is a Go module, github.com/argoproj/argo-cd/v3, and go.mod pins go 1.27.0 with a comment warning not to bump it unless newer features are required. The Dockerfile builds from a pinned Ubuntu base image by digest and installs a pinned git version, which is a deliberate reproducibility choice and also means base image updates arrive as explicit dependency bumps you will need to review.

Editorial conclusion

Adopt Argo CD if your Kubernetes manifests already live in Git and you want a controller that continuously compares cluster state against that repository, with drift visible in one place. Do not adopt it as a Jenkins replacement for building and testing code, and do not adopt it if your delivery process has no version-controlled desired state to reconcile against. Before committing, verify the install path that matches your environment: the README points to the complete documentation and the live demo, and the repository ships manifests/ and a Helm chart published on Artifact Hub, so confirm which of those your platform team will own.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes