mrvitej.in

DevOps · CNCF daily

Flux: Continuous and Progressive Delivery Through GitOps

CNCF Graduated. A set of Kubernetes controllers that keep clusters in sync with Git repositories, OCI artifacts and Helm charts, reconciling drift continuously and automating image updates.

7 min read

CNCF Graduated

  • Flux
  • Kubernetes
  • Helm
  • Kustomize
  • SOPS
  • Flagger
CNCF project page

Flux is a GitOps toolkit for Kubernetes: a set of controllers that continuously pull the desired state of a cluster from Git repositories, OCI artifacts or Helm repositories and reconcile the cluster towards it. It addresses the drift and audit problems of push-based deployment, where CI systems hold cluster credentials and nothing corrects manual changes afterwards. Flux was created at Weaveworks, whose team coined the term GitOps, and was rewritten from 2020 as the modular “GitOps Toolkit” known as Flux v2. It joined the CNCF Sandbox in 2019, moved to Incubation in March 2021 and graduated on November 30, 2022; the project continued under a multi-vendor maintainer group after Weaveworks closed in February 2024.

CNCF daily · Sprint 2, day 2 · Continuous Integration & Delivery (bonus GitOps post)

At a glance
Category Continuous Integration & Delivery
CNCF status Graduated. Sandbox 2019, Incubating March 2021, Graduated November 30, 2022
Written in Go
License Apache 2.0
Current release line Flux 2.9 (GA June 30, 2026), supporting Kubernetes 1.34 to 1.36
Sources Git, OCI artifacts, Helm repositories, S3-compatible buckets
Companion projects Flagger (progressive delivery), Flux Operator, flux CLI plugins

Architecture

flowchart TB
  GIT[Git repository] --> SC[source-controller<br/>fetch and package]
  OCI[OCI registry] --> SC
  HR[Helm repository] --> SC
  SC --> ART[Versioned artifacts<br/>in cluster]
  ART --> KC[kustomize-controller<br/>build, decrypt, apply]
  ART --> HC[helm-controller<br/>install and upgrade]
  KC --> K8S[Kubernetes API<br/>server-side apply]
  HC --> K8S
  IR[image-reflector-controller<br/>scan registry tags] --> IA[image-automation-controller<br/>commit new tags]
  IA --> GIT
  K8S --> NC[notification-controller<br/>alerts and webhooks]
  NC --> EXT[Slack, Teams,<br/>Git commit status]
Component Responsibility
source-controller Fetches Git, OCI, Helm and bucket sources on an interval, verifies signatures and exposes each revision as an artifact.
kustomize-controller Builds Kustomize overlays, decrypts SOPS secrets, applies manifests with server-side apply, prunes removed objects and runs health checks.
helm-controller Manages HelmRelease objects: install, upgrade, test, rollback and drift detection for Helm charts.
notification-controller Sends events to chat and incident tools, updates commit statuses and receives webhooks that trigger immediate reconciliation.
image-reflector and image-automation controllers Scan registries for new tags matching a policy and commit the updated tag back to Git.
Flux Operator Optional operator that installs and upgrades Flux itself from a FluxInstance resource, with a web UI.

Design principle. Flux is pull-based and declarative: nothing outside the cluster needs write access to it. Each controller does one job and communicates through Kubernetes resources, so teams adopt only the parts they need and the desired state in Git remains the single source of truth.

Production reference design

A typical layout on EKS, GKE, AKS or on-premises clusters uses one Git repository for fleet configuration and separate application repositories that publish images.

  1. Bootstrap Flux into the cluster and commit its own manifests to the fleet repository: 
    flux check --pre
flux bootstrap github \
  --owner=acme --repository=fleet-infra --branch=main \
  --path=clusters/prod-ap-south-1 --personal=false
    Platform teams that prefer an operator-managed lifecycle can install the Flux Operator with Helm and declare a FluxInstance instead.
  2. Structure the repository by cluster and layer: clusters/<name> points at infrastructure/ (ingress, cert-manager, policies) and apps/ (workloads), with Kustomize overlays per environment.
  3. Declare sources and reconciliation with explicit dependencies, so infrastructure is ready before applications: 
    apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
  name: fleet
  namespace: flux-system
spec:
  interval: 1m
  url: https://github.com/acme/fleet-infra
  ref:
    branch: main
