GitOps Multi-Cluster: ArgoCD ApplicationSets vs Flux Helm

Single-cluster GitOps is largely solved. Multi-cluster GitOps — managing dozens to hundreds of clusters from a single source of truth — is substantially harder. Cluster-specific configuration, environment promotion, secret distribution, drift detection across the fleet, all become substantial problems. The two leading patterns: ArgoCD with ApplicationSets, and Flux with Helm-anchored composition. This post walks through what’s actually deployed at scale.

The multi-cluster problems#

Several substantial problems unique to multi-cluster:

Configuration parameterization. Cluster A in us-east-1 differs from Cluster B in eu-west-1 differs from Cluster C in production-restricted. The base manifests are shared; the differences need careful management.

Environment promotion. Code goes dev → staging → production. With many clusters per environment, the promotion machinery is substantial.

Cluster-targeted configuration. Some applications run only on specific clusters; some clusters have specific add-ons.

Secret distribution. Secrets need to flow to clusters; the same secret can have different values per cluster.

Drift detection at fleet scale. When 50 clusters drift in different ways, identifying and remediating drift is substantial work.

Bootstrap and lifecycle. New clusters need bootstrap; old clusters need teardown.

Observability across the fleet. Single dashboard showing application state across all clusters.

ArgoCD ApplicationSets#

ArgoCD’s ApplicationSet controller generates Argo Applications based on generators (Git, Cluster, List, plus the various).

Strengths:

• Generator model is powerful. Cluster generator + Git directory generator + matrix generator handles substantial patterns.
• Template support. ApplicationSet templates substantially reduce duplication.
• ArgoCD UI. Substantial visualization of fleet state.
• Substantial adoption — many enterprises on ArgoCD already.
• App-of-apps and ApplicationSets together handle hierarchical complexity.

Trade-offs:

• Complexity learning curve. Generators + templates + sync waves + hooks = substantial mental model.
• ApplicationSet syntax can become unwieldy at substantial complexity.

Best for: ArgoCD-anchored deployments at substantial multi-cluster scale.

Flux with Helm Composition#

Flux v2 with Helm controller and Kustomize controller provides the alternative.

Strengths:

• Helm-native. Substantial alignment with Helm-based deployments.
• Native multi-tenancy — Flux is designed for multi-tenant from the ground up.
• Substantial composability. Kustomize + Helm + GitRepository sources combine cleanly.
• Substantial Flux ecosystem — image automation, notifications, plus the various.
• Less UI-centric — works well in automation-anchored workflows.

Trade-offs:

• Less mature UI than ArgoCD.
• Smaller community than ArgoCD in 2026.

Best for: Helm-anchored deployments, multi-tenant scenarios, automation-anchored workflows.

The decision framework#

For most teams in 2026:

Pick ArgoCD with ApplicationSets when you want substantial UI, sync visibility, and ArgoCD is already in use.

Pick Flux with Helm Composition when Helm is the deployment paradigm, multi-tenancy matters, and UI is less central.

Either is workable. Both handle substantial multi-cluster at scale. The choice is more about ecosystem alignment than technical capability.

Don’t pick both. Some organizations end up with both for historical reasons; the operational complexity isn’t justified.

The specific multi-cluster patterns#

A few specific patterns that work across both tools:

Cluster registry pattern. Maintain a Git-managed registry of clusters with their attributes (region, environment, tier, plus the various). ApplicationSets or Flux generators consume this registry.

Layered configuration. Base config + environment overlay + cluster overlay. Kustomize handles this natively; Helm via values composition.

App-of-apps hierarchy. Top-level “fleet” application that creates per-cluster applications, which create per-application resources.

Sync wave ordering. Some manifests need to apply before others (CRDs before instances). ArgoCD sync waves; Flux dependsOn.

Secret management. External secret operators (External Secrets Operator, Sealed Secrets, SOPS, plus the various) distribute secrets without storing in Git. Substantial pattern.

Drift reconciliation. Both tools detect and remediate drift; specifics differ.

The operational requirements#

Multi-cluster GitOps at scale requires:

Fleet-level visibility. Dashboards showing all clusters and applications. ArgoCD UI works; Flux needs additional tooling.

Bootstrap automation. Cluster API or equivalent for cluster provisioning; bootstrap manifests for new clusters.

Disaster recovery thinking. What happens if ArgoCD/Flux is down? Can you recover individual clusters?

Substantial git workflow. Many engineers working on shared GitOps repo; branch protection, PR review, plus the various matter.

Security boundaries. Who can deploy to what cluster? RBAC and policies at multiple levels.

Cluster upgrade orchestration. Upgrade clusters in waves with verification.

What we typically see at clients#

Common patterns:

Single-cluster GitOps fully deployed; multi-cluster ad-hoc. Common transitional state.

ArgoCD with ApplicationSets at substantial enterprise scale — increasingly the default.

Flux at multi-tenant SaaS platforms — substantial alignment with platform-engineering teams.

Hybrid approaches — some teams on ArgoCD, some on Flux, some on neither.

Custom orchestration on top. At very-substantial scale (1000+ clusters), some organizations build orchestration layers on top of ArgoCD or Flux.

Where pdpspectra fits#

Our DevOps practice builds production Kubernetes platforms including multi-cluster GitOps architecture.

Related reading: the K8s network policies post, the Karpenter vs Cluster Autoscaler post, and the cluster-API multi-cloud post.

---

Multi-cluster GitOps is hard but solved. Talk to our team about your Kubernetes platform.