FluxCD vs ArgoCD: Architectural Comparison

A deep comparison of the architectural differences between FluxCD and ArgoCD for experienced Kubernetes platform engineers.

Flux Architecture

Flux is a set of independent controllers, each owning a CRD:

Sources (what to watch)          Reconcilers (what to do with it)
─────────────────────           ─────────────────────────────────
GitRepository                   Kustomization
OCIRepository                   HelmRelease
HelmRepository
Bucket

Each controller runs independently. A Kustomization references a GitRepository as its source. A HelmRelease references a HelmRepository + chart. Dependencies between Kustomizations are expressed via dependsOn. There’s no central server — each controller watches its own CRDs and reconciles independently. State lives in the CRDs themselves (status subresource). You query state with kubectl get kustomization or flux get all.

The reconciliation loop is: source controller polls git → updates GitRepository status with new artifact revision → kustomize controller sees the new revision → applies manifests → updates Kustomization status.

Argo Architecture

Argo has a fundamentally different design. Instead of distributed controllers, it’s a centralized application server with several components:

┌─────────────────────────────────────────────────┐
│                  argocd-server                    │
│         (API server + Web UI + gRPC)             │
└──────────────────┬──────────────────────────────┘
                   │
┌──────────────────┴──────────────────────────────┐
│          argocd-application-controller            │
│    (single controller watching ALL Applications)  │
└──────────────────┬──────────────────────────────┘
                   │
┌──────────────────┴──────────────────────────────┐
│             argocd-repo-server                    │
│   (clones repos, renders manifests, caches them)  │
└──────────────────┬──────────────────────────────┘
                   │
┌──────────────────┴──────────────────────────────┐
│                    Redis                          │
│          (manifest cache, revision cache)          │
└───────────────────────────────────────────────────┘

The Core CRD: Application

Where Flux separates source and reconciliation into distinct CRDs, Argo collapses everything into a single CRD: Application. An Application defines both where to get the manifests and where to put them:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
  namespace: argocd          # Applications live in the argocd namespace
spec:
  source:                     # Flux's GitRepository + Kustomization combined
    repoURL: https://github.com/org/repo
    targetRevision: main
    path: deploy/overlays/prod
    kustomize:                # or helm:, or directory:, or plugin:
      namePrefix: prod-
  destination:                # which cluster and namespace to deploy to
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:                # equivalent to Flux's auto-reconciliation
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

That’s one object doing what Flux does with two (GitRepository + Kustomization).

Mapping Flux Concepts to Argo

Flux	Argo	Notes
`GitRepository`	`spec.source.repoURL` + `targetRevision`	Not a separate CRD. Embedded in `Application`.
`Kustomization`	`Application` with `spec.source.kustomize`	The Application is the reconciler.
`HelmRelease` + `HelmRepository`	`Application` with `spec.source.chart` + `spec.source.repoURL`	Again, one object.
`dependsOn`	`sync-wave` annotations or `AppOfApps` pattern	Argo uses annotations on the resources themselves, not on the Application.
`spec.interval` (per-resource)	Global `timeout.reconciliation` (default 3 min)	You can’t say “check this app every 30s but that one every 10m.”
Source controller (independent)	`argocd-repo-server` (shared service)	Single process cloning all repos, rendering all manifests. Shared cache in Redis.
Multiple independent controllers	Single `application-controller`	One controller reconciling every Application. Can run in HA with sharding, but it’s still one logical controller.
Status on CRD	Status on CRD + Redis cache + API server state	Three places state can live, which is where the staleness comes from.
`flux get all`	`argocd app list` or the Web UI

AppProject (Argo’s Multi-Tenancy)

Argo adds a second CRD, AppProject, for access control:

apiVersion: argoproj.io/v1alpha1
kind: AppProject
spec:
  sourceRepos:
    - 'https://github.com/org/*'
  destinations:
    - namespace: 'team-a-*'
      server: '*'
  clusterResourceWhitelist:
    - group: ''
      kind: Namespace

This constrains which repos an Application can pull from and which namespaces it can deploy to. Flux doesn’t have an equivalent — multi-tenancy in Flux is handled by running separate Flux instances per tenant or using Kubernetes RBAC on the service accounts the controllers use.

ApplicationSet (Argo’s Templating)

Argo’s third CRD, ApplicationSet, generates multiple Application objects from templates:

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
spec:
  generators:
    - git:
        repoURL: https://github.com/org/repo
        directories:
          - path: 'envs/*'
  template:
    spec:
      source:
        repoURL: https://github.com/org/repo
        path: ''
      destination:
        namespace: ''

