Why Flux

Why push-based CI deployment breaks down at scale, the four OpenGitOps principles Flux implements, and where Flux sits against Argo CD, plain CI pipelines, and Kustomize or Helm on their own.

Overview

What Flux is

Flux is an open and extensible continuous delivery solution for Kubernetes. It keeps clusters in sync with configuration sources and automates updates when new code is available.

It is a CNCF Graduated project (graduated November 2022) and originated at Weaveworks, the company that coined the term GitOps in 2017. The CNCF CI/CD Tech Radar lists it at the Adopt level.

The problem: push-based pipelines

In a push pipeline a CI runner holds a kubeconfig and runs kubectl apply or helm upgrade against the cluster from the outside.

Credentials live in CI — A CI compromise reaches every cluster the pipeline can reach
Apply is forward-only — Once the job exits, manual edits, webhook mutations and half-reverted incident fixes drift the cluster undetected
No authoritative "what is running" — The repository states intent, the cluster holds reality, and nothing enforces equality

How Flux inverts control

Controllers run inside the cluster and pull desired state from a Git repository, an OCI registry, a Helm repository or an S3-compatible bucket on a configured interval. They apply it with server-side apply, become the field owner, and re-run the comparison every interval.

Who holds cluster credentials — CI system — Nobody outside the cluster
Secret that leaves the cluster — Cluster write access — An outbound, typically read-only, Git credential
Manual changes — Survive indefinitely — Reverted on the next pass unless the reconciliation is suspended

The four OpenGitOps principles

The formal frame is OpenGitOps v1.0.0, published by the GitOps Working Group under the CNCF App Delivery Technical Advisory Group.

> [!IMPORTANT] Most teams satisfy the first two (YAML in Git) and skip the last two, which are the ones that change operational behavior. Naming all four and which two are commonly missed separates a practitioner from someone who has read a blog post.

Where Flux sits

Helm and Kustomize — Flux does not compete; it consumes them through helm-controller and kustomize-controller
Argo CD — Both are CNCF Graduated pull-based GitOps controllers; the choice is about interaction model and multi-tenancy shape, not capability (covered in its own topic)
Plain CI push — Flux is a strict superset for anything declarative, and strictly worse for anything that is not

The honest boundary

Flux is a reconciliation engine for declarative desired state, not a workflow engine. Multi-step imperative runbooks, mid-deploy human approval gates and database migrations that need a person in the loop are not what it is for.

> [!WARNING] Flux makes the Git repository the production control plane. That is only safe if branch protection, review requirements and signed commits are already disciplined.

> [!TIP] Interviewers who have operated Flux probe exactly here: they want to hear where you would not use it.

Key concepts

GitOps: Per the Flux concepts documentation, managing infrastructure and applications so the whole system is described declaratively and version controlled, with an automated process ensuring the deployed environment matches the state specified in one or more repositories. The automated process is the part that distinguishes it from storing YAML in Git.
The four OpenGitOps principles: Declarative; versioned and immutable; pulled automatically; continuously reconciled. Published as OpenGitOps v1.0.0 by the GitOps Working Group under the CNCF App Delivery TAG. Principles three and four require a pulling agent and a reconciliation loop, which is what separates Flux from a CI pipeline reading from Git.
Reconciliation: The controller loop that reads desired state from a source, compares it to live cluster state, applies the difference, and repeats on spec.interval. kustomize-controller reverts out-of-band changes on the next pass unless the Kustomization is suspended, so drift correction is a property of the loop rather than a separate feature.
Pull model: Controllers inside the cluster fetch desired state from an external source. The security consequence is that no external system holds cluster credentials. Under the push model a compromised CI system is a compromised cluster; under the pull model it can at most publish a bad artifact that still has to pass repository review and policy gates.
GitOps Toolkit (GOTK): The set of composable controllers and Go packages Flux v2 is built from: source-controller, kustomize-controller, helm-controller, notification-controller, image-reflector-controller, image-automation-controller. The gotk- prefix on the bootstrap-generated filenames comes from this.
Flux v1 versus Flux v2: v1 was a single monolithic daemon handling Git sync, apply, and image scanning in one process. v2 is a complete rewrite into separate controllers with their own CRDs, plus atomic server-side apply, where a group of manifests is rejected entirely if server-side validation fails on any member. Migrating is a configuration rewrite, not a version bump.
Gitless GitOps: A newer Flux model that decouples the workflow from Git by treating an OCI registry as the source of truth for configuration artifacts and their signatures. Useful for air-gapped environments and for teams that want immutable, digest-addressed config artifacts rather than mutable branches.

When to use it

Any environment where cluster credentials must not live in a CI system — Flux controllers authenticate in-cluster with their own ServiceAccounts and pull outward
Fleets of clusters that must converge on shared platform baselines (CNI policy, ingress, cert-manager, monitoring) with per-cluster overlays
Regulated or audited environments where every production change must be a reviewed, signed, revertible Git commit with a complete history
Teams that keep discovering configuration drift during incidents and want manual cluster edits reverted automatically rather than silently accumulating
Multi-tenant platforms where each tenant owns a repository path and Flux reconciles under an impersonated tenant ServiceAccount rather than cluster-admin

Interview questions

Why is pull-based GitOps considered more secure than a CI pipeline that runs kubectl apply?
Name the four GitOps principles and explain which ones most teams actually fail.
How does Flux relate to Helm and Kustomize? Does it replace them?
When would you NOT use Flux?
What is the difference between Flux v1 and Flux v2, and why does it matter for migration?