Install Argo CD with the Helm chart

Installing Argo CD with the Helm chart: what you configure and who maintains it

If your platform team is choosing how to install Argo CD into clusters you control, the argo-helm chart is a community maintained route to the same Argo CD project, and it exposes values for high availability, SSO and ingress. The chart packages the Argo CD components as a Helm release, so the choice is about how your team prefers to manage configuration, not about a different product. Argo CD is released under the Apache License 2.0 (SPDX: Apache-2.0), and the project itself offers no paid edition, so the cost of this route is the engineering time to own the values files, upgrades and support arrangements, not a license fee.

Teams usually choose Helm over raw manifests or Kustomize when they already run Helm releases across their clusters, want one templating and values model for every platform component, or need many switches (replica counts, Redis settings, RBAC, repository and SSO configuration) that are easier to review as a values file than as patches. Raw manifests suit a team that wants the exact upstream YAML in Git with minimal indirection, and Kustomize suits teams that prefer overlays over templates. Whichever route you pick, confirm which Argo CD version each chart release ships, since the chart version and the application version are separate numbers that must be read together.

Because the chart is community maintained, the support question comes before the install: ask who answers for chart defects, how quickly chart releases follow Argo CD releases, and whether your support contract covers the chart or only the upstream project. Plan to pin the chart version in Git, record the Argo CD image tag it deploys, and check the chart's changelog against the Argo CD release process and cadence before each upgrade, since only the three most recent minor versions receive patch releases.

Which Helm values matter for HA, SSO, ingress and TLS

This table groups the chart values that most affect availability, sign-in, traffic entry and repository setup, and states when each choice fits. Read each row as a decision: the option, what it changes, and what to confirm in the values file for the chart version you pin.

Value group	Choice and when it fits	What to confirm in the pinned chart
HA replicas and anti-affinity	Use the HA settings only on a cluster with at least three schedulable nodes, because the anti-affinity rules cannot place replicas on a smaller cluster.	Confirm the HA switch name, replica counts for each component and the anti-affinity rules in the values file for your chart version.
Application controller sharding	Add controller replicas when the number of applications or clusters outgrows one controller. Start with the default single replica for small estates.	Confirm the sharding or replica keys and whether they match the controller version you deploy.
Redis	Treat Redis as a disposable cache. Choose the bundled HA Redis for production or an external cache if your platform standard requires one.	Confirm whether the chart deploys Redis or expects an external endpoint, and the HA Redis options it exposes.
SSO through bundled Dex	Use Dex when you need connectors such as SAML, LDAP or GitHub, or when group mapping must go through its connectors.	Confirm the Dex connector block, the redirect URL and that the chart version matches the Dex image it pulls.
SSO through direct OIDC	Connect straight to an existing OIDC provider when that provider already issues the groups you need. This removes one component to run.	Confirm the OIDC issuer, client settings and the group claim name in the oidc config keys for your version.
Local admin account	Keep the built-in admin user only for first setup, then set admin.enabled to false once SSO or local users work.	Confirm the admin.enabled key and test a second administrator login before disabling admin.
Ingress and TLS termination	Terminate TLS at the ingress when your load balancer or controller handles certificates. Use passthrough when Argo CD must hold its own certificate.	Confirm the ingress class, host names and whether the chart creates separate gRPC and HTTPS routes for the CLI.
server.insecure	Set server.insecure to true only when TLS ends in front of the API server and traffic between the ingress and Argo CD is on a trusted network.	Confirm the key name and the TLS settings on the ingress, since a mismatch breaks CLI or UI access.
Repository definitions	Define repositories as Kubernetes Secrets. Since 3.0, argocd-cm no longer carries repository configuration, so older values files that set it need changes.	Confirm that no repository entries remain under configs in the values file and that credentials are supplied as labeled Secrets.

How to install Argo CD with Helm in five steps

This sequence takes you from a checked cluster to a verified Argo CD installation from the community argo-helm chart, with versions pinned, values reviewed in Git, CRD handling decided and admin access locked down before any application goes live.