This generates one Application per directory. Flux doesn’t have a direct equivalent — you’d use Kustomize overlays or a script generating Kustomization CRDs.

The Architectural Tradeoff

Flux is decoupled. Sources and reconcilers are independent controllers with independent lifecycle, independent failure modes, independent scaling. State lives in CRDs. There’s no shared cache to go stale, no central API server to bottleneck, no Redis to lose. The cost is: no UI, no centralized view, more CRDs to manage.

Argo is centralized. One API server, one controller, one repo server, one cache. Everything flows through the same pipeline. The benefit is a unified view (the UI, the API, argocd app list). The cost is exactly what many operators experience: the cache (Redis), the API server, and the UI can all disagree about the current state. When the repo-server is slow cloning, or the controller has a queue backlog, or Redis has stale entries, the UI shows you a lie.

Why the Argo UI Goes Stale

The stale UI problem isn’t a bug — it’s the architecture. You have a manifest cache in the repo-server, a revision cache in Redis, state in the controller’s in-memory working set, and the UI polling the API server. That’s four places state can be out of sync. Argo’s proxy doesn’t support WebSockets (open feature request as of early 2026), so the UI is fundamentally polling-based — always showing a snapshot that’s some interval behind reality.

Flux has one place state lives: the CRD status, written by the controller that owns it, queryable with kubectl. There’s nothing to go stale because there’s no cache layer between you and the source of truth.

Every Point Where Argo State Can Diverge

Argo maintains state in multiple independent locations. Each is a point where reality and Argo’s view of reality can disagree:

Git repository (the source of truth) — The actual desired state. Argo doesn’t watch git in real-time; it polls on a global interval (default 3 minutes). Between polls, git and Argo’s view of git are diverged by definition.
Revision cache (Redis) — The argocd-repo-server caches git refs from git ls-remote in Redis with a default TTL of 3 minutes. If a push lands between cache refreshes, Argo doesn’t know about it. A soft refresh checks this cache; only a hard refresh bypasses it.
Manifest cache (Redis) — Rendered manifests (the output of running Kustomize, Helm, or directory rendering on the git source) are cached in Redis. If you change a Helm values file or a Kustomize overlay, the manifest cache can serve stale rendered output until it expires or is explicitly invalidated.
Application controller in-memory working set — The argocd-application-controller maintains its own in-memory representation of every Application’s current and desired state. This working set can diverge from both Redis and the actual cluster state when the controller’s internal queue backs up, deadlocks, or falls behind under load.
Cluster state cache (application controller) — The controller caches the live state of Kubernetes resources in the target clusters. This cache is refreshed by watching the Kubernetes API, but cache invalidation events can trigger infinite retry loops (see deadlock issues below), causing the cached cluster state to freeze at a point in time.
API server state (argocd-server) — The argocd-server serves the UI and CLI. It queries the application controller and repo-server to assemble its responses, but it has its own request/response cycle. The API server can return data that was current when the controller last reported but is no longer current by the time the response reaches the client.
UI state (browser) — The Web UI polls the API server. Since Argo’s proxy doesn’t support WebSockets, the UI is always showing a polling snapshot. Between polls, the UI is stale. Users acting on stale UI state (clicking sync, delete, restart) are operating on a view of the world that may no longer be accurate.
Diff state — Argo computes a diff between desired state (from the manifest cache) and live state (from the cluster state cache). If either cache is stale, the diff is wrong. This means Argo can report “Synced” when it isn’t, or “OutOfSync” when the cluster is actually correct.

The state propagation chain is: git → revision cache → manifest cache → controller working set → cluster state cache → diff computation → API server → UI. That’s eight stages. A stale value at any stage propagates downstream, and there is no mechanism to detect or correct cross-stage inconsistency short of a hard refresh that flushes the entire chain.

Flux’s equivalent chain is: git → source controller polls → writes artifact to GitRepository status → kustomize controller reads status → applies to cluster → writes result to Kustomization status. That’s one source of truth per stage (the CRD status), each written by the controller that owns it, with no intermediate caches. kubectl get kustomization always reflects the controller’s actual last reconciliation — there’s no cache between you and the truth.

Argo’s Controller Deadlocks and State Corruption

The centralized architecture creates failure modes that don’t exist in Flux’s distributed model. These are documented, reproducible, and persist through the v3.x release line:

