Choosing Argo CD or Flux for 40 Clusters with Intermittent Edge Connectivity

Isolation is a first-class requirement and both tools can meet it, differently. Argo CD uses AppProjects plus RBAC bound to SSO groups: a project restricts which repos may be sources, which cluster/namespace pairs are valid destinations, and which resource kinds may be created. A team bound to a project literally cannot express an Application targeting another team's namespace. The residual risk is shared rendering: one repo-server renders everyone's manifests, so disable custom plugins and config-management plugins for untrusted teams, and scope repo credentials per project. Flux isolates by impersonation: each tenant's Kustomization reconciles under a service account limited by RBAC, which is arguably stronger at the cluster level but has no equivalent single pane of glass for "who may deploy what."

The 85% repo-server number is a rendering-throughput symptom, not a verdict on the tool. 600 Applications each re-rendering Helm charts on a three-minute loop saturates a single repo-server. Remedies: scale repo-server replicas and shard repositories across them, raise the parallel render limit, enable manifest generation caching, lengthen reconciliation intervals for stable apps, and reduce Helm usage in the hottest paths (pre-render or Kustomize). Do this before concluding Argo CD cannot carry the load. Flux is cheaper per app because it caches source artifacts and does less per-reconcile work, but its kustomize-controller still renders, and at larger scale both need sharding.

Image automation: Flux has first-class image-reflector/image-automation controllers that write tag updates back to Git. Argo CD's equivalent (Image Updater) is a separate component that likewise commits to Git; either way, configure it to open pull requests rather than push to protected branches, or you reintroduce the review gap.

Recommendation: Argo CD as the primary control plane for the 15 non-edge clusters, where the UI, project model and audit view directly answer the compliance requirement, with a scaled/sharded repo-server. For the 25 edge sites, the deciding factor is reachability: classic Argo CD requires the control plane to reach each cluster's API server, which is a poor fit for links that drop for hours. If Argo CD's agent-based mode is mature enough in your version to invert that direction, standardize on Argo CD; otherwise run Flux on the edge sites and treat the two as one partitioned fleet. Verify current agent maturity against the release you will actually run before committing.

Behaviour. In a pull model the cluster is the client: when connectivity drops, the agent keeps running with the last successfully fetched desired state, continues to reconcile locally against its cached artifacts, and retries the source on a loop. Nothing is "paused" from the agent's perspective - it simply cannot see new commits. On reconnect it fetches the backlog and converges, and a Git commit made during the outage is applied then, in order, without a human. That retry-forever characteristic is what makes the model resilient to flaky links.

Implication for the principle. Continuous reconciliation means software agents continuously observe and attempt to reconcile; it does not promise that the network is always up. An agent that keeps retrying and converges after reconnection satisfies the intent. The honest description is "continuous intent, eventual convergence bounded by connectivity" - and you must document the bound. Six hours of staleness on a retail site may be acceptable for a pricing service and unacceptable for a payment terminal; that is a risk decision per workload, not a tooling decision.

Drift on site is the sharper problem. During an outage a technician may change something locally (scale a deployment, patch a config). On reconnect, a self-healing agent will revert it without asking, which is correct behaviour and a nasty surprise if unplanned. Options: make edge workloads read-only and communicate that local edits do not survive; keep self-heal on and alert on the reverted drift so the change is visible in the audit trail; or, for genuinely site-specific state, model it as a declared object in Git updated through a controlled process rather than as ad-hoc local edits.

Also plan the observability gap: while a cluster is unreachable you cannot report its live state, so "what is deployed where" has a hole. Show the last-known state with an explicit stale/unreachable marker and the timestamp of the last successful reconciliation - an auditor will ask, and a silently empty cell is worse than a labelled one.

Build a two-source audit trail, joined at the commit SHA.

• Change record lives in Git: PR, approver identity from SAML, merge commit, and the digest that was promoted. This is the authoritative "who changed what," and it exists whichever tool you use.
• Application record lives in the controller: sync events, the revision applied, health transitions, and the live manifest of every resource. For Argo CD this is the Application history plus its event stream; export both to the SIEM rather than relying on the UI's retention window. For Flux, emit events and use a UI layer over the same data.
• Join key: stamp the commit SHA into the applied resources (an annotation) so that for any running object you can go from live pod to commit to PR to approver. That closes the loop auditors actually test: "show me why this is running in production."

Single view. Argo CD gives it natively: one list of Applications with cluster, namespace, sync and health, plus a resource tree per app. Flux needs an add-on (Weave GitOps-style UI or dashboards) for the same picture. That is the strongest argument for Argo CD as the system of record for the 15 reachable clusters, with edge state surfaced through the same UI where agent mode allows, or explicitly labelled as a separate fleet.

Cost of running both. Doubled controllers, doubled upgrade and CVE burden, two RBAC models to review, two sets of dashboards, and - the real danger - two possible owners for the same resource, which produces flapping where each tool reverts the other's work. If you go hybrid, partition by cluster set with a written rule that no cluster is ever reconciled by both, and name one tool as the audit system of record. If a single tool can meet the edge constraint (agent mode), the second tool is pure overhead; the UI objection to Flux is easier to solve than the operational cost of two control planes.