Confirm cluster shape and IPv6 assumptions
Your platform engineer checks that the target cluster has at least three nodes if you plan to use the high availability manifests, since pod anti-affinity rules need room to spread replicas. Confirm the cluster is not IPv6-only, because Argo CD's high availability documentation states those clusters are not supported. Record the node count, Kubernetes version and network model in your change ticket. This step is done when someone other than the author has reviewed and signed off those facts.
Pin chart and Argo CD versions together
Choose a chart version from the argo-helm repository and confirm which Argo CD application version it deploys by default, then set the image tag explicitly in your values so the two cannot drift. Check the Argo CD release process for the current minor release and the patch releases still maintained, and avoid release candidates in production. Store the chosen chart version and image tag in Git. This step is done when the pinned pair appears in a committed file and matches the upgrade notes you plan to follow.
Render and review values in Git
Write your values file for high availability, ingress, TLS and SSO, keeping the admin account enabled only for first login. Run helm template against the pinned chart, save the rendered manifests as an artifact and have a second engineer review the diff against your expectations. Confirm that repository definitions are Kubernetes Secrets rather than entries in argocd-cm, since Argo CD 3.0 removed repository configuration from that ConfigMap. This step is done when the rendered output contains no unreviewed changes and the values file is merged to the main branch.
Install into a dedicated namespace with CRD handling decided
Create a dedicated namespace, then run helm install or upgrade with the reviewed values and the pinned chart version. Decide explicitly whether the chart manages the Argo CD custom resource definitions, and record that decision because removing the release later can affect applications and their CRDs. Restrict who holds the permissions to install or upgrade this release. This step is done when the release reports deployed and the CRDs present match the version you decided on.
Verify pods, login, admin lockdown and a test sync
Check that all Argo CD pods reach Running and Ready, that the Redis cache and application controller replicas are scheduled across nodes as expected, and that the UI and CLI reach the server over TLS. Log in through your configured SSO provider or a local user, then set admin.enabled to false once those accounts work, as the user management documentation recommends. Finally, deploy a small test application from a Git repository you control, confirm it reaches Synced and Healthy, and remove it. This step is done when the test sync completes and the admin account no longer logs in.

Managing CRDs when the chart installs or upgrades

On an empty cluster there are no existing Argo CD CRDs to reconcile, so the work is mostly about fixing versions and naming before anything is created. The chart installs the Argo CD custom resource definitions along with the controllers, and the first install creates them for the first time. Keep the set of values and the release name under version control so later upgrades and removals target the same objects.

Pin the chart version: install an exact chart version so the CRD set matches the Argo CD release you tested.
Fix the namespace and release name: use the same namespace and release name in every environment so later commands act on the same objects.
Record what was installed: list the CRDs with kubectl get crd and keep the output in your change record.
Wait for establishment before creating workloads: apply Application manifests only after the CRDs report as established and the release shows as deployed.
Check how resources are tracked: Argo CD 3.0 made annotation-based resource tracking the default, per the Argo CD 2.14 to 3.0 upgrade notes, so confirm which tracking mode your version uses before adding other tooling to the namespace.

Before you move on, confirm that the pinned chart version, the Argo CD application version and the CRD versions all come from the same release line.

Security settings to set at install time

The community Helm chart installs a working Argo CD, but several security settings only hold if you set them during installation. Each card below is a setting or risk to decide on before the first sync, not after the cluster has users and repositories.

Disable the built-in admin user

The built-in admin account is meant for first-time setup only. Once SSO or local users work, set admin.enabled to false in your values so the shared password stops being a standing way in. Before you disable it, confirm that at least one SSO group maps to an administrator role and that someone has tested that login end to end. Keep a documented break-glass procedure for the case where SSO is down.

JWT-only API authentication

Argo CD authenticates API requests only with JSON Web Tokens, so there is no separate API key model to manage at install time. Your job is to confirm that TLS covers the traffic between the UI, API server and internal components, and that your ingress does not terminate TLS in a way that exposes tokens on untrusted hops. Check token lifetimes and who can generate tokens for automation accounts.

Credential redaction and log access

Argo CD redacts cluster, Git and OAuth2 credentials from API responses and logs, which limits what a reader of logs can recover. Verify this in your own cluster by searching controller and server logs for a test credential after setup. Pair it with the RBAC default that log access requires an explicit logs get permission, so that viewing application logs is a grant you can audit.

Repo-server runs Helm and Kustomize

