How Argo CD keeps Kubernetes clusters in line with Git
Teams that deploy by hand, or through pipelines that run kubectl or Helm against each cluster, usually meet the same two problems over time. The live cluster drifts from what the repository says, because someone patched a Deployment during an incident or a job failed halfway through. Every pipeline also needs credentials that can write to production clusters, so the number of places that can change a cluster grows with the number of pipelines. Argo CD reverses the direction of control. A controller inside the cluster pulls the desired state from Git and compares it with what is actually running, so the cluster is always measured against the repository.
Argo CD is an open-source continuous delivery tool released under the Apache License 2.0 and maintained within the Argo project. The project itself offers no paid edition, so the software carries no license fee, but the cost of designing, running and supporting it remains. The Cloud Native Computing Foundation accepted Argo at the Incubating level on March 26, 2020 and moved it to Graduated on December 6, 2022. In operation, each Application object names a Git repository, a path, a revision, a destination cluster and a namespace. The application controller renders the manifests, compares them with live objects and reports whether each application is in sync. Whether it applies differences automatically or waits for a person is a sync policy decision that should be made per application and per environment before go-live.
The supported approach runs Argo CD in the cluster and configures it through Kubernetes objects: Application and AppProject resources, plus the ConfigMaps and Secrets that hold its settings. Users sign in either through the bundled Dex identity service, which offers connectors such as SAML, LDAP and GitHub, or directly through an existing OIDC provider such as Okta, Auth0, Microsoft, Keycloak or Google Workspace. Choose the identity source before the build starts, because it determines the RBAC claims and the configuration. Confirm the Argo CD version line you will run against the current upgrade notes, since the 3.0 release moved repository definitions into Kubernetes Secrets and changed the Dex RBAC claim. Also confirm the patch support window for that line, because the project patches only its three most recent minor versions.
DeployOpen plans the Git repository layout, the Argo CD installation for your clusters, the AppProject boundaries that decide which teams can deploy where, the sync policies and the identity integration. It then builds the installation in infrastructure you control, configures SSO and RBAC, disables the built-in admin account with admin.enabled set to false once SSO is working, and hands over the configuration as code in Git, with runbooks and a documented upgrade path. You provide the clusters, the Git hosting, the identity provider and the decisions on who may approve a sync to production. High availability, repository credentials and the risks of untrusted Helm and Kustomize content are covered in their own sections, and they should be settled before any production application is connected.
Argo CD prerequisites to confirm before the build
Argo CD depends on decisions made outside its own namespace: the cluster it runs on, the clusters it deploys to, where Git content lives, who signs in and which release you pin. Settle these items first, because each one changes the build sequence and the access model. The cards below list what to confirm for each.
Control plane node count
The HA manifests for Argo CD rely on pod anti-affinity rules, so the cluster that runs Argo CD needs at least three nodes that can schedule replicas on separate hosts. Argo CD does not support IPv6-only clusters, so confirm the cluster provides IPv4 or dual-stack networking before the build starts. Check that node pools, taints and resource quotas allow replicas to land on different nodes, and that a single node failure leaves the API server and controllers running.
Target cluster versions
List every cluster Argo CD will deploy to, with its Kubernetes version and the components running on it. The Kubernetes version skew policy requires kube-apiserver to be upgraded one minor version at a time, and kubelets may be up to three minor versions older than kube-apiserver. Confirm each target sits on a minor release the project still maintains, and note any cluster already scheduled for an upgrade, because that changes the rollout order.
Git hosting and network paths
Identify where manifests, Helm charts and Kustomize bases live, whether on a self-hosted Git server, a managed service or another internal source. Confirm that the repo server can reach each source through any proxy or firewall rules, and that internal certificate authorities can be trusted. Decide how repository credentials will be stored. Argo CD 3.0 removed repository definitions from the argocd-cm ConfigMap, so repositories must be defined as Kubernetes Secrets.
Identity provider and claims
Decide whether Argo CD uses its bundled Dex with a connector such as SAML, LDAP or GitHub, or connects directly to an existing OIDC provider such as Okta, Auth0, Microsoft, Keycloak or Google Workspace. Confirm which claims the provider emits, including group membership, because RBAC policies map to them. Argo CD 3.0 changed Dex-based RBAC to use the federated_claims.user_id claim, so test that this claim exists for each user. Plan to disable the built-in admin user once SSO works.
Argo CD release line to pin
The patch lines published on October 12, 2026 were v3.5.5 (marked latest), v3.4.11 and v3.3.16, and v3.6.0 was in release candidate. Argo CD ships a minor release about every three months and patches only the three most recent minors, so pin a patch line your environment supports and plan the next upgrade in advance. Avoid release candidates in production. Confirm the chosen release against your Kubernetes versions and your own support requirements before the build.
How the Argo CD controller reconciles clusters, and where sharding fits
The application controller is the component that decides whether a cluster matches Git, so it is the first thing to understand before you size or recover an Argo CD installation. Around it sit three other parts: the API server, which serves the web UI, the CLI and the API that users and CI systems call; the repo server, which clones Git repositories and renders manifests, including running Helm and Kustomize to produce the final objects; and Redis, which caches rendered manifests and application state to reduce repeated work. Redis is a disposable cache. If it is lost, Argo CD rebuilds what it needs, although the first sync after a restart will be slower.
The application controller continuously compares the desired state rendered by the repo server with the live state reported by each target cluster, and it acts on differences when auto-sync is enabled or when a user triggers a sync. It holds a watch and cache for every managed cluster, so its memory and CPU load grows with the number of Application objects, the number of resources each application manages, and the number of clusters it connects to. Reconciliation of one application does not depend on another, which is what makes the controller shardable.
Argo CD is largely stateless. Its configuration, applications, projects, repository definitions, cluster credentials and RBAC settings live as Kubernetes objects such as ConfigMaps, Secrets and custom resources in the Argo CD namespace. Recovery therefore centers on two things: a backup of those objects in the hosting cluster, and the Git repositories that hold the desired state. Confirm with your platform team how those objects are backed up, whether the backup covers Secrets, and how the cluster credentials stored by Argo CD are protected and restored. Test a restore into a separate cluster rather than assuming the export is complete.
Sharding distributes the application controller across multiple replicas so that each replica manages a subset of the target clusters. The high availability documentation describes it as a way to scale the controller, and the decision is a sizing one rather than a default. Ask your team to count the Application objects, the resources they manage and the clusters they target, then project growth over the period you plan to run the platform. A single controller may be enough for a small estate, while a larger one may need several shards. Treat any shard count as a starting hypothesis.
Validate the sizing with load testing in your own environment, using realistic repository sizes, rendering complexity and sync frequency, because those factors change controller and repo server load more than application count alone. Watch memory, CPU and reconciliation latency during tests, and check that a shard failover behaves as expected. Sharding also changes how you troubleshoot, since the cluster you are investigating may be handled by a specific replica, so record the shard assignment in your runbook.
Argo CD setup sequence from install to first sync
This sequence takes Argo CD from a highly available install on a management cluster to its first controlled sync from Git. Each step ends with a check, so the platform team confirms one layer works before the next layer depends on it. The result is a GitOps control plane with named users, scoped repository access and project boundaries in place before any workload is deployed.
Install the HA manifests on the management cluster
The platform team applies the high availability manifests to a dedicated management cluster, keeping Argo CD separate from the workloads it deploys. The HA manifests need at least three nodes because of pod anti-affinity rules, and IPv6-only clusters are not supported, so confirm node count and addressing with your cluster team before the apply. Argo CD keeps its data in Kubernetes objects and treats Redis as a disposable cache, so backup planning centers on cluster state and Git repositories. Done when all Argo CD pods report Running and Ready and the API server accepts a login from the CLI.
Connect SSO through Dex or OIDC
Choose between the bundled Dex, which offers connectors such as SAML, LDAP and GitHub, and a direct OIDC connection to an existing provider such as Okta, Auth0, Microsoft, Keycloak or Google Workspace. A direct OIDC connection removes one component from the login path, while Dex suits providers that speak SAML or LDAP. Confirm which protocols your identity provider supports, register the redirect URL and client settings there, and store the client secret in a Kubernetes Secret. Done when a browser login redirects to the provider and returns to the Argo CD interface with an identity attached.
Map SSO groups to roles and test login
Write RBAC policy that maps identity groups to Argo CD roles. For Dex-based RBAC, Argo CD 3.0 uses the federated_claims.user_id claim, so check the value your provider sends before writing policy. Update and delete permissions now apply only to the application itself, and reading logs requires an explicit logs, get permission, so include both in the roles you define. Done when a non-admin account from the identity provider signs in, sees only the applications its group allows, and is refused any action outside its role.
Disable the initial admin account
Once the non-admin SSO login succeeds, set admin.enabled to false so the built-in admin user can no longer sign in. The user management guidance limits the admin user to initial setup, so record where its initial credential was stored and who can recover access if SSO fails. Agree a break-glass procedure with your security team and document it in the runbook before making the change. Done when a login attempt as admin is refused and an SSO administrator can still manage applications.
Define repository credentials as Secrets
Create each Git or Helm repository as a Kubernetes Secret in the repository secret format Argo CD expects, with credentials limited to read access on that repository. Argo CD 3.0 removed repository configuration from the argocd-cm ConfigMap, so older examples that edit that ConfigMap will not apply. Use deploy keys or least-privilege tokens where the Git host supports them, and name an owner responsible for rotation. Done when each repository shows a healthy connection status in the Argo CD interface and in the CLI repository listing.
Register target clusters with scoped credentials
Register each target cluster so Argo CD can deploy to it, using a service account whose permissions match what that cluster's workloads need. Grant cluster admin only where a documented reason exists, and confirm the network path from the management cluster to each target API server before registration. Store the cluster credentials as Kubernetes Secrets under the same access controls as the repository credentials. Done when each cluster shows a successful connection status and Argo CD can list the resources in the namespaces it was granted.
Create AppProjects with source and destination boundaries
Create an AppProject for each team or environment that lists the repositories it may deploy from, the clusters and namespaces it may deploy to, and the Kubernetes resource kinds it may create. Projects set the main boundary between teams sharing one Argo CD instance, so review each project with its application owners. Bind the RBAC roles to project actions so each team can sync only its own applications. Done when an Application pointing at a repository outside its project is rejected and an approved source passes validation.
Create the first Application and sync
Create the first Application in a non-production target, pointing at a reviewed path in a Git repository and using manual sync so each change is applied on purpose. Read the diff Argo CD presents before syncing, including output from Helm or Kustomize content your team has not reviewed, since rendered manifests are applied with the permissions Argo CD holds for that destination. Argo CD tracks resources with annotations by default, so confirm how existing resources will be adopted before the first sync. Done when the sync completes, the application reports Healthy, and a refresh afterward reports no drift.
Connecting Argo CD SSO and RBAC to your identity provider
Start by choosing the login route, because it decides what your identity team must configure and what Argo CD expects in return. Argo CD ships with Dex, a bundled identity broker that offers connectors such as SAML, LDAP and GitHub. Use it when your directory is reachable through one of those connectors and you want Argo CD to handle the federation. The alternative is a direct OpenID Connect integration with an existing provider such as Okta, Auth0, Microsoft, Keycloak or Google Workspace. Direct OIDC removes one component from the login path, but it still needs a client registration, a redirect URL and a client secret that you must store and rotate. Confirm which option your identity team already supports and who owns the client configuration.
Whichever route you pick, RBAC depends on claims. Argo CD reads the user identity and group membership from the token it receives, so confirm with your identity team which claim carries the user name and which carries the group values. For Dex-based RBAC, Argo CD 3.0 uses the federated_claims.user_id claim, so a Dex setup built on earlier behavior needs its mapping checked before any upgrade. Ask whether groups arrive as display names, distinguished names or stable object IDs, and whether every user's token includes groups at all. Then decide how each group maps to an Argo CD role. Those mappings live in the RBAC policy, and a group name that does not match exactly will leave the user without the access you intended.
If you are moving from Argo CD 2.14 or earlier, review the RBAC policy before cutover. In 3.0, update and delete permissions apply only to the application itself, so a rule that once covered the resources beneath it no longer does. Access to pod logs also requires an explicit logs, get permission, which means a role that can view application details may see no logs until you add that line. Make these changes in a non-production instance first, then sign in with one test account per role and confirm what each can view, sync, update and delete. Keep a copy of the previous policy so you can compare the two sets of rules when a team reports a missing permission.
Plan the break-glass path before you disable the built-in admin account. The user management guidance recommends using admin only for initial setup and turning it off by setting admin.enabled to false once local users or SSO are configured. Disable it only after several people have confirmed they can sign in through SSO with the correct role, and after you have a written, tested procedure for restoring access if the identity provider or the Dex connector fails. Store that procedure with your cluster runbooks, and rehearse it in a non-production instance before you rely on it.
How identity and repository data map to Argo CD roles and objects
This table traces each identity and repository input to the Argo CD object or setting that consumes it, along with who owns the mapping and where changes are reviewed. Read each row as a link in the access chain: a change in the identity provider or Git repository only takes effect in Argo CD once the matching RBAC policy, AppProject or Secret is updated. The main takeaway is that every mapping should have a named owner and a review path before go-live.
| Source | Argo CD destination | Owner and review |
|---|---|---|
| IdP user identifier | federated_claims.user_id claim for Dex-based RBAC, or the OIDC subject when Argo CD connects directly to an OIDC provider | Identity team owns the claim mapping. Review in the SSO configuration change record, confirmed with a test login by a non-admin user. |
| IdP groups | Group-to-role bindings in the Argo CD RBAC policy (argocd-rbac-cm), mapping each group to a project-scoped or global role | Identity team supplies group membership. Platform team owns the policy file. Review through a pull request to the policy repository. |
| AppProject scope | Allowed source repositories, destination clusters and destination namespaces, plus permitted Kubernetes resource kinds | Platform team owns each project. Application team requests changes. Review by security and platform leads before the project manifest is merged. |
| Repository URL and credential type | A Kubernetes Secret labeled as a repository definition, holding the URL and either an SSH key, token or GitHub App credential, since repositories are no longer read from argocd-cm | Platform team creates the Secret. Credential owner is the Git service team. Review by the security team, and confirm the Secret is restricted by least-privilege RBAC. |
| Admin account | The built-in admin user, disabled by setting admin.enabled to false once SSO or local users are working | Platform lead owns the setting. Review in the break-glass procedure, with an audit of who can reach the emergency credential. |
| Local accounts, if any | Accounts declared in argocd-cm with their capabilities, kept only for cases SSO cannot cover such as service automation | Platform team owns the list. Review each account on a fixed schedule and confirm the owner is named in the account record. |
| Git change to live deployment | Application objects referencing an AppProject and a repository Secret, synced by the application controller | Application team owns the manifest in Git. Review is the normal pull request approval, with branch protection enforced in the Git host. |
Argo CD security settings to harden before production
Argo CD holds credentials for every repository and cluster it deploys to, so its own configuration is part of your attack surface. The six controls below cover sign-in, authorization, secret storage and the content Argo CD renders. Confirm each setting against the Argo CD security page and the CIS Kubernetes Benchmark for your platform before production.
Disable the built-in admin account
The built-in admin user is meant for initial setup only. Once SSO or named local users work, set admin.enabled to false and confirm that a named administrator can still sign in and manage applications and projects. Document a break-glass procedure for the case where the identity provider is unavailable, store its credentials outside the cluster, and test the procedure before go-live.
Scope access with RBAC and AppProjects
Argo CD RBAC controls who can act on applications, and each AppProject controls what those applications may deploy. Limit every AppProject to the source repositories, destination clusters and namespaces its team owns, and deny cluster-scoped resources unless the platform team approves them. After upgrading to Argo CD 3.0 or later, test your Dex group mappings, because RBAC now matches the federated_claims.user_id claim.
Store repository credentials as Secrets
Since Argo CD 3.0, repositories must be defined as Kubernetes Secrets, because the argocd-cm ConfigMap no longer holds repository configuration. Give each credential read-only access to the repositories it needs, prefer deploy keys or short-lived tokens where your Git host supports them, and rotate credentials on a schedule your security team sets. Confirm that cluster RBAC prevents other users from reading these Secrets.
Encrypt Secrets at rest in etcd
Kubernetes stores Secrets unencrypted in etcd by default, so repository and cluster credentials are exposed to anyone who can read the datastore or its snapshots. Configure encryption at rest for the API server, and protect etcd backups with the same controls as the Secrets they contain. Restrict list and watch access on Secrets with least-privilege RBAC, or use an external store through the Secrets Store CSI Driver. Confirm the setting on your distribution, because managed services handle it differently.
Treat untrusted charts and overlays as code
A Helm chart or Kustomize overlay from an outside source can run in your cluster, because its rendered manifests may create workloads, cluster roles or admission webhooks. Pin chart versions and Git revisions, mirror approved sources into repositories you control, and have reviewers read the rendered output before merge. Limit which Helm repositories and Git sources each AppProject can use, so one application cannot pull arbitrary content.
Enforce Pod Security Admission on Argo CD namespaces
Pod Security Admission applies one of three Pod Security Standards (Privileged, Baseline or Restricted) to each namespace. Label the namespaces that Argo CD deploys into with the level your workloads can meet, and use Restricted wherever workloads allow it. Start in audit or warn mode to find violations before switching to enforce. Apply the same review to the namespace where Argo CD runs.
Argo CD upgrades, patch support and recovery planning
Plan Argo CD upgrades as a recurring operational task with a named owner. The Argo CD release process ships a minor release four times a year, about once every three months, and only the three most recent minor versions receive patch releases. An Argo CD instance left on an older minor version therefore falls out of patch coverage within a few releases. On October 12, 2026 the project published patch releases v3.5.5 (marked latest), v3.4.11 and v3.3.16, with v3.6.0 in release candidate. Check the GitHub releases page against your running version at each review, and book an upgrade window before your current minor version leaves the supported set.
The jump from 2.14 to 3.0 needs the most test time because it changed behavior that your teams may depend on. Update and delete RBAC now apply only to the application itself, and logs access requires an explicit logs, get permission. Annotation-based resource tracking is the default, so resources previously tracked by label need to be checked before cutover. Argo CD 3.0 also removed repository configuration from the argocd-cm ConfigMap, so each repository must be defined as a Kubernetes Secret, and Dex-based RBAC now matches the federated_claims.user_id claim. Run the upgrade against a copy of your production configuration in a non-production cluster, then confirm that every AppProject role, repository and SSO group still grants the access it did before.
Recovery planning starts with what Argo CD keeps outside Git. Argo CD is largely stateless, with its data held in Kubernetes objects, and Redis is a disposable cache. Back up the Argo CD Kubernetes objects, including Applications and AppProjects, along with the Secrets that hold repository and cluster credentials and the settings used for SSO and the admin account. Store these copies encrypted and outside the cluster they protect. Git holds the desired state of your workloads, but it does not hold the credentials Argo CD uses to read it, so a backup that omits those Secrets leaves you with manifests and no way to pull them.
If the Argo CD control plane is lost, rebuild it from the high availability manifests. These need at least three nodes because of pod anti-affinity rules, and IPv6-only clusters are not supported. Restore the saved objects and Secrets, then let the application controller re-sync each Application from Git. Confirm that the controller shard and replica settings match your sizing, and let Redis start empty. Review which Applications have pruning or sync windows that could block changes, and decide which ones need a manual sync before automated sync is re-enabled.
A recovery plan is only proven when someone restores from it. Run a timed restore test in a non-production cluster that matches your production topology, starting from the backup set and stopping when every Application reports synced and healthy. Record how long each step takes, including obtaining access to the backup and any approvals, and compare the result with the recovery time your operations and risk owners have agreed. Repeat the test after each minor upgrade, because a new release can change which objects and Secrets must be captured.
Common Argo CD failures, their causes and fixes
This table lists six failures that teams hit most often when running Argo CD on Kubernetes, with the likely cause, the check to run and the fix for each. Read each row from left to right. Several failures trace back to the Argo CD 3.0 changes, so confirm the upgrade notes for your version before changing configuration.
| Symptom | Likely cause | Check to run | Fix |
|---|---|---|---|
| Repository authentication fails after upgrading to 3.0 | Repository details still sit in the argocd-cm ConfigMap, which 3.0 no longer reads for repositories | List Secrets carrying the repository label and confirm each app's repository URL matches one of them | Recreate each repository as a Kubernetes Secret following the 3.0 upgrade notes, then refresh affected applications |
| SSO users sign in but see no applications | RBAC policy keys on a claim the identity provider does not send, or on the 3.0 federated_claims.user_id claim | Decode a test user's token and compare its claim values with the subjects in the RBAC policy | Align the policy subject with the claim value and grant read access on applications to the matching role |
| Application sync loops or flaps between states | Annotation-based resource tracking, the 3.0 default, collides with another tool writing the same annotation | Review the tracking annotation on live objects and find which other controller or pipeline updates it | Change the tracking method to match your tooling, or ignore the conflicting field through ignoreDifferences |
| Applications stuck OutOfSync after a clean sync | Helm or Kustomize renders defaults that the live object adds back, such as server-set fields | Run an app diff and compare the rendered manifest with the live object field by field | Set the value explicitly in the source, or add narrow ignoreDifferences entries for defaulted fields only |
| HA pods stay Pending on a small cluster | HA manifests use pod anti-affinity, which needs at least three nodes to schedule every replica | Count schedulable nodes and read the scheduler events on the pending pods | Add a third schedulable node, or run the non-HA install on clusters with fewer nodes and plan HA for later |
| Permission errors when viewing logs after upgrading past 2.14 | Since 2.14 to 3.0, logs access needs an explicit logs, get permission, and update and delete apply only to the application | Test a user's pod log view and check whether their role includes the logs resource with get | Add a logs, get grant for the relevant application path to the role, then retest with a non-admin account |
Questions buyers ask before hiring help with Argo CD
How much does it cost to hire help with Argo CD?
Argo CD has no paid edition from the project, which is released under the Apache License 2.0, so the cost is labor and infrastructure. Your spend covers the people who design and build the deployment, plus the clusters and nodes that run it. The main cost drivers are the number of clusters and applications, the complexity of your identity provider, how repositories and secret stores are integrated, the HA and sharding design, upgrade and recovery testing, and ongoing patch support. Build work is usually one-time, while patch support, upgrades and monitoring recur. Ask every bidder for a fixed-scope quote that lists these items separately, with exclusions and the assumptions made about your environment.
How long does an Argo CD implementation take?
The timeline depends on the same drivers as cost, so no single duration fits every environment. A pilot on one cluster with one identity provider moves faster than a fleet with several tenants, multiple repository sources and a formal approval process. Work usually runs in stages: a foundation with SSO and RBAC, repository and secret integration, a pilot application, then HA, upgrade and recovery tests before wider rollout. Ask for the timeline as dated milestones in the written scope, with the client decisions and access each milestone depends on. Delays most often come from slow identity group design, change windows and credential handoffs, so confirm those dates early.
What does our team need to provide for an Argo CD engagement?
Plan to provide access, decisions and named people. Typical inputs include administrator access to the target clusters or a suitable non-production cluster, admin rights or a named contact for your identity provider, access to the Git hosting that will hold manifests and charts, and the secret store your team already uses. You also need a named owner for each application team, a change process, and a sign-off authority for production cutover. Identify who approves group-to-role mappings, who owns the backup target for recovery testing, and which network paths to Git and container registries are allowed. Ask the implementation partner to list these inputs in the scope so gaps surface before work starts.
Can our platform team run Argo CD without outside help?
Yes, a capable platform team can run Argo CD alone, since it is open source and the installation path is well documented. The harder work sits where small mistakes have wide effects: SSO group mapping, project boundaries, repository and secret handling, HA and sharding, and upgrades across breaking changes. Argo CD 3.0 changed repository configuration and RBAC behavior, so teams moving from older releases need a tested plan. Assess your team against those areas honestly, and check whether anyone has already run controller sharding or restored Argo CD from backup. If gaps exist, a fixed-scope engagement can cover only those parts while your team keeps ownership of the platform.
What usually breaks in Argo CD deployments after go-live?
The most common failures come from configuration that looks correct until a change exposes it. After Argo CD 3.0, repositories must be defined as Kubernetes Secrets, and the argocd-cm ConfigMap no longer holds repository settings. Dex-based RBAC uses the federated_claims.user_id claim. In 2.14 to 3.0 upgrades, update and delete permissions apply only to the application itself, and viewing logs needs an explicit logs, get permission. Teams often leave the built-in admin user enabled after SSO works, although the project recommends disabling it with admin.enabled set to false. HA manifests need at least three nodes because of pod anti-affinity rules. Untrusted Helm and Kustomize content in a repository also needs review before sync.
How do we keep Argo CD patched after go-live?
Argo CD ships a minor release about four times a year, and only the three most recent minor versions receive patch releases, according to the project's release process. On October 12, 2026 the GitHub releases page published patches v3.5.5 (marked latest), v3.4.11 and v3.3.16, with v3.6.0 in release candidate. A deployment on an older minor falls out of patch coverage, so the upgrade cadence has to be planned. Patch support is recurring work: reading release notes, testing in a non-production cluster, applying the update, and checking RBAC and sync behavior afterward. Ask any provider who performs this work, how often, how testing and rollback are handled, and whether it is sold as a retainer or as a separate item.
Does Argo CD need high availability and sharding from day one?
It depends on how many clusters and applications Argo CD manages and how much deployment downtime your teams can tolerate. HA manifests need at least three nodes because of pod anti-affinity rules, and IPv6-only clusters are not supported. The application controller can be sharded across replicas, while Redis is a disposable cache and most state lives in Kubernetes objects. Sharding adds design and testing work, so teams usually decide it during a sizing review, before an incident forces the choice. Ask for the HA and sharding design as a separate line in the quote, including the test plan for controller failover and a restore from backup.
What should a fixed-scope quote for Argo CD include?
A useful quote lists each component and the assumptions behind it. Ask for the cluster and application counts used in the estimate, the identity provider and connector types, the repository and secret sources, the HA and sharding scope, the upgrade and recovery tests, and the format of the handover documentation. Include exclusions such as application code changes, cluster provisioning or work on other platforms, and state who supplies the test environment. Ask how changes to scope are priced, which acceptance criteria close each milestone, and what support runs after go-live and whether it is a separate retainer. Comparable line items make bids easier to evaluate side by side.
How DeployOpen scopes and delivers an Argo CD integration
DeployOpen plans, implements, customizes, integrates, hardens and supports self-hosted open-source platforms in infrastructure you control. For Argo CD, the work starts with a written scope covering the clusters, repositories, identity and recovery design, then moves through build, testing and handover to your team. Engagements are fixed-scope, and ongoing support is available as a retainer.
How we scope
- The written scope names the clusters, Argo CD instances and namespaces, and whether HA or sharding is in place.
- Scope covers SSO and RBAC design, including Dex or direct OIDC, project boundaries and the admin user policy.
- Repository credentials, untrusted Helm and Kustomize content handling and recovery steps are listed as deliverables with owners.
How we build
- Argo CD is installed from the project's manifests in your clusters, with the HA topology agreed in scope.
- Repository definitions are created as Kubernetes Secrets, since Argo CD 3.0 no longer reads them from argocd-cm.
- Helm and Kustomize sources are reviewed and pinned, and the application controller is sized for your application count.
How we hand over
- Handover includes Application and AppProject manifests, RBAC mappings and the runbook for adding clusters and repositories.
- Recovery documentation covers Argo CD state held in Kubernetes objects and how Redis cache loss is handled.
- Your team walks through a test restore and a controlled sync before the environment goes live.
How we support
- Ongoing support is available as a retainer covering Argo CD patch upgrades and configuration changes.
- Upgrade planning follows the Argo CD minor release cadence and the upgrade notes for each release you move to.
- Security reviews of Helm and Kustomize content and RBAC changes can run as separate, recurring testing work.
