Argo Helm

High Availability

By default, this chart installs a non-HA version. To run in High Availability mode, use the example values provided in the repository (ci/ha-values.yaml) and refer to the upstream Operator Manual for scaling details.

Workflow Controller Scoping

By default, controller.instanceID.enabled is set to false, meaning the controller acts upon any workflow in the cluster. To deploy multiple scoped controllers, set controller.instanceID.enabled to true and configure the instanceID to limit the controller's scope.

The Argo Helm charts use Helm's built-in .Capabilities object to detect cluster features, such as the presence of ServiceMonitors (monitoring.coreos.com/v1) or specific Kubernetes API versions.

If you are using helm template instead of helm install, you must manually provide the available API versions to ensure the templates render correctly. Otherwise, the logic checking for these capabilities may fail or produce incorrect manifests.

# Use the --api-versions flag with helm template
helm template argocd \
  oci://ghcr.io/argoproj/argo-helm/argo-cd \
  --api-versions monitoring.coreos.com/v1 \
  --values my-argocd-values.yaml

You can pass configuration values directly to the Argo CD internal ConfigMaps using the configs key.

• Values under .Values.configs.cm are passed to the argocd-cm ConfigMap.
• Values under .Values.configs.params are passed to the argocd-params-cm ConfigMap.

The chart supports two Custom Resource Definition (CRD) variants:

1. Full CRDs (Default): Includes complete OpenAPI schemas for better validation and type safety. These are approximately 11MB uncompressed. The chart uses a pre-install/pre-upgrade hook Job to apply these using kubectl apply --server-side --force-conflicts to avoid Helm Secret size limits.
2. Minified CRDs: Uses x-kubernetes-preserve-unknown-fields to accept any fields. These are smaller but provide almost no validation.

To use minified CRDs instead of the default full CRDs, use the crds.full=false value.

helm install my-release argo/argo-workflows --set crds.full=false

When deploying the argo-cd chart using an Argo CD Application resource, you must define the bcrypt-hashed admin password under helm.values rather than helm.parameters.

Reason: Argo CD performs variable substitution on parameters, which will corrupt the $ characters used in bcrypt hashes.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: argocd-testing
spec:
  destination:
    namespace: testing
    server: https://kubernetes.default.svc
  project: default
  source:
    chart: argo-cd
    repoURL: https://argoproj.github.io/argo-helm
    targetRevision: 3.21.0
    helm:
      values: |
        configs:
          secret:
            argocdServerAdminPassword: $2a$10$H1a30nMr9v2QE2nkyz0BoOD2J0I6FQFMtHS0csEg12RBWzfRuuoE6

There are two primary strategies for choosing a namespace for the installation:

1. Install into the Argo CD namespace (Recommended): This is the simplest approach and requires minimal configuration.
2. Install into a separate namespace: This provides better workload isolation but requires several manual configuration steps.

The Argo Rollouts dashboard can be enabled during installation by setting dashboard.enabled=true.

To access the dashboard locally after installation, use kubectl port-forward to map the service to a local port:

1. Run the port-forward command: kubectl port-forward service/argo-rollouts-dashboard 31000:3100
2. Open your browser and navigate to localhost:31000.

Security Warning: Changing the service type via dashboard.service.type to LoadBalancer or NodePort exposes the dashboard. The dashboard is intended as a local view and should be protected by network access controls or an OAuth proxy if exposed.

In version 7.0.0, the type of .Values.configs.clusterCredentials changed from a list to an object.

Old format (list):

configs:
  clusterCredentials:
    - mycluster:
      server: https://mycluster.example.com
      labels: {}
      annotations: {}

New format (object):

configs:
  clusterCredentials:
    mycluster:
      server: https://mycluster.example.com
      labels: {}
      annotations: {}

To install Argo Workflows using Helm, first add the argo repository and then run the install command. For a deployment that most closely matches the Argo CLI behavior, it is recommended to deploy in the argo namespace.

helm repo add argo https://argoproj.github.io/argo-helm
helm install my-release argo/argo-workflows

To install Argo CD using Helm, first add the argo repository and then run the helm install command.

Prerequisites:

• Kubernetes: >=1.25.0-0
• Helm: v3.0.0+

$ helm repo add argo https://argoproj.github.io/argo-helm
$ helm install my-release argo/argo-cd

In version 2.0.*, CRDs were moved to the templates folder to allow Helm to manage them. If you have existing CRDs that were installed before this change and want to adopt them into your Helm release, you must label and annotate them so Helm recognizes them as managed resources.

Replace <YOUR_NAMESPACE> with your target namespace and <YOUR_HELM_RELEASE> with your Helm release name.

for crd in "eventbus.argoproj.io" "eventsources.argoproj.io" "sensors.argoproj.io"; do
  kubectl label --overwrite crd $crd app.kubernetes.io/managed-by=Helm
  kubectl annotate --overwrite crd $crd meta.helm.sh/release-namespace=<YOUR_NAMESPACE>
  kubectl annotate --overwrite crd $crd meta.helm.sh/release-name=<YOUR_HELM_RELEASE>
done

To install Argo Rollouts using Helm, first add the argo repository to your local Helm installation, then run the helm install command. This installs the Argo Rollouts controller, which enables progressive delivery for Kubernetes.

Prerequisites:

• Kubernetes 1.7+
• Helm v3.0.0+

$ helm repo add argo https://argoproj.github.io/argo-helm
$ helm install my-release argo/argo-rollouts