skip to content

Flux exposes GitOps as a set of composable controllers and CRDs with no built-in web UI, while Argo CD centres on an Application object with a console and its own API server. How does that shape difference affect which one a team should adopt?

level: principalimportance: should knowfreq 42%

answer

  1. they tie on capability, not on shape
  2. primitives versus an application-centric product
  3. who needs to see the deployment
  4. one reuses cluster RBAC, one adds its own
  5. the missing console is a real cost to budget

basics

~20 s

Flux gives composable primitives managed like any other Kubernetes resource, which suits platform teams who already work through Git, CRDs and RBAC. Argo CD gives an application-centric console and its own access layer, which suits many app teams needing a visible, self-service surface.

solid answer

~60 s

Both reconcile Git into a cluster, so the choice is rarely about capability — it is about the interface your organisation needs. Flux's unit of work is a set of small resources: a source, one or more `Kustomization` objects, `HelmRelease` objects, all ordinary CRDs you manage through the same repository, the same review process and the same Kubernetes RBAC as everything else. There is no separate console, so the operating surface is `kubectl` and the `flux` CLI, and observability is whatever you build from conditions, events and metrics. Argo CD instead offers an application-centric product: one object aggregates a source and destination, and a web UI, API server and its own user model sit in front of it. That is a genuine asset when dozens of application teams need to see and act on their own deployments without cluster access — and a genuine cost, because it is another service to run, secure and integrate with SSO. Pick Flux when the platform team is the operator and Git is already the interface; pick Argo CD when visibility and self-service for many teams is the requirement.

go deeper

for a junior

Know that both tools reconcile Git into a cluster, and that the visible difference is Flux's set of CRDs driven from the CLI versus Argo CD's application object with a web console.

for a middle

Explain what the shapes imply day to day: Flux composes small resources and reuses Kubernetes RBAC, while Argo CD aggregates an application and brings its own server, users and UI to operate.

for a senior

Frame the choice around operations — who needs visibility without cluster access, what you must build if there is no console, and the cost of running and securing an extra server and permission model.

for a principal

Own the decision and its consequences: name the organisational fact that decides it, standardise one agent per cluster, budget the observability or the operational overhead you just accepted, and state what a later migration would actually cost.

## Same job, different product shape Flux and Argo CD do the same fundamental thing: watch a Git (or OCI) source, render manifests, apply them to a cluster, keep re-applying so drift heals. If you evaluate them on "can it do continuous reconciliation", they tie. The real decision is about *shape* — what the unit of configuration is, who operates it, and what the humans look at when something is wrong. ## Flux's shape: composable controllers Flux decomposes the job across controllers, each with narrow CRDs. Acquisition is a source object; application is a `Kustomization`; charts are a `HelmRelease`; alerts and webhooks are their own resources again. Nothing aggregates them into a single "application" object. What follows from that: - **No new access-control system.** Permissions are Kubernetes RBAC, and the identity a set of manifests is applied under can be scoped per `Kustomization`. Tenants are namespaces and service accounts. If you have already invested in cluster RBAC, you reuse it rather than mirroring it in a second product. - **Composition instead of configuration.** One source feeding many Kustomizations, layered with `dependsOn`, gives you ordering and blast-radius control by structure. The trade is that the structure is yours to design and to document. - **Kubernetes-native operations.** Everything is a resource, so your existing tooling — GitOps for the GitOps agent, admission policy, resource-level auditing, kube-state metrics — applies without adaptation. - **No UI in the box.** This is the honest cost. "What is deployed and is it healthy?" is answered with the CLI, conditions and events, or with a dashboard you build from Flux's metrics and notifications. For a small platform team that lives in a terminal, that is fine; for fifty product engineers who do not have cluster access, it is a gap you must fill. ## Argo CD's shape: an application-centric console Argo CD's centre of gravity is one aggregate object representing an application, plus a server component with a web UI, an API and its own account and role model, commonly wired to SSO. Engineers open a page, see a tree of resources with health and sync state, and act on it. What follows: - **Discoverability by default.** The state of a deployment is legible to someone who has never used kubectl. For organisations where deployment visibility is a support burden, this alone can decide it. - **Self-service without cluster credentials.** The product's own roles let you grant a team the ability to see and sync their app without granting Kubernetes access. - **Another system to run.** Its server, user model and SSO integration are components you operate, patch and secure, and its permission model is a second place where access can be wrong. ## How to actually decide Useful questions, in rough priority order: 1. **Who is the operator?** A platform team of five that already reviews every manifest through pull requests gets little from a console. A company where product teams own their own deploys gets a lot. 2. **What is your access story?** If cluster RBAC is already the boundary you trust, Flux's reuse of it is a simplification. If most engineers must never touch the cluster, a product with its own user model is doing real work for you. 3. **How much structure do you want to own?** Flux hands you primitives and expects you to design layers, tenancy and promotion. That is flexibility if you have opinions and a burden if you do not. 4. **What does on-call need at 3am?** Both expose conditions and events. Only one gives a resource tree in a browser out of the box. If you choose Flux, budget the observability work — alerts on source and Kustomization readiness, a dashboard from metrics — rather than discovering the gap during an incident. 5. **What else is in play?** Existing investment in one ecosystem, the surrounding progressive-delivery and multi-cluster tooling each community has built, and simply which one your engineers have operated before are legitimate tiebreakers. Neither locks your manifests in — the repository content is portable, only the agent's own resources are not. ## The trap to avoid Running both because two teams each prefer one. Now you have two reconcilers with cluster-wide write access, two audit trails, two failure modes, and eventual ambiguity about which one owns an object — a situation that ends with two controllers fighting over the same field. Pick one per cluster and mean it. The strong answer in an interview is not "Flux is better" or "Argo CD is better"; it is naming the organisational fact that decides it, and being explicit about the cost you are accepting in exchange.

  • If you choose Flux, what do you have to build that you would otherwise get in the box?
    A visibility layer. Concretely: alerting on source and Kustomization readiness so a stale-but-Ready source cannot silently freeze delivery, a dashboard from the controllers' metrics and events, and a documented triage path with the CLI. Without that, on-call engineers discover mid-incident that nobody can see what is deployed without cluster access.
  • Is it reasonable to run Flux and Argo CD in the same cluster?
    Rarely. Two reconcilers with cluster-wide write access mean two audit trails, two failure modes, and the real risk that both manage the same object and revert each other on their own intervals. If a migration forces overlap, partition ownership strictly by namespace and make the boundary explicit and temporary.
  • Does choosing one lock you into it?
    The valuable content — your manifests, kustomize overlays and charts — is portable, since both render essentially the same inputs. What is not portable is the agent's own resources and any structure that assumed them: your layering, tenancy model, ordering and promotion conventions. Migration is real work, but it is re-wiring, not rewriting the desired state.

saying these in an interview costs you the question

  • Argues one is strictly more capable rather than differently shaped
  • Ignores that a console must be operated, secured and integrated with SSO
  • Assumes Flux's lack of a UI is free
  • Proposes running both agents in the same cluster
  • Decides on popularity instead of who operates the deploys

context

resolving links…