Which Argo CD installation type fits your team
A platform lead choosing how to run Argo CD should start with the production recommendation: the Argo CD installation docs point to the high availability manifests for production, while the non-HA install.yaml and namespace-install.yaml manifests are typically used for evaluation, demonstrations and testing. The HA manifests run multiple replicas of supported components, so the controller, API server and repo server can keep working through a pod restart or an upgrade. That benefit matters only if you can meet the setup conditions: the HA docs say the installation needs at least three different nodes because of pod anti-affinity rules, and IPv6-only clusters are not supported. The HA layout also preconfigures argocd-redis for three Redis servers and sentinels and suggests three or more API server replicas to avoid downtime during upgrades. If your cluster has fewer schedulable nodes, plan for that gap before you pick HA.
The non-HA manifests suit a proof of concept, a lab or a training environment, not a production control plane. Their privilege model is the decision point. install.yaml runs with cluster-admin access, which simplifies setup for a single administrator but gives Argo CD broad reach across the cluster. namespace-install.yaml requires only namespace-level privileges and no cluster roles, which can fit a team that must keep Argo CD inside its own namespace. Confirm with your security team whether namespace scope is acceptable for the clusters you target, because Argo CD's ability to manage resources across namespaces depends on what it is allowed to do.
The core install fits headless cluster administrators who do not need multi-tenancy. It deploys Argo CD without the API server and UI, with fewer components, and runs the non-HA version of each component, so it does not give you the redundancy of the HA manifests. Choose it when a platform team drives Git-based delivery through its own tooling and has no need for per-team SSO, RBAC or a web UI. If developers will later need the UI or SSO, plan the migration to a full install now, because the core layout does not include them. Also check whether the Helm chart you intend to use is the one you want, since the installation docs state the Argo CD Helm chart is community maintained.
How the three Argo CD installs compare
This table compares the non-HA manifests, the HA manifests, and the core install across privileges, node requirements, component layout, API server and UI presence, Redis topology and Helm chart support. Read each row against your own cluster policy, since the documented facts describe the upstream manifests and your environment decides what is acceptable. The main takeaway is that production use points to the HA manifests, while the core install suits cluster administrators who do not need multi-tenancy.
| Aspect | Non-HA (install.yaml) | HA manifests | Core install |
|---|---|---|---|
| Recommended use | Evaluation, demonstrations and testing, not recommended for production | Recommended for production by the Argo CD installation docs | Cluster administrators who do not need multi-tenancy |
| Privileges | Runs with cluster-admin access | Confirm the cluster-wide role bindings your policy allows | Confirm the privilege model against your admin workflow |
| Namespace-level option | namespace-install.yaml needs only namespace-level privileges and no cluster roles | Confirm whether a namespace-scoped HA variant fits your policy | Confirm whether it runs with namespace-scoped permissions in your setup |
| Node requirement | Not stated as a minimum in the facts supplied; confirm sizing for your cluster | At least three different nodes because of pod anti-affinity rules | Confirm node count with your platform team |
| Component layout | Non-HA version of each component | Multiple replicas of supported components | Fewer components, non-HA version of each |
| API server and UI | Included | Included, with 3 or more API server replicas suggested to avoid downtime during upgrades | Not included (headless) |
| Redis topology | Single non-HA Redis instance | argocd-redis preconfigured for three Redis servers and sentinels | Confirm the Redis setup in the core manifests before relying on it |
| Helm chart support | Argo CD Helm chart is community maintained | Argo CD Helm chart is community maintained | Argo CD Helm chart is community maintained; confirm which values match a core install |
What runs in each installation
The three Argo CD install types differ mainly in how many replicas run, whether the API server and UI are present, and how the application controller scales. Each card below covers one component or decision that changes between them, so you can match the footprint to your team's needs.
Non-HA: one replica of each
The non-HA manifests, install.yaml and namespace-install.yaml, run a single replica of each component, including the API server, repo server, application controller and Redis. The Argo CD installation docs say these manifests are not recommended for production and are typically used for evaluation, demonstrations and testing. Check that your team does not carry a non-HA install into production by default. Plan a move to HA before go-live rather than after the first incident.
HA: replicas and Redis trio
The HA manifests run multiple replicas of supported components. The HA docs say argocd-redis is preconfigured for three Redis servers and sentinels, and suggest three or more API server replicas so upgrades do not cause downtime. The HA install needs at least three different nodes because of pod anti-affinity rules. Confirm that your cluster has three schedulable nodes and that IPv6-only clusters are not your setup, since the docs do not support them.
Controller sharding with ARGOCD_CONTROLLER_REPLICAS
In HA, the application controller scales by sharding clusters across replicas, configured through the ARGOCD_CONTROLLER_REPLICAS setting. Sharding matters once you manage many clusters or large application sets, because a single controller becomes the bottleneck. Ask your platform team how many clusters and applications each shard will carry, and test how sharding behaves when a replica is restarted or rescheduled.
Core: headless without API and UI
The core install deploys Argo CD in headless mode for cluster administrators who do not need multi-tenancy. It runs fewer components, omits the API server and UI, and runs the non-HA version of each remaining component. Core suits teams that manage Applications through Git and the CLI on the cluster itself. If your delivery teams need a web UI or SSO-based access, core does not give them that surface.
Stateless design with Kubernetes as the store
Argo CD is largely stateless. Its data lives in Kubernetes objects, so the cluster's etcd backup and restore practices are the main recovery path for Argo CD configuration. Redis is a disposable cache, so losing it causes a rebuild rather than data loss. Confirm that your etcd backups cover the namespace where Argo CD runs, and document how you would rebuild the cache after a Redis failure.
Why cluster-wide versus namespace privileges change the design
The privilege model is often the deciding factor between the Argo CD installation types, and it matters before any HA sizing. The install.yaml manifest runs Argo CD with cluster-admin access, so one instance can deploy to and read from the whole cluster and any cluster it is registered with. The namespace-install.yaml manifest needs only namespace-level privileges and no cluster roles, which suits a platform where a central team does not want a GitOps controller holding cluster-wide rights. The Argo CD installation docs also position the non-HA manifests for evaluation, so a namespace-scoped design that reaches production will still need the HA layout. Confirm with your platform team which namespaces and clusters each Argo CD instance must reach before choosing, because a namespace-scoped install can only manage what its granted permissions allow.
Argo CD 3.0 changed several RBAC behaviors that affect any tenancy design. Per the 2.14 to 3.0 upgrade notes, update and delete RBAC now apply only to the application itself, not to the resources it manages. Access to logs needs an explicit logs, get permission. Annotation-based resource tracking is now the default. Teams that wrote policies against the 2.x behavior should review them and test them in a staging cluster before upgrading. Also, Argo CD 3.0 removed repository configuration from the argocd-cm ConfigMap, so repositories must be defined as Kubernetes Secrets. That change moves repository credentials into the same RBAC and secret-handling controls you already audit, and it means the people who can read Secrets in the Argo CD namespace need explicit review.
Neither privilege model suits every tenancy pattern. A single-team cluster may run comfortably with cluster-wide rights, while a multi-team platform with strict boundaries may need namespace-scoped installs, a separate instance per boundary, or the controller sharding described elsewhere on this page. Ask your team to map each tenant to the clusters, namespaces and repositories it may use, and to confirm which Argo CD RBAC roles and Dex or OIDC group claims enforce that map. The Argo CD user management documentation is the natural next read for setting up local users and SSO, and disabling the built-in admin user with admin.enabled set to false once those are in place.
Choosing an installation by team situation
For a shared platform that serves several application teams, the Argo CD installation docs recommend the high availability manifests for production. They run multiple replicas of supported components, so a single pod failure or an upgrade should not take the whole deployment offline. Plan for the scheduling requirements before you commit.
- Node count: The HA manifests need at least three different nodes because of pod anti-affinity rules. Confirm your cluster can keep those replicas schedulable during node maintenance.
- Redis topology:
argocd-redisis preconfigured for three Redis servers and sentinels. Redis is a disposable cache, so the state that matters lives in Kubernetes objects. - API server replicas: The docs suggest three or more API server replicas to avoid downtime during upgrades.
- Controller scaling: Shard clusters across application controller replicas with
ARGOCD_CONTROLLER_REPLICASas the number of clusters grows. - Access controls: Use SSO through the bundled Dex or a direct OIDC provider, then set
admin.enabledtofalseonce SSO or local users are configured.
The choice changes if your cluster cannot host three nodes or IPv6-only networking is in use, since the docs state IPv6-only clusters are not supported. Confirm node count and network stack before sizing the install.
The non-HA install.yaml and namespace-install.yaml manifests are typically used for evaluation, demonstrations and testing. The Argo CD installation docs say they are not recommended for production use. Their main value is speed and low setup effort when you want to see how the controller and UI behave against your own repositories.
- Cluster-wide access:
install.yamlruns with cluster-admin access, so use it only in a disposable or lab cluster. - Namespace-scoped trial:
namespace-install.yamlrequires only namespace-level privileges and no cluster roles. It suits a shared cluster where you cannot grant cluster-wide rights, but it limits the controller to that scope. - Single replicas: Components run without redundancy, so an outage during a demo is expected and does not indicate a production fault.
- Clean reinstall: Plan to install the production layout from the start, since an evaluation instance is not a supported base for production.
The choice changes when a pilot starts carrying real workloads or credentials. At that point, move to the HA layout before cutover. Label the lab instance as non-production in your runbooks and confirm which privilege model your environment permits.
The core install deploys Argo CD in headless mode for cluster administrators who do not need multi-tenancy. It has fewer components, leaves out the API server and UI, and runs the non-HA version of each component. This suits a platform team that manages its own clusters and drives reconciliation through Git and Kubernetes objects.
- Smaller footprint: Fewer components means fewer pods to size, patch and monitor.
- No UI or API server: Without the UI and API server, end users have no login page, so access is governed through Kubernetes RBAC and Git review.
- No built-in redundancy: The components are non-HA, so plan backup and restore for the Kubernetes objects that define your applications.
- Workflow dependencies: Identify which operator workflows depend on the UI or API server, such as status visibility for other teams.
The choice changes when more than one team needs to request deployments or view application status through a UI, or when SSO-based access is a requirement. In those cases, the HA or standard layout fits better. Confirm which of your operator workflows depend on the UI or API server before standardizing on headless mode.
Many teams want to manage Argo CD itself with Helm so its configuration sits in the same values files as the rest of their platform. The Argo CD installation docs state that the Helm chart is community maintained. That means the chart is not the project's own packaged release path, so treat it as a dependency you own and test before each upgrade.
- Maintenance model: Ask who maintains the chart you plan to use, how quickly it tracks Argo CD releases, and what happens when it lags.
- Version pinning: Pin both the chart version and the Argo CD image version, and record the combination you tested.
- Upgrade notes: Major upgrades change behavior. For example, the 2.14 to 3.0 notes say repositories moved from
argocd-cminto Kubernetes Secrets, so read the notes before bumping the chart. - Values control: Keep HA, sharding and SSO settings in version-controlled values so a chart upgrade does not silently reset them.
The choice changes if your organization requires vendor-maintained packaging or a documented support path for the install itself. In that case, weigh the community chart against the project's own manifests or a Kustomize overlay. Confirm the chart source, its maintenance commitments and the Argo CD version it targets before adopting it.
Upgrades, releases and day-two operations
This table compares what each Argo CD install type asks of the operator after go-live: release tracking, rolling upgrades, backups, monitoring and Kubernetes skills. Read it with the Kubernetes version skew and support windows in mind, since your Argo CD upgrade path depends on the cluster version you run.
| Area | Non-HA manifests (install.yaml) | HA manifests (recommended for production) | Core install (headless) |
|---|---|---|---|
| Intended use | Evaluation, demonstrations and testing, not recommended for production | Production, with multiple replicas of supported components | Cluster administrators who do not need multi-tenancy, with no API server or UI |
| Release cadence and patch window | Follows the same Argo CD minor release cycle: four minors a year, with only the three most recent minors receiving patches | Same cadence and patch window as the other install types | Same cadence and patch window; confirm the core manifests track the same release line |
| Current published patches | v3.5.5, v3.4.11 and v3.3.16 were published October 12, 2026, with v3.6.0 in release candidate | Same patch set applies; plan to move to a supported minor before the older lines drop out | Same patch set applies; plan the same upgrade path |
| Rolling upgrade planning | Single replicas mean upgrades cause downtime for the controller and API server | Plan at least 3 API server replicas to avoid downtime during upgrades, on at least three different nodes | No API server to protect, but the single controller still restarts during upgrades; confirm your tolerance for sync pauses |
| Node and replica footprint | Runs on fewer nodes with one replica per component | Needs at least three nodes because of pod anti-affinity rules, plus Redis HA with three servers and sentinels | Fewest components, so the smallest footprint, with no Redis HA layer |
| Backup scope | Back up Argo CD Application, AppProject and repository Secret objects, since Argo CD keeps its data in Kubernetes objects | Same objects, plus confirm your backup tool captures the Redis-related state you rely on; Redis is a disposable cache | Same Kubernetes objects; the smaller component set reduces what to restore |
| Monitoring focus | Watch controller sync health and pod restarts; keep in mind no redundancy masks failures | Monitor replica health, Redis and sentinel status, controller shard load and API server availability | Monitor controller sync health and CLI or API-driven automation, since there is no UI for operators |
| Kubernetes skills needed | Basic cluster administration and the ability to read manifests | Cluster administration plus sharding (ARGOCD_CONTROLLER_REPLICAS), anti-affinity planning and Redis HA operation | Cluster administration plus GitOps conventions, since operators work through Git and the CLI rather than the UI |
| Version dependencies to track | Argo CD minor, Kubernetes minor (1.37 end of life October 28, 2027; 1.36 June 28, 2027; 1.35 February 28, 2027, per kubernetes.io as of September 2026) and the kube-apiserver upgrade order | Same, plus confirm Argo CD supports the Kubernetes minor you plan to run before each cluster upgrade | Same, with fewer components to re-test after each Kubernetes minor upgrade |
Moving from evaluation manifests to a production install
This sequence takes a cluster from the non-HA evaluation manifests to an Argo CD install that has HA components, scoped privileges, Secret-based repositories, SSO and a tested upgrade path. Each step ends with a check you can confirm before moving on.
Confirm node count and anti-affinity capacity
The platform team checks that the target cluster has at least three schedulable nodes that can host the HA pods without breaking pod anti-affinity rules. They also confirm the cluster uses IPv4 or dual-stack networking, because IPv6-only clusters are not supported for the HA manifests. Done means the team has written evidence of the node count, the node pool layout and the networking mode, and has agreed it with the cluster owner. If the cluster has fewer than three nodes, stop here and confirm the sizing with your platform team before any manifest changes.
Choose the privilege model for the controller
The team decides whether Argo CD needs cluster-wide privileges or can run with namespace-level privileges only. The standard install.yaml runs with cluster-admin access, while namespace-install.yaml needs no cluster roles but limits the scope of what Argo CD can manage. Platform and security leads should record the decision, the teams that will deploy into each namespace and who approves any cluster-scoped resources. Done means a signed-off decision record exists and the matching manifest set is selected for the next step.
Replace evaluation manifests with the HA set
The engineer removes the non-HA evaluation deployment and applies the high availability manifests recommended for production, using the chosen privilege model. The HA set runs multiple replicas of supported components, including the Redis HA setup, so the team should confirm the image versions and the namespace match its change process. Done means all Argo CD pods are running on different nodes, Redis and the Redis sentinels report healthy, and the team has a rollback path documented.
Scale the controller and API server for production
The engineer sets the API server to three or more replicas to reduce downtime during upgrades and, for large fleets, shards cluster management across application controller replicas using ARGOCD_CONTROLLER_REPLICAS. The right replica count depends on how many clusters and applications the controller manages, so the team should measure load in a test environment first. Done means the replica counts are set in version-controlled configuration and the controller shows balanced cluster assignments.
Move repository definitions into Kubernetes Secrets
The engineer removes repository entries from the argocd-cm ConfigMap and recreates each one as a Kubernetes Secret, since Argo CD 3.0 no longer reads repository configuration from that ConfigMap. Credentials should be restricted with least-privilege RBAC, and the team should confirm how Secrets are encrypted at rest in its cluster, because Kubernetes stores Secrets unencrypted in etcd by default. Done means every application syncs from its repository through a Secret, and no repository credentials remain in plain ConfigMaps.
Enable SSO through Dex or a direct OIDC provider
The identity team configures single sign-on either through the bundled Dex, which supports connectors such as SAML, LDAP and GitHub, or through a direct OIDC connection to an existing provider. The team maps groups to Argo CD RBAC roles, and for Dex-based RBAC it confirms the federated_claims.user_id claim is used as documented for 3.0 and later. Done means a test user from each role group can log in, sees only the applications permitted by RBAC, and the mapping is recorded for audit.
Disable the built-in admin user
Once local users or SSO are working, the administrator sets admin.enabled to false, as the user management documentation recommends using the built-in admin account only for initial setup. The team should keep a documented break-glass procedure in case SSO fails, and confirm who can re-enable the account under change control. Done means the admin login is rejected, at least one SSO administrator can still manage the instance, and the change is recorded.
Rehearse an upgrade in a non-production cluster
Before any production change, the platform team applies the same manifests and configuration to a non-production cluster and performs a version upgrade. They should check the release notes for the target version, confirm it is one of the minor versions that still receive patches, and verify that syncs, RBAC, SSO and Redis recovery behave as expected. Done means the rehearsal produces a written runbook with the observed results, and the team has agreed a go or no-go decision for production.
Questions teams ask before running Argo CD in production
Is the non-HA Argo CD install acceptable in production?
No, the Argo CD installation docs say the non-HA install.yaml and namespace-install.yaml manifests are not recommended for production use. They are typically used during evaluation, demonstrations and testing. For production, the docs recommend the high availability manifests, which run multiple replicas of the supported components. Non-HA is a reasonable choice for a lab or proof of concept, but plan the move to HA before any team depends on the controller for deployments.
Does the core install suit a multi-tenant platform?
No. The core install runs Argo CD in headless mode for cluster administrators who do not need multi-tenancy. It has fewer components, no API server and no UI, and runs the non-HA version of each component. A platform that serves several teams needs the API server and UI for user access, SSO and RBAC, so the HA or namespace-scoped installs are the relevant options there. Core fits a single operations team that manages delivery through Git and the CLI or Kubernetes objects directly.
How many nodes does an Argo CD HA install need, and why?
The HA docs say the HA installation requires at least three different nodes because of pod anti-affinity rules, which keep replicas of the same component off a single node. The same docs preconfigure argocd-redis for three Redis servers and sentinels, and suggest three or more API server replicas to avoid downtime during upgrades. IPv6-only clusters are not supported. Confirm that your cluster has three schedulable nodes with enough headroom to survive one node failure, and check the requirement against your own cluster design.
What drives the effort and cost of running Argo CD in production?
Cost comes from people, infrastructure and the work around the controller. The main drivers are:
- Kubernetes skills in-house for upgrades, RBAC design, etcd and node operations, since Argo CD itself is a controller running on that platform.
- Node capacity for three or more nodes, plus the Redis, API server and controller replicas.
- SSO integration through bundled Dex or an existing OIDC provider, and the RBAC mapping that goes with it.
- Upgrade testing, because Argo CD 3.0 changed repository configuration and RBAC behavior.
The project itself has no paid edition, so license cost is zero. Buying DeployOpen services or staffing in-house both carry recurring effort, and the fixed-scope quote should list who does each piece and what recurs after handover.
How long does an Argo CD production installation take?
It depends on scope. The duration depends on the number of clusters, the SSO design, the repository and secret layout, the cluster hardening and how much testing your upgrade path needs. DeployOpen works from a written scope with agreed deliverables and timelines before work starts, so the only reliable answer comes from a written quote. Ask for the timeline split by phase, the assumptions behind it and the environments it covers, and confirm any internal change approval steps you need to add.
Can a small team run Argo CD HA on its own?
It can, if the team already operates Kubernetes and has an owner for the GitOps platform. The work includes HA node placement, Redis and controller sharding through ARGOCD_CONTROLLER_REPLICAS, SSO, disabling the built-in admin user with admin.enabled set to false once SSO or local users exist, and keeping up with patch releases, since only the three most recent minor versions receive patches. A small team without Kubernetes depth should either train first or buy scoped implementation and ongoing support from DeployOpen, which offers both as separate written engagements.
What should we check about the community Helm chart before using it?
The installation docs state that the Argo CD Helm chart is community maintained, so it is not the same support path as the project's own manifests. Before you adopt it, check which chart version tracks which Argo CD version, how values for HA, Redis and sharding are set, and how upgrades are handled. Confirm who will review chart changes and whether your change process allows a community chart in production. Pin chart and application versions in Git so upgrades are deliberate.
Do Argo CD's Apache-2.0 license and CNCF status mean paid support is needed?
Not for the license. Argo CD is Apache-2.0 licensed and there is no paid edition from the project itself. The CNCF graduated Argo in December 2022. Paid help is a service decision: it covers implementation, hardening, upgrades and support time, and it is priced through a written scope rather than a license fee. Ask any vendor, DeployOpen included, to name what is covered, who responds and how upgrades are tested before they start.
Securing the Argo CD install in regulated environments
The install type sets the first security boundary. The non-HA install.yaml manifest runs with cluster-admin access, so anyone who can control that deployment can act across the whole cluster. The namespace-install.yaml manifest needs only namespace-level privileges and no cluster roles, which narrows the blast radius but limits Argo CD to the namespaces it is granted. The HA manifests carry the same cluster-wide scope question, so confirm with your platform team which privileges each manifest grants in your version before approving it. The core install removes the API server and UI, which reduces the attack surface, but it still needs enough access to reconcile the clusters it manages. Document the chosen privilege model as a control with a named owner.
Repository credentials and cluster credentials are stored as Kubernetes Secrets, and Secrets are stored unencrypted in etcd by default. Configure encryption at rest for etcd before production use, restrict list and watch on Secrets with least-privilege RBAC, and consider an external store through the Secrets Store CSI Driver if your policy requires it. Since Argo CD 3.0, repositories must be defined as Secrets rather than in argocd-cm, so your access review should cover those objects. Also note that update and delete RBAC now apply only to the application itself, and logs access needs an explicit logs, get permission. Disable the built-in admin user by setting admin.enabled to false once SSO or local users are configured, and keep it only for initial setup.
DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications; independent auditors and certification bodies do. Ask your assessor which evidence they expect for RBAC reviews, Secret encryption and admin account settings. Hardening should be checked against the CIS Kubernetes Benchmark, but confirm with your client which benchmark version and which checks apply to the cluster and to the Argo CD namespace, since results depend on your distribution and configuration. Plan a periodic review of Argo CD and Kubernetes upgrades, because security fixes follow the supported release lines.
How DeployOpen scopes and supports Argo CD installs
DeployOpen plans and implements self-hosted open-source platforms inside the client's own infrastructure, including Argo CD on Kubernetes clusters the client controls. We start by agreeing which installation type fits the tenancy model, cluster privileges and node layout, then build, document and hand over that setup in writing.
How we scope
- Confirm whether the cluster needs multi-tenancy, a web UI and SSO, or a headless core install for cluster administrators.
- Record the node count and anti-affinity constraints, since the HA manifests need at least three nodes.
- Agree in writing whether install.yaml cluster-admin access or namespace-level privileges fit your security review.
- Set out the Redis HA, controller sharding and Helm chart decisions as named deliverables before work starts.
How we build
- Deploy the chosen manifests or Helm chart into your cloud account, data center or air-gapped network, not a DeployOpen-hosted service.
- Configure SSO through your existing OIDC or SAML provider, with RBAC mapped to your team structure.
- Define repositories as Kubernetes Secrets and set admin.enabled to false once SSO users are in place.
- Test failover of Redis and API server replicas and document the results for your own review.
How we hand over
- Deliver written configuration, runbooks and an upgrade procedure aligned with the Argo CD minor release cadence.
- Document the controller sharding settings and the ARGOCD_CONTROLLER_REPLICAS values used for your cluster count.
- Provide evidence of access controls and configuration so your compliance lead can prepare for independent assessment.
- Walk your platform team through day-two operations, including backups of Kubernetes objects that hold Argo CD state.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the initial build.
- Ask in the quote which Argo CD patch lines and Kubernetes versions the retainer covers.
- Confirm with your team who owns Kubernetes control plane and etcd operations, since those sit outside the Argo CD scope unless agreed.
- Retainer and project quotes follow from the written scope, and DeployOpen does not publish a price list.
