Skip to content

PATTERN Cited by 1 source

ArgoCD multi-source Helm + values

Shape

An Argo CD Application CRD with two sources entries — one pointing at the upstream Helm chart repository, the other at the customer's own values repository. The Helm source references the values source by name ($values/...) via the values source's ref: label:

# argocd-rpcn-standalone.yaml (Redpanda Connect standalone example)
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: redpanda-connect-standalone
  namespace: argocd
spec:
  project: default
  destination:
    server: <EKS controlplane endpoint>
    namespace: redpanda-connect
  sources:
    # 1) Upstream Helm chart source
    - repoURL: https://charts.redpanda.com
      chart: connect
      targetRevision: 3.1.0
      helm:
        releaseName: redpanda-connect-standalone
        valueFiles:
          - $values/standalone/standalone-mode.yaml
    # 2) Customer repo with values file
    - repoURL: <your project repository>
      targetRevision: main
      ref: values
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Why two sources

Separate ownership, separate cadence. The upstream chart is maintained by the vendor (Redpanda, in the canonical example) on its own release cycle — chart version 3.1.0 pins that cadence into your deployment. The customer values live in the customer's own repo, deployed on the customer's own cadence. Neither cadence blocks the other.

Avoid forking the chart. The alternative is to copy the chart into your repo and edit it — a fork. Forks diverge from upstream fixes + features, impose vendor-upgrade burden on the customer, and give up reviewability. Multi-source keeps you on the upstream chart verbatim; only your values live in your repo.

Version-pin the chart. targetRevision: 3.1.0 pins the Helm chart version explicitly. Upgrades are Git commits that change the pin — reviewed, auditable, revertable. Contrast with "latest" or "main", which gives up version control.

Environment-specific values via different values files in one values repo. Same Application can reference different values files per environment — standalone/standalone-mode.yaml, standalone/standalone-mode-prod.yaml, etc. — while the chart source stays common.

Preconditions

  • Argo CD supporting multi-source Applications. The multi-source feature was GA in Argo CD v2.6 (early 2023); older clusters need to upgrade or use the single-source workaround (fork the chart).
  • ref: on the values source. The values source must declare ref: <name> (typically values); the Helm source references it as $<name>/... in valueFiles.
  • Values files live at stable paths. Because the chart source references them by path in the values repo, renames of the path require coordinated PRs.

Seen in

  • sources/2025-12-02-redpanda-operationalize-redpanda-connect-with-gitops — canonical wiki instance. Tutorial ships two Argo CD Applications using this pattern — one for standalone Redpanda Connect (argocd-rpcn-standalone.yaml) pulling chart 3.1.0 from charts.redpanda.com + values from the customer's fork of redpanda-connect-the-gitops-way; one for streams mode (argocd-rpcn-streams.yaml) using the same two-source split. Rationale verbatim: "This pattern decouples maintenance of the Helm chart from your application configuration."

Trade-offs

  • Two repos to manage — upstream chart repo + customer values repo. For teams that don't own a chart, this is near-zero cost; for teams that want to version charts + values together, it's unnecessary split.
  • selfHeal: true with prune: true — enabled in the canonical tutorial. Aggressive drift correction (any non-Git mutation is reverted); prune removes resources that disappear from the manifest set. Good defaults for pure-GitOps shops; risky for teams that mix manual-and-GitOps-managed resources in the same namespace.
  • Cross-repo PR coordination on chart + values changes — a chart upgrade that requires new values keys requires a coordinated PR in both repos. The targetRevision: 3.1.0 pin + merge-order discipline handle this, but the operational overhead is real for vendor-chart teams.
Last updated · 470 distilled / 1,213 read