ArgoCD: GitOps for Kubernetes

By Khimananda Oli | Last reviewed: August 2026

Managing Kubernetes manifests manually or via imperative CI scripts creates drift, audit gaps, and fragile deployments that fail under pressure. ArgoCD: 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 ArgoCD: GitOps for Kubernetes and how does it work?

At its core, ArgoCD is a controller that runs inside your Kubernetes cluster. Unlike traditional CI/CD tools that push artifacts to the cluster using stored credentials, ArgoCD 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. For teams exploring declarative Kubernetes deployments, understanding this distinction is critical because it changes how you structure both your repository and your release process.

The reconciliation loop operates on three distinct phases. First, the Repo Server clones your Git repository and renders manifests (supporting raw YAML, Helm, Kustomize, or Jsonnet). Second, the Application Controller compares the desired state from Git against the live state in the cluster. Third, 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, meaning manual edits to the cluster are flagged as "OutOfSync" almost immediately.

How do you install and configure ArgoCD for production?

While `kubectl apply` works for testing, production environments require a managed installation via Helm or the ArgoCD Operator to handle upgrades, HA configurations, and custom values cleanly. I recommend the official Helm chart because it exposes every configurable parameter without forcing you to maintain forked manifests.

Step-by-step Helm installation

1. Add the ArgoCD Helm repository and update your local cache.
2. Create a dedicated namespace for isolation and RBAC scoping.
3. Install with high availability enabled for the application controller and server.
4. Configure ingress or service exposure based on your networking stack.

helm repo add argo https://argoproj.github.io/argo-helm
helm repo update

kubectl create namespace argocd

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 ArgoCD server exposed via LoadBalancer without TLS termination. Always place it behind an ingress controller with valid certificates. If you are 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 ArgoCD attempts to manage workloads.

Defining your first Application CRD

ArgoCD uses Custom Resources 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

How do you manage secrets securely in an ArgoCD GitOps workflow?

Storing plaintext secrets in Git violates every compliance framework from SOC 2 to ISO 27001. ArgoCD supports several secure patterns, but the choice depends on your existing security posture and team maturity. The goal is to keep encrypted references in Git while resolving actual values only at render time inside the cluster.

In my experience helping Nepali 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 ArgoCD to avoid creating new leakage vectors.

How does ArgoCD compare to Flux and other GitOps tools in 2026?

Choosing between ArgoCD 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. ArgoCD 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, ArgoCD’s UI is a significant productivity multiplier. If you are 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 ArgoCD’s sharded controller architecture scales more predictably for massive mono-repo setups when properly tuned. Consider your team's operational maturity: ArgoCD lowers the cognitive load for newcomers, while Flux rewards deep Kubernetes expertise with greater flexibility.

How do you implement multi-cluster and progressive delivery with ArgoCD?

Scaling beyond a single cluster requires the ApplicationSet controller, which generates ArgoCD Applications dynamically based on generators like Git directories, cluster labels, or matrix combinations. This eliminates copy-pasting manifests for staging, production, and DR regions. Pair this with Argo Rollouts for progressive delivery strategies that actually respect your error budgets.

ApplicationSet for fleet management

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: regional-api
  namespace: argocd
spec:
  generators:
    - clusters:
        selector:
          matchLabels:
            app.kubernetes.io/part-of: api-platform
  template:
    metadata:
      name: '{{name}}-api'
    spec:
      project: platform
      source:
        repoURL: 'https://github.com/your-org/k8s-manifests.git'
        targetRevision: main
        path: apps/api/overlays/{{metadata.labels.region}}
      destination:
        server: '{{server}}'
        namespace: api
      syncPolicy:
        automated:
          prune: true
          selfHeal: true

For progressive delivery, integrate Argo Rollouts to enable canary or blue-green deployments directly within your GitOps flow. The rollout controller analyzes metrics from Prometheus or Datadog during deployment and automatically promotes or rolls back based on SLO thresholds. This closes the loop between deployment and observability, preventing bad releases from impacting users even when auto-sync is enabled. Teams adopting this pattern should also explore advanced rollout strategies to fine-tune analysis intervals and step weights for their specific traffic patterns.

Implementing ArgoCD: GitOps for Kubernetes for long-term reliability

Adopting ArgoCD is not just a tooling change; it is an operational discipline that demands rigorous Git hygiene, clear ownership of manifest paths, and disciplined exception handling for out-of-band changes. Start with non-production clusters to build muscle memory around sync waves, hooks, and health checks before touching production. Invest early in RBAC policies that map to your team structure, and never grant blanket admin access to the ArgoCD API. Monitor ArgoCD itself as a tier-zero service: alert on sync failures, controller queue depth, and repo server latency. When implemented correctly, ArgoCD: GitOps for Kubernetes transforms deployment from a stressful event into a boring, predictable background process that lets your engineering team focus on delivering value instead of babysitting pipelines. If you need help designing a GitOps strategy tailored to your infrastructure constraints or compliance requirements, reach out to discuss your specific architecture.