The repo-server renders Helm charts and Kustomize overlays from repository content, so a malicious or careless manifest can influence what runs in the cluster. Restrict which repositories Argo CD can read, keep repositories in Kubernetes Secrets as the 3.0 upgrade notes require, and review who can change the repository list. Treat out-of-tree file access as a risk to control in your values and project settings.

RBAC defaults after the 2.14 to 3.0 change

Since Argo CD 2.14 to 3.0, update and delete RBAC apply only to the application itself, not to the resources it manages. Read logs needs an explicit logs get permission. Write these defaults into your policy.csv in the values file and test them with two accounts: one with a read-only role and one with a deploy role. Confirm that Dex-based RBAC matches on federated_claims.user_id if you use bundled Dex.

Keep chart secrets out of plaintext values

Chart values often end up in Git, so the admin password hash, OIDC client secret and repository credentials should never be written there in plain text. Reference existing Kubernetes Secrets created by your secret tooling, and confirm the chart version reads them the way your values expect. Check that rendered manifests and Helm release history do not expose the same values.

Keeping chart and Argo CD versions aligned over time

The chart and the Argo CD image are two version lines that must be kept in step. The argo-helm chart has its own version number, and each chart release pins a default Argo CD image tag in its values. Before any upgrade, check the chart's pinned image tag against the Argo CD release you intend to run, and confirm whether your values override global.image.tag or the component-level image settings. A chart bump that silently changes the image, or an image override that lags the chart, is the most common source of drift between what you think is running and what is running.

Track the Argo CD release process and cadence and the argoproj/argo-cd releases on GitHub. The project ships a minor release on a quarterly cadence and patches only the three most recent minor lines, so a version that falls out of that window stops receiving fixes. At the time of the supplied facts, the latest patch line was v3.5.5, with v3.4.11 and v3.3.16 also maintained. Confirm the current list before each planning cycle, because your own pinned version determines how urgent a move is.

Read the upgrade notes before crossing a minor version. The 2.14 to 3.0 notes are the reference case: update and delete RBAC now apply only to the application itself, logs access needs an explicit logs, get permission, annotation-based resource tracking is the default, repositories must be defined as Kubernetes Secrets, and Dex RBAC uses the federated_claims.user_id claim. Test each chart bump in a non-production cluster that mirrors your SSO and project setup, and record the chart version, image tag, values file revision and Git commit in a change record for every environment. That record is what lets you answer which version runs where when an incident or audit asks.

Questions teams ask before installing Argo CD with Helm

Does installing Argo CD with Helm cost money in license fees?

No. Argo CD is released under the Apache License 2.0, and the project itself does not offer a paid edition, so the software carries no license fee. The costs come from the work around it: the people who design the values file, configure SSO and ingress, test the install, and run it afterward, plus the cluster capacity Argo CD consumes. Ask any vendor or partner to separate one-time build effort from recurring support, and to state which Argo CD components, such as Dex, Redis or the ingress controller, are included in the quote. Confirm with your own licensing team whether any surrounding component you choose carries its own terms.

How long does a first Argo CD Helm install take?

The helm command itself is quick, so duration depends on scope. A basic install on a test cluster is mostly a values file and a smoke test. Duration grows with high availability, which needs at least three nodes for the pod anti-affinity rules in the HA manifests, with SSO, which requires identity provider metadata, group mapping and login testing, and with ingress and TLS, which depend on DNS, certificate issuance and your network policy. Change approval windows and access requests often take longer than the technical work. Ask for a written scope with a timeline that lists each of these items separately.

What does the work need from our team before it starts?

Plan for access and inputs before any engineering begins. You will need administrative access to the target cluster or a service account with rights to create namespaces, CRDs, RBAC objects and workloads, plus a decision on which namespace Argo CD will use. For SSO, you need metadata or client details from your identity provider, the group claims you want mapped to Argo CD roles, and a named owner who can approve the redirect URLs. For ingress, you need DNS records, a hostname for the UI and CLI, and either a certificate authority or a cert-manager setup. Also provide the Git repository location and credentials that Argo CD will read from.

Can one of our engineers install Argo CD with Helm alone?

A capable platform engineer can install a single-cluster, non-HA Argo CD from the argo-helm chart using the project's documentation. The harder parts are the decisions that affect later security and operations: whether to use the bundled Dex or an existing OIDC provider, how to store repository credentials as Kubernetes Secrets, how to set admin.enabled to false after SSO works, how TLS terminates, and how CRDs are handled when the chart is upgraded. If no one on your team has run Argo CD before, or the install must pass a change review, plan for a second reviewer and a documented test plan. The work is practical to do in-house when the team has time to test each decision.