Controller deadlocks and queue blocking: The argocd-application-controller is a single controller responsible for reconciling every Application. It maintains an internal work queue and in-memory state. Race conditions and internal queue blocks cause the controller to get stuck in a “Refreshing” state where no Applications are being reconciled. The root cause is typically a deadlock between the controller and argocd-repo-server, or an internal queue block within the controller itself. The only fix is restarting the affected components. (GitHub: ArgoCD stuck in “Refreshing” state)

Indefinite refresh/sync hangs: Users report refresh operations running 10+ minutes, syncs taking 50+ minutes, and applications stuck in “Unknown” state for an hour or more — even when the node is not resource-starved and ArgoCD components are within resource limits. Complete uninstall and reinstall does not resolve the issue. (GitHub #19980)

Cluster cache invalidation loops: Triggering invalidation of the cluster cache on the application controller replica causes applications to get stuck in Syncing/Terminating state. Logs show the controller timing out after 3 minutes, retrying the app status refresh, failing again, and looping indefinitely. Restarting the application controller statefulset is the only recovery. (GitHub Discussion #8116)

UI not updating without hard browser refresh: The UI fails to reflect state changes (sync, refresh, restart, delete) until the user performs a hard browser refresh. This is particularly dangerous: operators click sync on what they believe is current state, nothing happens, they click again, and either nothing happens or the wrong thing happens because the underlying state changed between the stale view and the action. This persists in v3.x. (GitHub #22492, GitHub #9247)

Automatic refresh broken in v3.1.9: Users upgrading to ArgoCD 3.1.9 reported that automatic application refresh stopped working entirely — Applications no longer detect changes in their source repositories without manual intervention. (GitHub #25052)

The recommended workaround for all of these is the CLI: argocd app get <app> --hard-refresh to force cache invalidation, or component restarts. This effectively means the UI — Argo’s primary differentiator over Flux — cannot be trusted for operational decisions without CLI verification.

Why Flux doesn’t have these problems: Flux’s controllers are independent processes with no shared state, no shared cache, and no central coordination point. A Flux kustomize-controller can’t deadlock with a source-controller because they communicate exclusively through CRD status updates in the Kubernetes API — the same mechanism every other Kubernetes controller uses. If a single Flux controller hangs, it affects only its own CRDs; other controllers continue reconciling independently. There is no equivalent of the “entire system stuck in Refreshing” failure mode because there is no single system — just independent controllers doing their jobs.

Where Each Tool Wins (2025-2026)

Flux Advantages

Kubernetes-native architecture — everything is CRDs and controllers, no central server. Lighter footprint, smaller attack surface.
Per-resource sync intervals — Argo’s sync interval is global; Flux can define it per application.
SOPS integration — native, configure-once encrypted secrets. Argo requires more plumbing.
Kustomize/Helm composition — Flux’s handling of layered Kustomize overlays and Helm post-renderers is more natural. Sources and kustomizations compose as separate CRDs.
Multi-tenancy — Flux’s controller-per-tenant model is more granular than Argo’s RBAC-based approach.
No UI attack surface — nothing to harden if there’s nothing exposed.
Lighter resource usage — matters for edge, bare-metal, or resource-constrained clusters.
State consistency — one source of truth (CRD status), no cache layers to disagree.

Argo Advantages

Web UI — genuinely useful for visibility, onboarding, and non-CLI users (when it’s not stale).
Commercial ecosystem — enterprise support exists for Argo (Codefresh/Akuity). Flux lost commercial support when Weaveworks shut down in early 2024.
Larger contributor base — backed by Intuit, more active development velocity.
Application-centric model — easier mental model for teams managing many apps across clusters.
RBAC maturity — v3.0 fine-grained RBAC is genuinely good (per-resource, per-application permissions).
OCI registry support (v3.1) — store deployment configs in OCI registries alongside container images.
ApplicationSet — templated generation of many Applications from a single definition.

The Weaveworks Factor

Weaveworks, the company behind FluxCD, shut down in early 2024. Flux is a CNCF graduated project and won’t disappear, but the core team that drove most development worked at Weaveworks. Commercial support is gone. Development continues via community contributors, but velocity has slowed relative to Argo. For existing Flux deployments this isn’t urgent, but for long-term ecosystem health it’s a real consideration.

Bottom Line

If you value minimalism, Kubernetes-native design, CLI-first workflows, and state consistency, Flux is the right choice. If you need a UI for non-CLI users, commercial support, or ApplicationSet-style templating, Argo has real advantages. The honest trade is operational simplicity and architectural correctness (Flux) vs. ecosystem momentum and UI accessibility (Argo).

nikogura.com

Thoughts, opinions, and occasionally rantings of a passionate technologist.