GitOps with ArgoCD: When It Works (and When It Doesn't)

I get asked often whether a team should adopt ArgoCD. My answer is rarely a simple yes or no. It is usually: "Show me your repository layout and explain how you manage secrets." After that, the answer is almost always obvious.

ArgoCD is not a deployment autopilot you plug into a running Kubernetes infrastructure. It is a tool that makes visible and painful the decisions organizations should have made long ago. That is one of its greatest strengths, and it is the reason so many rollouts fail.

This article states clearly what works in practice and what does not. No gray areas.

What GitOps Actually Means

GitOps is not "deployment via Git commit." That oversimplification is the first and most consequential misunderstanding I encounter in projects.

The OpenGitOps initiative, building on Weaveworks' pioneering work, defines four core principles: The system state is declaratively described. It is versioned and immutable, stored in a version control system. Changes are automatically applied. A software agent continuously ensures convergence between the stored and the actual state.^[1]

The fourth principle is the critical one, and it is most often overlooked. GitOps is a pull model. ArgoCD polls the repository and actively brings the cluster into the defined state, continuously and self-healing. That is fundamentally different from a push-based CI/CD deployment, even when both involve Git.

Jez Humble and David Farley laid the conceptual foundation in Continuous Delivery: reproducible, fully automated deployments are the prerequisite for everything else.^[2] GitOps is the logical consequence of that idea for Kubernetes operations. Teams that understand the principle use ArgoCD correctly. Teams that only know the tool are building technical debt with GitOps branding.

When ArgoCD Actually Works

ArgoCD is optimized for Kubernetes-native workloads. It delivers reliably good results when the conditions are right.

Multiple clusters, one central Git repository as the source of truth. ArgoCD was built for exactly this use case. The ApplicationSet resource allows a single configuration to be rolled out automatically across dozens of clusters.^[4] For teams adopting multi-cluster architectures in the context of Kubernetes consulting in Germany, that is a concrete, measurable operational advantage over pipeline-based approaches.

Clear separation between platform and application teams. When a platform team maintains infrastructure components such as Ingress controllers, cert-manager, and the monitoring stack in a dedicated repository, and application teams manage their workloads in their own repositories, ArgoCD functions as an enforcement layer between intent and state. Sam Newman describes independent deployability as the core principle of the microservices approach.^[3] GitOps makes that independence operational, but only if the repository structure mirrors the team structure.

Compliance and audit requirements. Git history is a natural, immutable audit log. Every state change is versioned, traceable, and reversible. For organizations in regulated industries such as financial services, critical infrastructure, or healthcare, this is not a side effect but a central argument. No other deployment model delivers this audit trail without additional tooling.

Self-service deployment with a reduced attack surface. When development teams can deploy via pull request without needing direct cluster access, the attack surface shrinks considerably. ArgoCD handles actual cluster access through a service account with minimal permissions. That is the least-privilege principle in production practice, not in theory.

When It Fails

The list below does not describe theoretical risks. These are recurring patterns from real projects.

No declarative approach at the application layer. When applications generate state through undocumented database migration scripts, manual kubectl patches, or imperatively managed configuration, ArgoCD cannot fully represent the actual system state via Git. The sync status becomes a lie detector: "Synced" then means Kubernetes manifests match, not that the application is running correctly. Teams that miss this distinction lose trust in the entire process.

Organizational ambiguity over responsibilities. GitOps requires precise answers to two questions: Who is allowed to write to which repository? Which repository determines the deployment status of an environment? In organizations with grown infrastructure structures and different deployment paths for different teams, ArgoCD does not solve the organizational problem. It makes it visible and painful. That is useful, but without reorganizing responsibilities, ArgoCD remains an expensive symptom-monitoring tool.

Secrets management as an afterthought. ArgoCD synchronizes everything that lives in Git. Secrets do not belong in Git, not even in encrypted form, unless there is an explicit, agreed-upon strategy in place: Sealed Secrets, External Secrets Operator with a cloud-provider secret store, or HashiCorp Vault. Teams that treat secrets management as a later problem during ArgoCD adoption end up in a hybrid model. Manifests run through ArgoCD; secrets are injected via CI pipeline or manually via kubectl. That is not GitOps. It is GitOps for everything except the most critical parts.

Misunderstood drift management. ArgoCD detects deviations between the Git state and the cluster state. When teams run ArgoCD in auto-sync mode with self-heal enabled, without understanding what the agent resets upon drift, hard-to-debug situations arise. A Kubernetes operator legitimately modifies a resource. ArgoCD overwrites the change. The application breaks. The solution is not a blanket rejection of auto-sync. The solution is an explicit model defining which resources are managed by ArgoCD and which are not, documented, testable, and agreed upon.

Monorepos without a strategy. A single Git repository for many applications and multiple clusters is technically possible. Operationally it is a maintenance nightmare. Every commit potentially triggers syncs for all applications. Pull request reviews become unwieldy. Branching strategies explode in complexity. The recommendation is unambiguous: one repository per team or per bounded context, aggregated through ArgoCD ApplicationSets.^[4]

Clear Recommendations for Getting Started

Teams adopting ArgoCD in the context of Kubernetes consulting should follow this sequence.

Platform repository first, business applications later. The first ArgoCD use case should be the monitoring stack, the Ingress controller, and cert-manager, not the business application. This gives the team time to understand ArgoCD concepts such as App-of-Apps patterns, health checks, sync waves, and resource hooks in a controlled environment before the deployment of revenue-critical applications is at stake.

Define sync policies explicitly and deliberately. Auto-sync with pruning and self-heal is powerful. It is also dangerous for teams that have not yet worked through drift scenarios. Recommended starting point: manual sync with alerts on drift. Automation comes once the team understands what it is automating.

Finish secrets management before adopting ArgoCD. External Secrets Operator with HashiCorp Vault or a cloud-provider secret store is the recommended production solution. Sealed Secrets are acceptable for smaller teams without Vault infrastructure. No solution is not an option.

Repository structure follows team topology, not technology. A repository for "all Helm charts" is a technical perspective. A repository for "Team Payments" is an organizational perspective. The latter scales with the organization; the former becomes a bottleneck.^[3]

Integrate manifest validation into the pull request process. Kubeconform, Conftest with OPA policies, and Helm template validation prevent ArgoCD from syncing valid but misconfigured manifests into the cluster. ArgoCD is not a linter. It executes what Git says.

Conclusion

ArgoCD is a mature solution for teams that want Kubernetes deployments to be declarative, audit-safe, and operationally controlled. It is not a tool you add to a running infrastructure and expect to impose order. Choosing GitOps with ArgoCD is an architecture decision with direct consequences for team topology, repository structure, secrets management, and compliance requirements.

Teams that lay these foundations before ArgoCD runs its first sync will build a stable deployment platform that permanently reduces the cognitive load on operations teams.^[2] Teams that skip them have done nothing but attach a Git URL to existing problems.

Sources

[1] OpenGitOps Working Group: GitOps Principles v1.0.0, Cloud Native Computing Foundation (CNCF), 2021. https://opengitops.dev

[2] Jez Humble, David Farley: Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation, Addison-Wesley Professional, 2010.

[3] Sam Newman: Building Microservices: Designing Fine-Grained Systems, 2nd edition, O'Reilly Media, 2021.

[4] Argo CD Project: ApplicationSet Controller, Argo CD Documentation, 2024. https://argo-cd.readthedocs.io/en/stable/user-guide/application-set/

[5] Alexis Richardson: GitOps: Operations by Pull Request, Weaveworks Blog, 2017. https://www.weave.works/blog/gitops-operations-by-pull-request