Skip to main content
This document reviews Argo CD’s core components, how they run inside a Kubernetes cluster, and how they interact to deliver GitOps workflows. Argo CD components run as pods in the argocd namespace and provide the API surface, repository operations, reconciliation logic, authentication, caching, notifications, and observability.
  1. ArgoCD API server (argocd-server)
  • The argocd-server is the primary API endpoint (gRPC + REST) used by the Web UI, the CLI (argocd), and external CI/CD systems.
  • Key responsibilities:
    • Exposes application management APIs (create, update, delete).
    • Handles user operations such as sync, rollback, and health checks.
    • Manages credentials, enforces authentication and RBAC, and serves the Argo UI.
    • Exposes Prometheus-compatible metrics and health endpoints for scraping.
  1. Authentication and RBAC (Dex and external IdPs)
  • Argo CD can delegate authentication to external identity providers (Okta, GitHub, Google, etc.) using OpenID Connect (OIDC). Many deployments use Dex as an OIDC broker, although Argo CD also supports direct OIDC integration.
  • RBAC within Argo CD is enforced based on configured policies and the identities asserted by the identity provider.
Dex (https://dexidp.io) commonly acts as an OIDC broker between Argo CD and external identity providers. Configure your IdP in Argo CD (or via Dex) so Argo CD can consume issued tokens for authentication and RBAC decisions.
  1. Caching and persistence (Redis + Kubernetes API / etcd)
  • Redis is used as an in-memory cache for transient data: repository indexes, session storage, and short-lived caches to speed up operations.
  • All persistent configuration—application definitions, repo credentials, and plugin settings—are stored as Kubernetes objects (Secrets, ConfigMaps, CRs) persisted in etcd via the Kubernetes control plane. Redis failures do not cause permanent data loss because Argo CD can rebuild caches from Git and Kubernetes resources.
  1. Retrieve phase (argocd-repo-server)
  • The repo-server performs the “retrieve” stage:
    • Clones Git repositories, resolves templates, and renders final Kubernetes manifests.
    • Supports Helm, Kustomize, Jsonnet, plain YAML, and Config Management Plugins (CMP).
    • Caches generated manifests for consumption by the controller and UI.
  1. Reconcile phase (argocd-application-controller)
  • The application-controller is a Kubernetes controller that implements reconciliation:
    • Compares desired state (manifests from the repo-server) with the live cluster state.
    • Detects drift and applies changes according to configured sync policies (manual, automatic, hooks, pruning).
    • Manages sync waves, resource ordering, and finalizers when needed.
  1. Notifications (argocd-notifications)
  • The notifications controller watches application and cluster events, then dispatches alerts via configured channels:
    • Slack, email, webhooks, Teams, or custom providers.
    • Uses templates and triggers to customize when and how notifications are sent.
  1. Metrics and observability
  • Argo CD components expose Prometheus-compatible metrics on HTTP endpoints for monitoring:
    • argocd-server: API traffic, auth events.
    • repo-server: repo clone times, template rendering stats.
    • application-controller: reconciliation loop durations, sync counts.
    • notifications: delivery attempts and success/failure counts.
  • Use Prometheus ServiceMonitors to scrape these endpoints and visualize them with Grafana dashboards for cluster and application visibility.
A labeled architecture diagram of ArgoCD core components showing argocd-server, repo-server, dex, application-controller, redis, and notification controller. It illustrates user/CI access, authentication providers, metrics, notifications, and deployments to multiple Kubernetes clusters (dev, staging, prod).
Summary table: core components and responsibilities
ComponentPurposeNotable endpoints / notes
argocd-serverAPI surface, Web UI, authentication & RBACREST/gRPC API, UI, metrics endpoint
argocd-repo-serverRetrieves and renders manifestsGit clone, Helm/Kustomize/Jsonnet, CMP support
argocd-application-controllerReconciliation and drift correctionWatches Application CRs, applies syncs/prunes
RedisIn-memory cache and transient storageNot persistent for long-term config
Dex / OIDC IdPAuthentication broker / providerOIDC tokens for Argo CD users
argocd-notificationsEvent-driven notificationsSlack, email, webhooks; templated triggers
Prometheus / Grafana integrationObservability and dashboardsScrape metrics + visualize in Grafana
Links and references
Best practices:
  • Keep Argo CD configuration (Applications, Repo credentials) as Kubernetes objects committed and backed up.
  • Treat Redis as ephemeral: ensure persistent state is in Kubernetes resources and Git.
  • Scrape Argo CD metrics with Prometheus ServiceMonitors and add Grafana dashboards for visibility.

Watch Video