# Core Components of Argo CD: Architecture and Source Code Breakdown

> Discover the core components of Argo CD: API Server, Application Controller, Repo Server, Redis, and Dex. Understand the architecture and source code behind this GitOps tool.

- Repository: [Argo Project/argo-cd](https://github.com/argoproj/argo-cd)
- Tags: architecture
- Published: 2026-07-09

---

**Argo CD consists of five fundamental microservices—the API Server, Application Controller, Repo Server, Redis cache, and an optional Dex OIDC provider—along with a React-based Web UI and CLI client, all orchestrated to provide declarative GitOps continuous delivery for Kubernetes.**

The open-source project **argoproj/argo-cd** implements a declarative, GitOps continuous delivery system for Kubernetes through a distributed architecture of specialized services. Understanding the **core components of Argo CD** is essential for operators who need to debug reconciliation failures, optimize sync performance, or extend the platform's capabilities. Each component runs as a separate container and communicates via gRPC/HTTPS, allowing independent scaling and high availability.

## The Five Core Microservices

### API Server (argocd-server)

The **API Server** (`argocd-server`) serves as the central control plane, exposing REST and GraphQL endpoints while hosting the static React web interface. According to the source code in [`cmd/argocd-server/commands/argocd_server.go`](https://github.com/argoproj/argo-cd/blob/main/cmd/argocd-server/commands/argocd_server.go), this component handles authentication, RBAC enforcement, and serves as the primary entry point for both the Web UI and CLI clients. The API Server stores Application custom resources in etcd and orchestrates requests between the other microservices.

### Application Controller (argocd-application-controller)

The **Application Controller**, implemented in [`controller/appcontroller.go`](https://github.com/argoproj/argo-cd/blob/main/controller/appcontroller.go), continuously monitors Application custom resources (CRs) to reconcile cluster state with desired Git state. This component performs the heavy lifting of comparing live Kubernetes resources against generated manifests, executing sync operations, and propagating health status back to the API Server. The controller operates on a pull-based model, watching for changes in both Git repositories and live cluster resources.

### Repo Server (argocd-repo-server)

The **Repo Server** (`argocd-repo-server`) functions as a specialized rendering engine, cloning Git repositories and executing manifest generation tools like Helm, Kustomize, and Jsonnet. As defined in [`cmd/argocd-repo-server/commands/argocd_repo_server.go`](https://github.com/argoproj/argo-cd/blob/main/cmd/argocd-repo-server/commands/argocd_repo_server.go), it maintains a local cache of rendered manifests to minimize redundant Git operations and reduce latency during reconciliation cycles. This separation of concerns allows the Application Controller to focus on state management while the Repo Server handles computationally expensive template rendering.

### Redis Cache

While not a custom microservice, **Redis** provides critical infrastructure for Argo CD, storing session tokens for authenticated users and caching rendered manifests from the Repo Server. The default Helm chart configures Redis as a dependency to ensure high-performance data access across the component stack. Without Redis, the Repo Server would regenerate manifests on every reconciliation cycle, significantly degrading performance.

### Dex (Optional OIDC Provider)

For installations requiring external identity providers, **Dex** (`argocd-dex`) supplies OpenID Connect authentication services. The implementation in [`cmd/argocd-dex/commands/argocd_dex.go`](https://github.com/argoproj/argo-cd/blob/main/cmd/argocd-dex/commands/argocd_dex.go) enables integration with enterprise SSO systems like Okta, Azure AD, and GitHub OAuth, delegating token validation to the API Server. When configured, Dex runs as a separate container that brokers authentication between the API Server and external IdPs.

## Supporting Components

### Notifications Engine

The **Notifications Engine** extends Argo CD's observability by sending status updates to external systems like Slack, Microsoft Teams, and email. Implemented in [`notifications/notifications.go`](https://github.com/argoproj/argo-cd/blob/main/notifications/notifications.go), this component watches Application events and evaluates triggers defined in ConfigMaps to route formatted alerts appropriately. The engine listens to controller events and forwards messages based on user-defined notification templates.

### Web UI (React)

The **Web UI** is a TypeScript/React single-page application located in [`ui/src/app/app.tsx`](https://github.com/argoproj/argo-cd/blob/main/ui/src/app/app.tsx). Compiled into static assets and served by the API Server, this interface provides visual management of Applications, real-time sync status monitoring, and diff visualization between Git and cluster states. The UI communicates exclusively with the API Server's GraphQL and REST endpoints.

### CLI (argocd)

The **Argo CD CLI** (`argocd`) provides a thin client interface for power users and CI/CD pipelines. Defined in [`cmd/argocd/commands/app.go`](https://github.com/argoproj/argo-cd/blob/main/cmd/argocd/commands/app.go), the CLI communicates exclusively with the API Server to perform operations like `app create`, `app sync`, and `app delete` without requiring direct Kubernetes API access. This design allows users to manage deployments from local machines or external automation systems.

## Component Interaction Flow

All services run as separate containers in a typical installation, with the official Helm chart deploying one pod per service. The interaction follows this sequence:

1. A user creates an `Application` CR via the UI, CLI, or Git commit.
2. The **API Server** validates the request, persists the CR to etcd, and returns a response.
3. The **Repo Server** fetches the target Git repository, renders the manifests using the appropriate tool (Helm, Kustomize, etc.), and caches the result.
4. The **Application Controller** watches the `Application` CR, pulls the rendered manifests from the Repo Server, computes the diff against the live cluster, and applies changes if configured for automated sync.
5. **Redis** speeds up repeat reads of the generated manifests and holds session tokens for the UI and CLI.
6. The **Notifications Engine** listens to controller events and forwards formatted messages to external systems when trigger conditions are met.

## Practical Implementation Examples

### Declaring an Application

The following YAML creates an Application resource that ties the components together:

```yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: guestbook
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/argoproj/argocd-example-apps
    targetRevision: HEAD
    path: guestbook
  destination:
    server: https://kubernetes.default.svc
    namespace: guestbook
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

```

When applied with `kubectl`, the API Server stores the object, triggering the Application Controller to request manifest generation from the Repo Server.

### Manual Sync via CLI

```bash

# Authenticate with the API Server

argocd login argocd.example.com --username admin --password $ARGOCD_PWD

# Trigger synchronization

argocd app sync guestbook

```

The CLI communicates with the API Server, which instructs the Application Controller to perform the sync using cached manifests from the Repo Server.

### Configuring Notifications

```yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-notifications-cm
  namespace: argocd
data:
  service.slack: |
    token: xoxb-...
    channel: "#argo-cd"
  trigger.on-sync-status-unknown: |
    - description: Application sync failed
      when: app.status.sync.status == 'Unknown'
      send: [slack]

```

The Notifications Engine monitors this ConfigMap and posts to Slack when the controller reports sync failures.

## Summary

- The **API Server** ([`cmd/argocd-server/commands/argocd_server.go`](https://github.com/argoproj/argo-cd/blob/main/cmd/argocd-server/commands/argocd_server.go)) provides the unified control plane for REST API, GraphQL, and Web UI traffic.
- The **Application Controller** ([`controller/appcontroller.go`](https://github.com/argoproj/argo-cd/blob/main/controller/appcontroller.go)) reconciles Application CRs and executes sync operations against the target cluster.
- The **Repo Server** ([`cmd/argocd-repo-server/commands/argocd_repo_server.go`](https://github.com/argoproj/argo-cd/blob/main/cmd/argocd-repo-server/commands/argocd_repo_server.go)) generates Kubernetes manifests from Git sources using Helm, Kustomize, and other tools.
- **Redis** caches session data and rendered manifests to optimize performance across the platform.
- The **Notifications Engine** ([`notifications/notifications.go`](https://github.com/argoproj/argo-cd/blob/main/notifications/notifications.go)) integrates with external messaging platforms for event-driven alerts.
- **Dex** ([`cmd/argocd-dex/commands/argocd_dex.go`](https://github.com/argoproj/argo-cd/blob/main/cmd/argocd-dex/commands/argocd_dex.go)) optionally provides OIDC authentication for enterprise SSO integration.
- The **Web UI** ([`ui/src/app/app.tsx`](https://github.com/argoproj/argo-cd/blob/main/ui/src/app/app.tsx)) and **CLI** ([`cmd/argocd/commands/app.go`](https://github.com/argoproj/argo-cd/blob/main/cmd/argocd/commands/app.go)) offer complementary interfaces for interactive and automated management.

## Frequently Asked Questions

### What is the difference between the Application Controller and the Repo Server?

The **Application Controller** manages the lifecycle of Application resources and applies changes to Kubernetes clusters, while the **Repo Server** exclusively handles Git operations and manifest generation. The Controller requests rendered manifests from the Repo Server via gRPC, then compares these against live cluster state to determine necessary changes.

### Is Redis required for Argo CD to function?

Yes, **Redis** is a required infrastructure component in standard Argo CD deployments. According to the default Helm chart configuration, Redis maintains the manifest cache to prevent redundant Git clones and stores session tokens for authenticated UI and CLI users. Without Redis, the Repo Server would regenerate manifests on every reconciliation cycle, significantly degrading performance.

### How does the Argo CD API Server handle authentication?

The **API Server** validates authentication tokens through multiple mechanisms: local accounts stored in Kubernetes secrets, external OIDC providers via **Dex** (configured in [`cmd/argocd-dex/commands/argocd_dex.go`](https://github.com/argoproj/argo-cd/blob/main/cmd/argocd-dex/commands/argocd_dex.go)), or direct webhook tokens. Once authenticated, the server enforces RBAC policies defined in the `argocd-rbac-cm` ConfigMap before processing requests.

### Can the Argo CD components run outside of Kubernetes?

While designed for Kubernetes deployment, the **CLI** can run on any machine with network access to the API Server. However, the core microservices—the **API Server**, **Application Controller**, and **Repo Server**—require Kubernetes API access and are typically deployed as pods within the cluster they manage or a dedicated management cluster.