How to Install Argo CD: A Complete Guide to Kubernetes Deployment

Argo CD is installed by applying the official Kubernetes manifests using server-side apply with --force-conflicts, which creates all required resources including CRDs, Deployments, and RBAC in the argocd namespace.

Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes that automates application deployment and lifecycle management. Installing it requires applying the official manifest files from the argoproj/argo-cd repository to your cluster. This guide covers the standard installation process, alternative deployment options, and initial configuration steps based on the source code and documentation.

Standard Installation Method

The standard installation deploys all Argo CD components including the API server, repository server, application controller, and Redis to a dedicated namespace. According to the argoproj/argo-cd source code, this method uses server-side apply to avoid client-side annotation limits and safely manage resource ownership.

Prerequisites

Before installing, ensure you have:

• A running Kubernetes cluster (version 1.25 or later)
• kubectl configured to communicate with your cluster
• Cluster-admin privileges to create namespaces and CRDs

Install Using the Official Manifest

Execute the following commands to install Argo CD:

kubectl create namespace argocd
kubectl apply -n argocd \
  --server-side --force-conflicts \
  -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

The install.yaml file located in manifests/install.yaml contains the complete set of Custom Resource Definitions (CRDs) and component Deployments, including argocd-server, argocd-repo-server, argocd-application-controller, and supporting services.

Alternative Installation Options

Depending on your environment, you may prefer a minimal installation or specific version pinning.

Core Components Only (No UI/SSO)

For automation-focused workflows that do not require the web UI or SSO capabilities, use the core installation:

kubectl apply -n argocd \
  --server-side --force-conflicts \
  -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/core-install.yaml

The manifests/core-install.yaml file deploys only the essential control plane components without the API server UI or Dex server, as documented in docs/operator-manual/core.md.

Pinning a Specific Version

For production stability, replace stable with a concrete release tag such as v3.2.0:

kubectl apply -n argocd \
  --server-side --force-conflicts \
  -f https://raw.githubusercontent.com/argoproj/argo-cd/v3.2.0/manifests/install.yaml

This ensures reproducible deployments and prevents unexpected upgrades when the stable branch updates.

Accessing the Argo CD UI

After installation, you must expose the argocd-server service and retrieve credentials to access the web interface or CLI.

Exposing the Argo CD Server

Choose one of these methods based on your infrastructure:

• LoadBalancer: Quickly expose via cloud provider load balancer
• Ingress: Production-ready exposure with TLS termination (see docs/operator-manual/ingress.md)
• Port-forwarding: Local development access

For LoadBalancer exposure:

kubectl patch svc argocd-server -n argocd \
  -p '{"spec": {"type": "LoadBalancer"}}'

Retrieving the Initial Admin Password

The installation generates an initial password stored in the argocd-initial-admin-secret:

PASSWORD=$(kubectl -n argocd get secret argocd-initial-admin-secret \
  -o jsonpath="{.data.password}" | base64 -d)
echo "Initial admin password: $PASSWORD"

Log in using the CLI:

argocd login <ARGOCD_SERVER> --username admin --password $PASSWORD

Summary

• Apply the official manifest using server-side apply with --force-conflicts to install Argo CD in the argocd namespace
• Choose between standard and core installation based on whether you need the web UI and SSO capabilities
• Pin specific versions by replacing stable with release tags like v3.2.0 for production stability
• Expose the server via LoadBalancer, Ingress, or port-forwarding depending on your environment
• Retrieve credentials from the argocd-initial-admin-secret before accessing the UI or CLI

Frequently Asked Questions

What is the difference between install.yaml and core-install.yaml?

The install.yaml contains the full Argo CD installation including the web UI, SSO integration via Dex, and all supporting components, while core-install.yaml deploys only the essential control plane components without the UI or SSO server, suitable for GitOps automation workflows that rely solely on the CLI or API.

Why use server-side apply with --force-conflicts?

Server-side apply with --force-conflicts prevents client-side field manager annotation limits and ensures Argo CD can safely take ownership of resources during installation, avoiding errors when applying large manifests or upgrading existing installations.

How do I upgrade Argo CD to a newer version?

To upgrade, apply the new version's manifest using the same server-side apply command with --force-conflicts, optionally pin to a specific version tag instead of stable, and review the upstream changelog in docs/getting_started.md for any breaking changes in CRD versions or configuration requirements.

Can I install Argo CD in a namespace other than argocd?

Yes, you can install Argo CD in any namespace by creating that namespace and applying the manifests to it, though you must ensure the --namespace or -n flag matches your target namespace, and update any namespace references in the manifests if performing a custom installation.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}