---
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: apps
  namespace: flux-system
spec:
  interval: 10m
  path: ./apps/prod
  prune: true
  wait: true
  timeout: 5m
  dependsOn:
    - name: infrastructure
  sourceRef:
    kind: GitRepository
    name: fleet
  decryption:
    provider: sops
    secretRef:
      name: sops-age
  4. Manage charts with HelmRelease (helm.toolkit.fluxcd.io/v2), pinning chart versions and enabling drift detection, so manual kubectl edit changes are reverted.
  5. Automate image updates: an ImagePolicy selects the newest semver tag, and image automation commits it to Git, keeping Git the record of what runs.
  6. Wire notifications to Slack or Microsoft Teams and set commit statuses on the fleet repository, so failed reconciliations are visible where engineers work.

Typical production uses are multi-cluster fleet management, environment promotion through Git pull requests, secret management with SOPS, and progressive delivery with Flagger for canary and blue-green releases.

Operational considerations

  • Scaling: controllers are horizontally sharded by label for very large fleets; tune interval values, since thousands of objects reconciling every minute load both the API server and Git hosts. Webhook receivers give fast feedback without short polling intervals.
  • High availability: Flux state lives in Git and Kubernetes, so a controller restart is harmless; the critical dependency is the Git or OCI source. Mirroring sources to an in-region OCI registry removes that dependency during outages.
  • Security: Flux needs no inbound access and no CI credentials for the cluster. Restrict tenants with service account impersonation per Kustomization, verify Git commits or OCI artifacts with signatures, and keep SOPS keys in a KMS or Vault-compatible store.
  • Sizing: the controllers are lightweight; memory grows with the number and size of artifacts. Large monorepos are better split, or packaged as OCI artifacts, to avoid repeated clones.
  • Common pitfalls: prune: true deletes objects removed from Git, including ones created by hand that were adopted accidentally; review the first sync in a test cluster. Upgrades occasionally remove deprecated API versions, so run flux migrate and read release notes before each minor upgrade.

Adoption

The project’s adopters page lists organisations that self-report production use, including Cisco, Grafana Labs, Maersk, SAP SE, Volvo Cars, UiPath, Orange, Kong, RingCentral, Hetzner, Scaleway, Sonatype, Traefik Labs, Giant Swarm and BlaBlaCar. Morgan Stanley described its five-year GitOps journey with Flux at FluxCon North America 2025. Flux is also embedded in managed offerings, such as the GitOps extension for Azure Kubernetes Service and Azure Arc.

Alternatives

Solution Model Best suited to
Argo CD (CNCF Graduated) Pull-based GitOps with a central UI and multi-cluster management Teams that want a rich web interface and application-centric views
Rancher Fleet Pull-based GitOps for very large fleets Organisations standardised on Rancher
Push-based CI deployment (GitHub Actions, GitLab CI, Jenkins) Pipeline runs kubectl or helm against the cluster Small setups where drift correction is not required
Pulumi or Terraform Kubernetes providers Infrastructure-as-code apply runs Teams managing clusters and workloads from one IaC tool

Strengths and limitations

Strengths Limitations
Modular controllers; adopt only what is needed No built-in rich UI comparable to Argo CD, although the Flux Operator web UI and flux9s narrow the gap
Strong multi-tenancy through service account impersonation Debugging spans several controllers and resource types
First-class Helm, Kustomize, OCI artifacts and SOPS Image automation writes to Git, which some teams prefer to keep human-only
Graduated, vendor-neutral governance with a long track record Requires disciplined repository structure to stay readable at scale
Native drift correction with selective ignore rules (Flux 2.9) Frequent minor releases require a regular upgrade cadence

Recommendation

Adopt for Kubernetes platforms that want Git or OCI artifacts as the source of truth and continuous drift correction. Start with a single fleet repository, bootstrap with the CLI or the Flux Operator, enable SOPS for secrets and notifications for failed reconciliations, and add image automation or Flagger once the base workflow is stable. Teams that value a central web UI for developers should compare Argo CD before choosing.

References: CNCF project page · Flux documentation · Flux 2.9 GA announcement · Flux 2.8 GA announcement · CNCF graduation announcement · Flux adopters · Flux on GitHub

Spotted something wrong or out of date?Suggest a correction. I review every suggestion before changing the page.