Why teams manage Argo CD with Argo CD
Platform teams that change Argo CD by hand end up with a controller whose live settings no longer match Git, and nobody can say who changed what or when. Self-management means defining an Application for Argo CD itself, with its configuration held in Git and synced like any other workload. Once that is in place, a change to the Argo CD installation becomes a reviewed commit, and the same audit trail that covers application releases also covers the delivery tool.
The declarative setup guide describes the pattern in concrete parts: a Kustomize application built over the base manifests, cluster and repository secrets added as resources, and an Application that points at this configuration with automated sync and the ServerSideApply=true sync option, which the guide states is required. Changes go through patches in the overlay rather than live edits to the running objects. Teams should confirm the exact sync options against the version they run, since the guide is the authority for each release. This pattern fits best when one platform team owns the cluster that hosts Argo CD and wants its own configuration reviewed the same way as application changes. It is less suited to a single cluster with no review process, where the added moving parts may not pay off.
Argo CD is licensed under Apache-2.0 and the project does not offer a paid edition, so the self-management pattern carries no license decision of its own. The costs are engineering time to build and maintain the overlay, and the operational discipline to keep secrets out of plain Git history. Before adopting it, ask your team to confirm how the bootstrap install will be recovered if the controller cannot sync itself, and who holds the credentials that break the loop.
What belongs in Git and what stays out
Argo CD's own configuration can be managed as code, but not everything in its namespace belongs in Git. The cards below separate the manifests, patches and definitions that should be versioned from the credentials and runtime state that must be protected or left out. Settle these boundaries before the first sync, because they decide how recovery and access reviews work later.
Base manifests and kustomization
The base manifests for Argo CD and the kustomization.yaml that references them are the foundation of the self-managed setup. Pin the upstream version in the base reference so an upgrade is a reviewed commit rather than a silent change. Confirm which release you are pinning against the release cadence and the patch support window before you commit. Keep the upstream files unmodified and put every local change in an overlay or patch.
Patches for argocd-cm and argocd-rbac-cm
Settings such as the Argo CD URL, resource tracking, SSO configuration and RBAC policy live in ConfigMaps. Change them through patches in the kustomization, not through live edits with kubectl, so every setting has a commit, an author and a review. Because RBAC policy changes who can sync and delete, treat patches to argocd-rbac-cm as access changes that need the same approval as code changes to production.
Repository definitions as Secrets
Since Argo CD 3.0, repositories must be defined as Kubernetes Secrets, not in the argocd-cm ConfigMap. The Secret manifest belongs in the repository only in encrypted or referenced form, because it contains the repository URL and credentials. Check every existing repository entry during migration, since a ConfigMap entry left in place will not be used after the upgrade.
Cluster Secrets and destination credentials
Each registered cluster is stored as a Secret that holds the API server address and the credentials Argo CD uses to deploy there. These are among the most sensitive objects in the installation, since they grant deployment rights in the target cluster. Decide whether cluster Secrets are generated by a tool at bootstrap, managed by your cluster provisioning process, or stored encrypted in Git, and confirm that choice with your security team before the first commit.
Encrypted or externally sourced secrets
Any credential that must exist in the repository needs an approach your team chooses and confirms, such as encrypting the value before commit or keeping only a reference that an external secrets operator resolves at runtime. Plain Base64 is encoding, not protection. Ask who holds the decryption keys, how key rotation works, and whether a leaked key invalidates the encrypted history.
Runtime state that stays out of Git
Redis contents, generated Application status, admin passwords and sessions, and the controller's live cache are runtime state, not configuration. Argo CD keeps its data in Kubernetes objects and treats Redis as a disposable cache, so these items should be regenerated, not committed. Exclude them from the repository and document what a restore must recreate, including the admin account and SSO settings, before you rely on Git as your recovery source.
Configuration choices and when each fits
This table compares four ways to put Argo CD's own installation under GitOps, with the fit, the added difficulty and the checks each option needs. Read each row as a decision: the first column names the option, and the cells show when it suits your team and what you must confirm before choosing it. Automated sync with pruning and self-heal appear at the end because they change what Argo CD may delete or revert on its own.
| Option | When it fits | What it makes harder, and what to confirm |
|---|---|---|
| Kustomize application over base manifests with patches | Teams that want the upstream install unchanged and all local settings kept as patches in Git | Patches must be rechecked on every version bump. Confirm the Argo CD version you pin and that each patch still matches the base. |
| Helm-based install managed by Argo CD | Teams that already manage cluster add-ons through Helm and want values files reviewed in Git | Chart and Argo CD versions must be kept aligned. Confirm which chart version maps to your target Argo CD release and how CRDs are handled. |
| Separate bootstrap installer outside Argo CD | Teams that need a known-good install path to rebuild Argo CD when the cluster or its Argo CD instance is lost | Two control points exist, so changes can drift between them. Confirm who owns the bootstrap path and how it is tested during recovery. |
| Plain-manifest self-application without patches | Small, short-lived or lab environments where the team accepts the upstream defaults as they are | Local settings such as repositories and clusters must be edited in place, which weakens review. Confirm that secrets are not stored in plain form in Git. |
| Automated sync with pruning | Environments where Git is the only accepted source of change and stale resources must be removed | Pruning can delete resources that were created outside Git. Confirm the resource list Argo CD may remove before enabling it on its own Application. |
| Self-heal | Environments where manual live edits to Argo CD's configuration must be reverted automatically | Emergency fixes made directly in the cluster will be overwritten. Confirm the break-glass path and who may apply it before enabling self-heal. |
How to bootstrap Argo CD under its own GitOps control
The sequence moves Argo CD's own installation, cluster registrations and repository credentials into Git so that later configuration changes are made by commit rather than by live edits. Each step ends with a check you can run before moving to the next.
Create the Git layout for the installation
Your platform team creates a repository or directory dedicated to the Argo CD installation, with a base folder that holds the chosen upstream manifests or Helm output and an overlay folder that holds your patches, namespace settings and Secret definitions. Keep this layout separate from application manifests so that changes to Argo CD itself go through their own review. The step is done when the folders are committed to the default branch and a reviewer can trace every file to either the base or an overlay patch. Confirm the base version you pin matches the release you plan to run, since the upgrade notes for each minor version affect what goes in the patches.
Install Argo CD once from the chosen base
Someone with cluster-admin rights applies the Kustomize overlay directly with kubectl, one time, to create the Argo CD namespace, Deployments, CRDs and RBAC. This bootstrap is the only intended live apply of the installation. Use the same ServerSideApply behavior you will later declare in Git so the first install and the managed sync do not fight over field ownership. The check is that all Argo CD pods reach Running and the admin login works or the CLI can reach the API server. Record the exact commit that was applied so the bootstrap can be reproduced if the cluster is rebuilt.
Add the self-management Application
Create an Application resource that points at the overlay folder in Git, targets the cluster and namespace where Argo CD runs, and enables automated sync with the sync option ServerSideApply=true. Argo CD's declarative setup guide describes this as the required option for managing its own installation. Apply this Application once with kubectl, then commit it to the same Git layout so it is also tracked by Git. The check is that the Application appears in the UI or CLI and reports the expected target revision, and that its sync status shows the commit you expect. Do not edit the Application in the cluster afterward; change it in Git.
Add cluster and repository Secrets as resources
Add the Kubernetes Secrets that register destination clusters and Git or Helm repositories to the overlay, using the label conventions Argo CD expects for each type. Since Argo CD 3.0, repositories are defined as Secrets rather than in the argocd-cm ConfigMap, so this step replaces any earlier ConfigMap entries. Keep credential values out of plain Git by using a secret manager or encryption approach your team has agreed on; the secrets management topic covers the options. The check is that Argo CD lists each cluster and repository as connected, and that the Application now includes these resources in its tree without reporting them as orphaned.
Verify Synced and Healthy status
Open the self-management Application and confirm its sync status is Synced and its health is Healthy, with the revision matching the commit at the head of the overlay branch. Compare the live Deployments and ConfigMaps against the Git manifests, looking for drift that would show a leftover manual change from the bootstrap. Check that the admin account is still the only way in, since the user management guidance recommends disabling admin once SSO or local users are configured. If the status is OutOfSync after the first sync, identify which resource differs before making any further change, because a silent mismatch here will undermine every later step.
Roll out a patch change through Git
Make a small, reversible change to Argo CD's configuration as a patch in the overlay, such as a label or a non-disruptive setting in argocd-cm, then commit and push it to the branch the Application tracks. Do not run kubectl edit or the UI to make the change. Watch the Application until it moves to a new revision, shows Synced, and the live ConfigMap or Deployment reflects the patch. The step is complete when the change is visible in the live resource and the Git history records the author and reason. Keep this patch as a standing test for future upgrades, and roll it back through another commit so the rollback is also recorded.
Why ServerSideApply=true is required for self-management
The declarative setup guide makes ServerSideApply=true a required sync option for an Application that manages Argo CD itself, so treat it as part of the pattern rather than an optional tuning setting. Without it, the Application that owns Argo CD's own manifests can disagree with the live objects in ways that are hard to diagnose later. The guide's approach is to define an Application for Argo CD with automated sync and this option set in its syncOptions, then change configuration through patches. Confirm the exact field path and option spelling against the version you run before you copy it into your repository.
With client-side apply, Argo CD writes the fields it finds in Git and records them in the last-applied-configuration annotation, which makes it compare against that stored copy. Server-side apply moves the work to the API server. Each field is tracked by a named field manager, and the server records which manager owns which field. That ownership matters for Argo CD's own objects, such as the argocd-cm and argocd-rbac-cm ConfigMaps, the Deployments and the controller's CRDs, because other controllers, operators or a manual kubectl edit may also set fields on them. Conflicts surface as explicit errors instead of silent overwrites, so a sync can stop where you need to decide who owns a field. Plan that decision before go-live: which fields Argo CD owns, and which, if any, another controller owns.
Test the option on a non-production cluster first. Run a self-management sync, change one value through a patch, and check that the result, the ownership reported on the live objects and any conflict messages match what you expect. Also check that a restart of the Argo CD components does not cause a loop of drift and sync. Confirm the behavior against the Argo CD version you plan to run, because upgrade notes and defaults change between releases, and reconfirm the setting after each upgrade.
Questions teams ask before self-managing Argo CD
What does it cost to manage Argo CD with Argo CD, and who pays for each part?
The software itself has no license fee, since Argo CD is released under the Apache License 2.0 and the project offers no paid edition. The cost is labor and infrastructure. Your platform engineers spend time writing the Kustomize overlay, moving cluster and repository secrets into Git-managed resources, and testing the bootstrap. Cloud or cluster capacity for the Argo CD pods is a recurring cost, and it grows if you run HA with at least three nodes. Recurring labor covers upgrades: the project supports only the three most recent minor versions with patch releases, so you will upgrade about every three months to stay supported. If you buy an implementation, the fixed-scope quote should itemize design, build, testing and handover. Ask what is one-time and what is retainer work.
How long does a first self-managed Argo CD setup take?
The duration depends mostly on how mature your GitOps practice already is. A team that already keeps cluster configuration in Git, runs a secret tool that fits Kubernetes, and has a tested bootstrap method will move much faster than a team that manages Argo CD by hand with kubectl. The main work items are the Kustomize base and patches, the cluster and repository secrets, the Application that manages Argo CD itself, and a test of rebuilding the installation from scratch. Ask any vendor or internal lead to break the estimate into those items and to name the assumptions behind each one, including how many clusters and repositories are in scope.
What must our team provide before the work starts?
Three groups of inputs are needed before the first commit. First, cluster access: an account with rights to install the Argo CD resources and to create the self-management Application on the cluster that will host it. Second, Git hosting: a repository your organization controls where the Kustomize base, overlays and secret definitions will live, along with branch protection and a credential Argo CD can use. Third, secret tooling: a method for keeping secret values out of plain Git, such as an encryption or external secret operator that your team already runs. Also provide a named owner for Argo CD upgrades and a decision on who may sync or override the self-managed Application.
Can an internal platform team do this alone?
Often yes, if the team already knows Kubernetes, Kustomize and Git-based delivery, and has at least one person who can own the bootstrap procedure. The harder part is not the first install but the recurring discipline: every configuration change goes through a patch and a pull request, upgrades are planned against the release cadence, and a recovery path is tested before it is needed. A small team usually struggles to find time for that testing. Consider an external review or a fixed-scope build if no one on the team has repeated a full cluster rebuild from Git. DeployOpen implements, hardens, documents and supports self-hosted platforms in your own infrastructure, and it can build the bootstrap with your team so the knowledge stays in-house.
What happens if the self-managed Argo CD Application breaks?
A broken self-managed Application can stop Argo CD from applying changes to itself, so the first safeguard is to keep a working path outside Argo CD. Keep the bootstrap instructions, the Kustomize base and the secret sources in Git, and make sure someone can apply the base manifests directly with kubectl if the controller is unavailable. Avoid live edits to the running Argo CD resources, because the next sync may revert them, and make changes through patches instead. Test the rollback on a non-production cluster first, especially for upgrades that change the RBAC or sync behavior. Argo CD is largely stateless and keeps its data in Kubernetes objects, so recovery is usually a reinstall from Git, provided the secrets and the Git repositories remain available.
How does self-managing Argo CD affect our security controls?
It changes who can alter the delivery path, so the Argo CD installation becomes a high-value asset. Argo CD authenticates API requests with JSON Web Tokens, uses TLS for traffic between its components, and redacts credentials from API responses and logs. The repo-server runs Helm and Kustomize on repository content, so the repositories that feed the self-managed Application must be trusted and access-controlled. Admin access should be turned off once SSO or local users are configured, which the user management guidance recommends. Review who can merge to the Argo CD configuration repository, because a change there can alter RBAC and cluster access. Consider this in your threat model before you grant the Application broad cluster rights.
What changes when Argo CD upgrades are managed through Git?
Upgrades become pull requests against the Argo CD manifests rather than manual kubectl steps. You still need to read the upgrade notes for each minor version, because some changes affect behavior your applications depend on. For example, the 2.14 to 3.0 notes changed how update and delete RBAC applies, required an explicit logs permission, made annotation-based resource tracking the default, and moved repository definitions into Kubernetes Secrets. Plan a test cluster to run the new version and a documented rollback. Since the project's patch releases cover only the three most recent minor versions, schedule upgrades as recurring work, not as a one-off project.
Security risks of a self-managed Argo CD
When Argo CD manages its own installation, the same tool that deploys your workloads also holds the settings that decide who can deploy them. The cards below cover the places where that loop creates risk, from the admin account and repository write access to repo-server exposure and credential handling. Each one names a check to run before you rely on the setup.
The built-in admin account
Argo CD ships with a built-in admin user intended for initial setup. The user management documentation recommends disabling it by setting admin.enabled to false once local users or SSO are configured. For a self-managed installation, confirm that the setting is stored in the Git-managed configuration, not changed by hand in the cluster, and that someone on the team knows the recovery path before disabling it. Disable the admin account once SSO works.
Write access to Argo CD's own configuration
The Application that manages Argo CD reads its RBAC, projects and repository definitions from Git. Anyone who can merge a change to that repository can therefore alter who may sync, which clusters are reachable and which repositories are trusted. Treat this repository as the most sensitive one in your organization. Ask whether branch protection, required reviews and restricted merge rights are enforced by your Git host, and who approves changes to the RBAC and project files.
Repo-server exposure to untrusted content
The repo-server runs Helm and Kustomize against repository content. The security documentation identifies untrusted repositories and out-of-tree file access as risks to control. In a self-managed setup, list every repository the Argo CD instance can read, confirm that each one is owned by your organization, and check whether any Helm chart or Kustomize build reaches files outside its own directory. Restricting which repositories a project may use is a team decision to document.
JWT-only API authentication
The security documentation states that Argo CD authenticates API requests only with JSON Web Tokens. Scripts, CI jobs and the CLI all depend on tokens, so token issuance and revocation become part of your access process. Confirm which automation accounts hold tokens, how long they remain valid, and how a leaked token would be detected and replaced. Document this as part of the access review for the Argo CD instance itself.
Credential redaction in responses and logs
Argo CD redacts cluster, Git and OAuth2 credentials from API responses and logs, according to the security documentation. Redaction does not replace secure storage. The Secrets that hold repository and cluster credentials still live in the cluster and in Git if you store them as resources, so check who can read those Secrets with kubectl and whether your log pipeline retains anything Argo CD writes. Confirm that encryption at rest for etcd is in place for your distribution.
Recovering when the controller that manages itself is down
When Argo CD manages its own installation, a broken self-management Application can stop the very controller that would repair it. If a bad patch removes a ConfigMap key, a sync wave fails on a CRD, or the repo-server can no longer reach Git, the normal path of editing the repository and waiting for a sync is unavailable. Plan for this before it happens: the team needs a documented break-glass method that does not depend on Argo CD being healthy, and it needs to know which objects are the source of truth when that method is used.
The break-glass method usually means applying the last known good manifests directly with kubectl against the destination cluster, under an identity your cluster administrators control and audit. Keep the repository, the Application that points at it, and the Kustomize overlay under version control so you can identify the exact commit that was last healthy. Back up the Git repository itself, not only a mirror that depends on the same host, and back up the Secrets that Argo CD needs to start: the repository credential Secrets, cluster Secrets, and the admin or SSO-related configuration in argocd-secret. Confirm how your organization stores those backups, who can read them, and how they are restored into a cluster that has no running Argo CD. Also confirm with your platform team which items in that set are encrypted at rest and which are kept outside Git on purpose.
Write the procedure down, then rehearse it on a non-production cluster with the same overlay, Secret layout and SSO setup. The rehearsal should answer concrete questions: who can run the break-glass steps, whether the admin.enabled setting and local accounts still work when SSO is the normal path, how long the team needs to restore access under its own change process, and which step has never been tested. The Argo CD high availability documentation covers how Argo CD components are stateless and Redis is disposable, which narrows what must be restored. Record the outcome of each rehearsal and treat any undocumented step as a gap to close before the next upgrade.
Upgrading a self-managed Argo CD safely
An Argo CD that manages itself is upgraded the same way as any other workload: a reviewed change to the version pin in Git, synced by Argo CD. The cards below cover what to read before the change, how the release cadence sets your planning rhythm, and how to rehearse the upgrade before production.
Change the version pin in Git
In a Kustomize setup, the Argo CD version lives in the remote base reference in your kustomization file, so the upgrade is a one-line change to that pin. Open it as a pull request, let a reviewer confirm the new tag, and merge it. Argo CD then reconciles its own installation from the commit. Avoid editing the live Deployment with kubectl, because the next sync will revert the change or leave the cluster in a state Git does not describe.
Read the 2.14 to 3.0 upgrade notes
Any move across the 2.14 to 3.0 boundary changes behavior you may depend on. Update and delete RBAC now apply only to the application itself, logs access needs an explicit logs, get permission, and annotation-based resource tracking is the default. Repository definitions must be Kubernetes Secrets, and Dex RBAC keys on the federated_claims.user_id claim. Check each of these against your own configuration before you change the pin.
Plan around the release cadence
A minor release ships four times a year, once every three months, and only the three most recent minor versions receive patch releases. A minor version therefore has a limited patch window before you must move. Set a recurring review date for the pin so you are not forced into an emergency jump, and track the GitHub releases page for patch notes that apply to your running version.
Confirm the patch line you run
Patch releases are published per supported minor line, so a patch can land for a version you no longer run. Confirm which minor version is current and which patch is latest before you plan a window. Compare your pin against the latest patch on that line and treat a missing patch as a finding to schedule, not an assumption that nothing changed.
Rehearse on a non-production cluster
Apply the same commit to a non-production cluster that runs the same Argo CD configuration, SSO settings and registered applications as production. Confirm that sync completes, that applications still show Synced and Healthy, that SSO logins and RBAC behave as expected, and that the admin account remains disabled. Record what you verified so the production change has a repeatable checklist.
Schedule a window and a rollback path
Choose a maintenance window that covers the sync of Argo CD itself, because a failed upgrade can block the controller that would fix it. Confirm who can reach the cluster directly, and keep a way to revert the pin in Git. Ask your team to confirm how Argo CD state is backed up before the change, since the controller and repo-server are designed to be largely stateless and cluster objects hold the data.
How DeployOpen scopes this self-management work
DeployOpen scopes self-management of Argo CD as a fixed piece of work agreed in writing before any cluster is touched. The scope starts with the repository layout: a Kustomize tree with a base that holds the Argo CD manifests, an overlay per cluster, and separate paths for cluster and repository secrets. It then defines the bootstrap sequence, including the Application that manages Argo CD itself with automated sync and ServerSideApply=true, and the verification steps that prove the first sync reconciles cleanly. Your team should decide early who owns the Git repository holding that tree, who may merge to it, and which cluster is the bootstrap cluster. Those answers shape the statement of work more than any technical detail.
The secrets approach is the decision most often left vague, so it is written into the scope explicitly. Cluster credentials and repository credentials are defined as Kubernetes Secrets, because Argo CD 3.0 no longer reads repository definitions from the argocd-cm ConfigMap. Each secret must reach Git in encrypted form or be supplied by an external mechanism, and the scope names which one your organization has approved. DeployOpen also writes down the verification plan: how a change to a patch is previewed, how a failed self-sync is rolled back, and how the admin user is disabled with admin.enabled set to false once SSO is working. Ask for each of these to appear as a numbered deliverable with an acceptance check, so that the quote can be compared with your own estimate line by line.
Implementation happens inside your clusters, using your Git hosting, your identity provider and your change process. DeployOpen documents the layout, bootstrap steps, recovery procedure and operator runbook so that your team can maintain them without us. Upgrades are a recurring cost that the fixed scope does not cover on its own. Optional retainers can cover patch and minor upgrades, support requests and periodic review of the repository. Before signing, confirm which Argo CD minor versions your organization will track, since the project publishes patch releases only for its three most recent minor versions, and ask the quote to separate one-time build effort from any retainer. DeployOpen does not issue certifications or attestations for this work; the evidence it produces is input for your own assessors.
