FluxCD

What is Flux?

Flux (FluxCD) is a GitOps tool for Kubernetes: a set of controllers that run inside your cluster and continuously reconcile the cluster’s state to match configuration declared in a Git repository. You describe your desired Kubernetes resources in Git; Flux pulls from Git, applies them, and keeps watching so the live cluster never drifts from the declared state. It’s a CNCF-graduated project and one of the two leading GitOps operators alongside Argo CD — the automated engine that turns “Git is the source of truth” from a principle into a running system.

How it embodies GitOps

Flux implements the core GitOps mechanics: it’s pull-based (the operator inside the cluster pulls desired state from Git, rather than an external CI system pushing changes in with cluster admin credentials — more secure, since the cluster’s keys never leave it), declarative (you commit desired Kubernetes manifests/Helm releases/Kustomize configs), and continuously reconciling (a control loop constantly compares actual vs desired state and corrects drift, so a manual change to the cluster gets reverted back to what Git says). This delivers GitOps’s benefits: every change is a reviewed, audited, revertible Git commit; environments stay drift-free and self-healing; and rollback is git revert. Flux is composed of modular controllers (source, kustomize, helm, notification, image-automation) and is known for an automation-first, composable, Kubernetes-native design — it also pioneered image automation (automatically updating manifests in Git when new container images are published, closing the loop from build to deploy).

Flux vs Argo CD, and the realities

The practical decision is usually Flux vs Argo CD, and both are excellent, CNCF-graduated, and implement the same GitOps principles — the difference is style. Argo CD is known for its rich web UI and application-centric visualization (great for seeing sync status and diffs at a glance, often favored where teams want a dashboard). Flux is more CLI/GitOps-native and composable, leaning into automation and integrating as controllers rather than centering a UI (favored by teams that want everything as code and pipelines). Many organizations pick based on whether they value a strong UI (Argo CD) or a lightweight, automation-first, API-driven approach (Flux) — and both are safe, mature choices. The realities to respect are GitOps’s realities: secrets management is the classic hard problem (never commit plaintext secrets to Git — use SOPS, Sealed Secrets, or an external secrets operator, all of which Flux integrates with); the model only delivers its guarantees if teams stop making manual cluster changes and route everything through Git (Flux will otherwise fight their drift); and there’s genuine setup and repo-structure work (organizing manifests, environments, and Helm/Kustomize overlays). The recurring mistakes: committing secrets to Git, continuing out-of-band kubectl changes that reconciliation reverts, and underestimating the repo-structure and secrets tooling needed to run GitOps properly.

What people get wrong

• Committing secrets to Git — plaintext credentials in the source-of-truth repo is a serious exposure; use SOPS, Sealed Secrets, or an external secrets manager (all Flux-compatible).
• Still making manual cluster changes: Flux continuously reverts drift, so out-of-band kubectl edits get undone — the GitOps model requires routing all changes through Git.
• Underestimating setup — repo structure, environment overlays, and secrets tooling take real effort; GitOps is an operating discipline, and Flux is the engine, not a one-click install.

Primary source: Flux documentation