Managing Kubernetes manifests manually or via imperative CI scripts creates drift, audit gaps, and fragile deployments that fail under pressure. Argo CD—GitOps for Kubernetes—solves this by treating your Git repository as the single source of truth, continuously reconciling cluster state against declared configuration without external push mechanisms. This shift from push-based pipelines to pull-based reconciliation is fundamental for teams needing reliable, auditable, and self-healing infrastructure at scale.
What Is Argo CD and How Does It Work?
At its core, Argo CD is a controller that runs inside your Kubernetes cluster. Unlike traditional CI/CD tools that push artifacts to the cluster using stored credentials, Argo CD pulls definitions from Git and applies them locally. This architecture eliminates the need for external systems to have write access to your production API server, significantly reducing your attack surface.
The reconciliation loop operates on three distinct phases:
- The Repo Server clones your Git repository and renders manifests (supporting raw YAML, Helm, Kustomize, or Jsonnet)
- The Application Controller compares the desired state from Git against the live state in the cluster
- If auto-sync is enabled and policies allow, it applies the necessary changes to close the gap
This comparison happens continuously—typically every three minutes by default—which means manual edits to the cluster are flagged as “OutOfSync” almost immediately. For teams exploring declarative Kubernetes deployments, understanding this distinction is critical because it changes how you structure both your repository and your release process.
Traditional Deployment Methods and Their Limitations
Before diving into GitOps, it’s worth examining why teams initially rely on imperative methods:
kubectl apply—the standard CLI tool—works by providing YAML manifests that describe the desired state of Kubernetes resources (Deployments, Pods, Services, Ingresses, ConfigMaps, Secrets). While versatile and flexible enough to script advanced patterns like blue-green or canary releases, it suffers from operational discipline issues. Each step requires manual specification of resources, and a single mistake can disrupt deployment.
Kustomize—a declarative tool that modifies base YAML manifests using patches and transformations—solves some problems by clearly stating how configuration is layered. However, patching can become subtle as overlays evolve over time, making it difficult to reason about cluster state when the structure isn’t kept clean.
Helm—the package manager for Kubernetes—bundles everything needed into a chart using Go-based templating. It provides versioning, rollback support, and a large ecosystem of community charts. Yet Helm introduces its own learning curve with Go templating, and misconfigured charts can introduce reliability or security issues.
Each approach has tradeoffs in operational habits, risk profiles, and team maturity requirements—hence the growing adoption of GitOps tools like Argo CD.
Setting Up Argo CD for Production
While kubectl apply works for testing, production environments require a managed installation via Helm or the Argo CD Operator. I recommend the official Helm chart because it exposes every configurable parameter without forcing you to maintain forked manifests.
# Step 1: Add the repository and update cache
helm repo add argo https://argoproj.github.io/argo-helm
helm repo update
# Step 2: Create a dedicated namespace for isolation and RBAC scoping
kubectl create namespace argocd
# Step 3: Install with high availability enabled
helm install argocd argo/argo-cd \
--namespace argocd \
--set server.extraArgs[0]="--insecure" \
--set configs.params."server\.timeout\.seconds"=300 \
--version 7.3.11 \
--wait
A common mistake in 2026 is leaving the Argo CD server exposed via LoadBalancer without TLS termination. Always place it behind an ingress controller with valid certificates. If you’re running on AWS EKS or similar managed services, integrate with OIDC for authentication rather than managing local admin passwords. For teams also automating infrastructure provisioning, combining this with Terraform for underlying platform resources ensures the cluster exists before Argo CD attempts to manage workloads.
Defining Your First Application CRD
Argo CD uses Custom Resources (Applications) to define what to sync. Never use the UI for production definitions; store these as YAML in your config repo so the tool manages itself:
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: production-api
namespace: argocd
spec:
project: default
source:
repoURL: 'https://github.com/your-org/k8s-manifests.git'
targetRevision: HEAD
path: apps/api/overlays/prod
kustomize:
images:
- api-server=v1.4.2
destination:
server: 'https://kubernetes.default.svc'
namespace: api-prod
syncPolicy:
automated:
prune: true
selfHeal: true
syncOptions:
- CreateNamespace=true
- PrunePropagationPolicy=foreground
This tells Argo CD to deploy manifests from the apps/api/overlays/prod path in your GitOps repository into the api-prod namespace. Key fields include:
- repoURL: The Git repository hosting desired state
- targetRevision: Which branch/tag to sync (HEAD means latest commit)
- path: Directory within the repo containing manifests
- kustomize.images: Overrides for container image tags at render time
Managing Secrets Securely in a GitOps Workflow
Storing plaintext secrets in Git violates every compliance framework from SOC 2 to ISO 27001. Argo CD supports several secure patterns, but the choice depends on your existing security posture and team maturity:
| Method | Security Level | Complexity | Best For |
|---|---|---|---|
| External Secrets Operator | High | Medium | Cloud-native teams using AWS/Azure/GCP secret managers |
| Sealed Secrets | Medium | Low | Small teams, no cloud KMS dependency |
| SOPS + Age/GPG | High | Medium | Multi-cloud, offline decryption capability needed |
| Vault Agent Injector | Highest | High | Enterprise, dynamic secrets, strict audit requirements |
In my experience helping fintech companies achieve compliance, External Secrets Operator (ESO) strikes the best balance. It creates native Kubernetes Secrets from external providers without storing sensitive data in etcd longer than necessary. You commit an ExternalSecret manifest to Git, and ESO fetches the value from AWS Secrets Manager or HashiCorp Vault at runtime. This keeps your Git history clean and your audit logs centralized in the secret provider. Teams transitioning from legacy setups should review secrets management fundamentals before integrating with Argo CD to avoid creating new leakage vectors.
How Argo CD Compares to Flux in 2026
Choosing between Argo CD and Flux is the most common question I field during architecture reviews. Both are CNCF graduated projects and fully capable, but they optimize for different operational models:
- Argo CD prioritizes visualization and multi-cluster management through a centralized UI, making it ideal for platform teams managing dozens of clusters for developers
- Flux v2 embraces a more modular, CLI-first philosophy with stronger multi-tenancy isolation via native Kubernetes namespaces and no mandatory central server
If your team struggles with debugging sync failures or needs non-engineers to view deployment status, Argo CD’s UI is a significant productivity multiplier. If you’re building a highly automated internal developer platform where GitOps is invisible plumbing and multi-tenancy boundaries must be cryptographically enforced, Flux’s smaller footprint and Kustomize-native approach may fit better.
Performance-wise, both handle thousands of applications, but Argo CD’s sharded controller architecture scales more predictably for massive mono-repo setups when properly tuned. Consider your team’s operational maturity: Argo CD lowers the cognitive load for newcomers, while Flux rewards deep Kubernetes expertise with greater flexibility.
Best Practices and Common Pitfalls in 2026
Repository Strategy: Separate repositories for application source code and environment configuration. Use umbrella Helm charts to manage shared dependencies and deployment structure. Update GitOps repositories from CI pipelines instead of direct cluster mutation—this maintains the separation between build artifacts and desired state declarations.
CI Integration Patterns: The unified deployment workflow typically follows:
- Application pipeline builds and pushes a container image
- Pipeline updates the image tag in a GitOps repository
- Argo CD detects the commit
- Argo CD syncs the application into the target cluster
A simplified CI job updates values.yaml with the current commit SHA and pushes back to the GitOps repo. Once the new tag is committed, Argo CD notices the change and updates Kubernetes so that the live environment matches Git.
Separation of Concerns: The approach I prefer builds around clear boundaries—CI owns building and recording desired versions; Argo CD owns synchronization into the cluster; Git remains the contract; automation becomes the operator.
Common Pitfalls to Avoid
- Leaving secrets in plain text or committing them directly into charts
- Using the web UI for production Application definitions instead of YAML manifests
- Exposing Argo CD API server without proper authentication and TLS termination
- Not enabling auto-sync policies properly, causing drift between Git and cluster state
- Overusing Helm templating when Kustomize would suffice—Go templates introduce complexity that may not pay off
Conclusion
Adopting GitOps principles and implementing Argo CD can unify Kubernetes delivery across many projects. Configuration drift becomes less of a problem because the live cluster state is continuously compared with the Git repository. Kubernetes already makes scaling and moving workloads easier; Argo CD adds a deployment model that makes those workloads easier to control.
The strongest results come when your team has a solid foundation in Kubernetes and a clear strategy for repositories, charts, access, and environments. Pairing a managed Kubernetes service with Argo CD can provide an automated path from code to production while reducing the daily effort spent on infrastructure management.
GitOps is not just a deployment tool choice—it’s a delivery model where Git becomes the contract, automation becomes the operator, and Argo CD keeps the cluster honest. In 2026, as organizations increasingly demand reliability, auditability, and self-healing at scale, this operational discipline provides measurable competitive advantages in speed to market, incident reduction, and team productivity.
FAQ
How does Argo CD differ from traditional CI/CD deployment tools like kubectl apply or Helm?
Argo CD uses a pull-based reconciliation model where the controller continuously compares Git definitions against cluster state, rather than relying on stored credentials to push artifacts during CI pipelines. This eliminates external systems needing write access to your production API server and reduces attack surface while automatically flagging drift immediately after manual edits.
What happens when someone manually modifies resources in an Argo CD-managed application?
The Application Controller detects changes within its default three-minute sync window and marks the application as “OutOfSync” until Git definitions are updated to reflect the desired state. This immediate feedback loop ensures teams can quickly identify unauthorized or accidental cluster modifications during production operations.
What advantages does Argo CD provide over Kustomize, Helm, and kubectl apply for Kubernetes deployments?
While each traditional method has merit—kubectl offers flexibility but lacks drift detection, Kustomize introduces patching complexity over time, and Helm adds templating overhead—Argo CD eliminates operational discipline issues by treating Git as the single source of truth. It provides continuous reconciliation without requiring teams to manually specify resources or maintain complex imperative scripts.
What are best practices for installing Argo CD in a production Kubernetes cluster?
Use the official Helm chart with high availability enabled rather than relying on kubectl apply, and create a dedicated namespace for isolation and RBAC scoping during installation. Avoid leaving insecure parameters enabled by default, as 2026 security standards expect properly hardened configurations from the start of your deployment process.