When should we bring in an implementation partner for Argo CD?

Bring in a partner when the install has to meet requirements your team has not met before, or when the timeline does not allow internal learning. Typical triggers include multi-cluster or multi-tenant design, SSO across several identity providers, air-gapped clusters, regulated change control that needs evidence, or a migration from another GitOps tool or from Helm releases already in production. A partner should work from a written scope with named deliverables, acceptance criteria and a handover plan so your team can operate the result. DeployOpen implements Argo CD in infrastructure you control and prepares documentation and configuration for review, but it does not issue audit reports or certifications.

How are Argo CD and chart upgrades handled after installation?

Upgrades need a plan because Argo CD minor releases arrive about every three months, the project patches only the three most recent minor versions, and major upgrades carry breaking changes. The upgrade notes for 2.14 to 3.0, for example, changed RBAC for update and delete actions, moved repositories from argocd-cm into Kubernetes Secrets, and changed the default resource tracking method. Keep the chart version and the Argo CD image version aligned with the compatibility notes in each release, test in a staging cluster first, and review CRD changes before applying them. Ask any partner whether upgrades, testing and rollback are included in the initial scope or sold as a retainer.

What a DeployOpen Helm installation covers

A DeployOpen Helm installation of Argo CD ends with a values file committed to your Git repository, not with a running release that only exists in a cluster. That file holds the chart version pin, the Argo CD image tag, the configs.cm and configs.rbac settings, the server.ingress block, and the redis-ha or controller.replicas choices. Documented version pins sit beside it, so your team can see which argo-helm chart version and which Argo CD minor release were tested together, and which upgrade path the next change must follow. Scope, deliverables and timelines are agreed in writing before work starts, and DeployOpen does not publish a price list, so the quote follows from the written scope rather than from a rate card.

Three decisions are agreed in writing before the values file is finalized. The first is SSO: whether Argo CD talks directly to your OIDC provider or through the bundled Dex, with the admin.enabled setting planned so the local admin account is disabled once SSO works. The second is ingress and TLS, where the hostnames, the termination point and the gRPC path for the CLI are named so the browser and CLI both work. The third is high availability. The HA manifests need at least three nodes because of pod anti-affinity rules, so confirm your node count and zone layout before choosing the HA values. Confirm IPv6 is not required, since IPv6-only clusters are not supported.

The handover includes a verification checklist and operator notes. The checklist covers login through each identity path, a test sync of a sample application, confirmation that repositories are defined as Kubernetes Secrets, and a check that the chart's CRDs were installed and remain under the install process you chose. The notes record the upgrade steps for each minor release, the release cadence your team will track in the Argo CD release process, and the owner of each value. Ask your provider to show the checklist results and the open items before sign-off.

How DeployOpen scopes, delivers and supports Argo CD installs

DeployOpen plans and installs Argo CD from the community argo-helm chart inside the cloud accounts, data centers or air-gapped networks you control. Each engagement starts with a written scope that fixes the chart version, Argo CD version, values, SSO design and ingress approach before any cluster is touched.

How we scope

Confirm the target clusters, namespaces and whether one Argo CD serves one team or many.
Agree the argo-helm chart version and the Argo CD application version that the chart installs.
Record SSO, ingress and TLS choices, HA replica counts and CRD handling in the written scope.

How we build

Write Helm values files for HA, admin.enabled, repositories as Kubernetes Secrets and RBAC policy.
Test install, upgrade and rollback of the chart on a non-production cluster before production.
Verify SSO login, project boundaries and redis-ha behavior against the agreed acceptance checks.

How we hand over

Deliver the values files, pinned chart and image versions, and the install runbook as versioned files.
Document the CRD upgrade steps, admin account disablement and break-glass access procedure.
Walk your platform team through the upgrade path that keeps chart and Argo CD versions aligned.

How we support

Offer ongoing support, version upgrades and continuous testing as a retainer after handover.
Review each new Argo CD minor release and chart change against your pinned values before rollout.
Confirm support terms, response expectations and included upgrades in the written scope with your DeployOpen contact.

Installing Argo CD with the community Helm chart