Bootstrapping Argo CD and Letting It Manage Itself

Argo CD has a chicken-and-egg problem on day one. The cluster has nothing in it, so kubectl is the only tool that can install the first thing. After that, you want Argo CD to manage itself the same way it manages everything else. The flow I use: 1. One bootstrap kubectl apply puts Argo CD into the cluster. I use the upstream install manifest pinned to a version, not latest. That gets you the namespace, the CRDs, the controller, the repo server, the API server. 2. Once Argo CD is up, I apply one Application CR by hand. This Application points at a directory in the manifests repo, something like argocd/bootstrap. That directory contains another Application that points at Argo CD's own Helm chart or Kustomize overlay. So Argo CD starts syncing itself. 3. The same bootstrap directory contains AppProjects, repository credentials (as sealed secrets or external secrets), and a parent Application that points at argocd/applications, which holds every other Application CR for the cluster. After that initial kubectl apply, you never touch Argo CD with kubectl again. Bumping the Argo CD version is a Git commit changing the chart version or image tag in argocd/bootstrap. Adding a new app to the cluster is a Git commit dropping a new Application YAML into argocd/applications. Repo layout I keep for this: argocd/ bootstrap/ # Argo CD itself, plus the root app-of-apps kustomization.yaml values.yaml # Helm values for the argo-cd chart root-app.yaml # the parent Application that points at applications/ projects/ # AppProjects: per-team or per-environment applications/ # one Application YAML per workload or per env One gotcha. Argo CD syncing itself can lock you out if a bad change rolls in. If the controller fails to start because of a config change you just merged, no controller means no reconcile, which means no rollback through Git. Keep the bootstrap Application on manual sync, or at minimum keep a tested rollback commit ready. Some teams keep a separate management cluster running its own Argo CD that watches the workload clusters' Argo CDs, so a broken self-managed instance can still be repaired through GitOps.