One central cluster holds kubeconfigs for the rest and pushes desired state into them. It works while you have three clusters in the same network. At the scale of a bank, an insurer, or an edge fleet, the pattern breaks in three places at once.
Where hub-and-spoke breaks
Blast radius. The hub holds an admin kubeconfig for every spoke. Compromising any component of the control cluster compromises the entire fleet, not «an incident in one environment». Token rotation barely helps: while the token is valid, the hub has full access to prod.
Network model. The hub needs direct inbound access to every spoke's API server. On AWS that means cross-region security groups and peerings; on edge infrastructure, where the spoke sits behind NAT, it doesn't work at all without a VPN or a tunnel.
Compliance. Regulated industries forbid inbound traffic into production clusters from any external network — and the hub is external in this picture. An auditor's requirement, not an architectural constraint; hub-and-spoke doesn't work around that barrier.
On top of that comes an operational ceiling: a single application-controller pod hits CPU and memory limits at 5000+ Applications. ArgoCD v3 (early 2026) ships horizontal scaling for the controller; before that you shard via ARGOCD_CONTROLLER_REPLICAS with round-robin by cluster ID. With fifty spokes, hundreds of Applications each, the control plane becomes the bottleneck without sharding.
Per-cluster local
Every cluster runs its own ArgoCD that watches only its subset of the gitops repository. The blast radius of a compromise is a single cluster. The network model is trivial: ArgoCD ↔ K8s API is always local, through https://kubernetes.default.svc. Sharding isn't needed, because 5000 Applications never land on the same controller — they're physically split across clusters.
The price is no single pane of glass and N instances to upgrade in sync. The ArgoCD UI only shows the local cluster; the on-call engineer with three prods keeps three tabs open. The ApplicationSet matrix generator works locally, but only with exactly two child generators — anything else is no longer supported. The local cluster also has to be re-registered through an explicit cluster Secret with a unique name, because the default in-cluster entry breaks matching on {{name}}.
Per-cluster local wins where compliance forbids centralisation, where the spoke's network is untrusted, and where the fleet doesn't need a central audit console in the first place.
Pull-mode: the third option
Sveltos Addon Controller in pull-mode (since v1.0.0, hardened in v1.4.0) flips the direction: the spoke initiates an outbound connection to the hub and pulls its desired state. The hub no longer holds admin tokens for spokes — it holds SA tokens that the spoke uses to read its own configuration from the hub. Compromising the hub becomes compromising a read-only API, not admin access to the fleet.
Use cases — regulated industries (banks, healthcare), edge and IoT (POS systems, factory floors, ships with intermittent connectivity), air-gapped environments (outbound only), multi-cloud with a single GitOps model across AWS/GCP/Azure/on-prem. ArgoCD core is moving in the same direction through argocd-agent (KubeCon EU 2025) and the Akuity Platform, but in early 2026 Sveltos pull-mode is the most mature production implementation.
When to pick which
Per-cluster local — air-gapped, edge, compliance-restricted spokes, no network connectivity between clusters. A good default for a team that doesn't need a single dashboard.
Hub-and-spoke — centralised governance, a fleet of up to a dozen clusters in the same network, a team that benefits from one UI. Plan controller sharding ahead if you're heading toward 1000+ Applications.
Pull-mode — anywhere hub-and-spoke breaks against compliance or the network model, and per-cluster local doesn't fit because you need a central control plane.
A hybrid is viable: ArgoCD hub-and-spoke for app delivery in the trusted segment, Sveltos pull-mode for the compliance-restricted segment. Not a starting architecture, an outcome of evolution, when part of the fleet moves to the edge or into a regulated perimeter.
A separate case is managed ArgoCD on EKS Capabilities. AWS runs the installation, upgrades and HA; the cost is that Argo lives outside the cluster, https://kubernetes.default.svc as a destination doesn't work, and EKS has to be registered as a remote target. Identity Center is mandatory. It's hub-and-spoke with zero ops on the hub itself, but with the same compliance limits as a self-hosted hub.