# Flux v2: GitOps Continuous Delivery for Kubernetes Powered by the GitOps Toolkit > Flux v2 is a CNCF graduated GitOps tool that keeps Kubernetes clusters synchronized with Git repositories and OCI artifacts, automating deployment when new configuration or code is pushed. It is built on composable Kubernetes custom resources rather than a monolithic application, and it supports multi-tenancy and multiple source types including Helm, Kustomize, and OCI. **fluxcd/flux2** — Open and extensible continuous delivery solution for Kubernetes. Powered by GitOps Toolkit. - Repository: https://github.com/fluxcd/flux2 - Website: https://fluxcd.io - Stars: 8,432 · Forks: 791 - Language: Go - License: Apache-2.0 - Published: 2026-09-22 · Updated: 2026-09-22 · Language: en - Canonical page: https://hysenlabs.com/projects/fluxcd-flux2 ## What Flux v2 is and who it is for Flux v2 is a tool for keeping Kubernetes clusters in sync with sources of configuration, which can be Git repositories, OCI artifacts, Helm repositories, or S3-compatible buckets. When new code or configuration is committed, Flux detects the change and automatically applies it to the cluster. The README describes it as a tool for keeping Kubernetes clusters in sync with sources of configuration and automating updates to configuration when there is new code to deploy. The target audience is platform engineering teams and DevOps engineers who manage Kubernetes clusters and want a declarative, auditable deployment pipeline where the desired state of the cluster is stored in version control. Flux v2 is a CNCF graduated project, meaning it has passed the CNCF's process for production readiness. It is in use by various organizations and cloud providers listed at fluxcd.io/adopters. ## The GitOps model: reconciliation loops and desired state The core mechanism is continuous reconciliation. Flux controllers watch Kubernetes custom resources that describe the desired state, then compare that desired state with the actual state of the cluster, and apply changes until the two match. If someone makes a manual change to a cluster resource that conflicts with what the Git repository says, Flux will revert it. This is the GitOps model: Git is the source of truth, not the cluster's current state. Flux v2 is constructed from the GitOps Toolkit, which the README describes as a set of composable APIs and specialized tools for building continuous delivery on top of Kubernetes. The APIs are Kubernetes custom resources, which means Flux configuration is stored and versioned in the same way as any other Kubernetes resource and can be managed with kubectl, Helm, or Kustomize. ## The GitOps Toolkit components and their custom resources The GitOps Toolkit divides concerns across several controllers. The Source Controller handles fetching configuration: its custom resources include GitRepository, OCIRepository, HelmRepository, HelmChart, Bucket, ExternalArtifact, and ArtifactGenerator. The Kustomize Controller applies Kustomize-managed configuration to the cluster using the Kustomization CRD. The Helm Controller manages Helm releases using the HelmRelease CRD. The Notification Controller routes events to external services via the Provider, Alert, and Receiver CRDs. The Image Automation Controllers handle automatic image updates: the ImageRepository CRD polls a container registry for new tags, the ImagePolicy CRD defines which tags to select, and the ImageUpdateAutomation CRD writes the selected tag back to a Git commit, closing the loop between a new image push and a cluster update. ## Installing and bootstrapping Flux on a Kubernetes cluster The primary install path is the flux CLI. The Dockerfile in the repository shows the flux binary is packaged alongside kubectl in an Alpine image, giving a sense of what the CLI needs. The README points to the bootstrap guide at fluxcd.io/flux/get-started/ as the starting point. The Makefile provides a setup-kind target for creating a local test cluster: ```bash make setup-kind ``` This creates a Kind cluster named flux-e2e-test and applies a Calico network configuration. Once connected to a cluster, the flux CLI bootstraps the controllers and creates the GitRepository and Kustomization CRDs pointing to the repository. From that point, any commit to the repository triggers the reconciliation loop. The flux binary itself is a Go application; source is in cmd/flux/ and internal packages are in internal/ and pkg/. ## Multi-tenancy and OCI artifact support Flux v2 explicitly supports multi-tenancy, which was a much-requested feature not available in Flux v1. Multiple teams can have separate namespaces with separate source repositories, and the reconciliation for each team is isolated. The OCIRepository CRD allows clusters to consume configuration packaged as OCI artifacts stored in a container registry, which means configuration can be versioned and distributed the same way container images are. The Image Automation Controllers add a closed-loop update mechanism: when a new container image is pushed to a registry, Flux detects the tag change, applies the image update policy to select the right tag, writes a commit back to the Git repository, and triggers a new reconciliation. This eliminates the need for a separate CI step to update image references in the Git repository. ## Limitations: no built-in UI, configuration complexity, and Kubernetes-only scope Flux v2 has no built-in web UI. Argo CD, which is the other major CNCF GitOps project, ships with a web interface for visualizing sync status and resource trees. Flux users who want a dashboard need to use a separate tool, such as the community-maintained Flux UI or integrate with Grafana and Prometheus, which the README notes Flux integrates with. The composable controller model means a Flux installation has several moving parts: typically at minimum the Source Controller and either the Kustomize Controller or Helm Controller must be running. Debugging a failed reconciliation requires understanding which controller is responsible for which resource type. Flux is Kubernetes-only; it does not support other platforms. The latest release at the time of the last repository push was v2.9.5, published 2026-08-31. The Apache-2.0 license places no copyleft restrictions on use. ## Flux v2 versus Argo CD: composable controllers versus a monolithic application Argo CD is also a CNCF GitOps project that synchronizes Kubernetes clusters with Git repositories. The key architectural difference is that Argo CD is a monolithic application with a web UI, a Redis cache, and a Dex identity provider bundled together, while Flux v2 is a set of independent controllers that each manage a specific resource type. Argo CD's UI provides an immediate visual way to see sync status, resource health, and deployment history without additional tooling. Flux v2 requires separate tooling for visualization but is more composable: teams can install only the controllers they need and combine them with other Kubernetes-native tools. For teams comfortable with Kubernetes-native operations and who prefer CLI-driven workflows, Flux v2's approach fits naturally. For teams who need self-contained GitOps with a built-in visual dashboard from day one, Argo CD's bundled UI reduces initial setup time. ## Conclusion Flux v2 is the right choice for platform teams who need a composable, Kubernetes-native GitOps pipeline with multi-tenancy, support for both Kustomize and Helm, and image update automation. Teams who need a visual sync dashboard out of the box should evaluate whether the separate Flux UI or a third-party integration covers their requirements before committing. The correct entry point for a new installation is the bootstrap documentation at fluxcd.io/flux/get-started/, which walks through installing the flux CLI and connecting it to a Git repository. ## FAQ ### What is the difference between Flux v1 and Flux v2? Flux v2 is rebuilt from the ground up on Kubernetes API extensions and the GitOps Toolkit. It supports multi-tenancy, multiple source repositories, OCI artifacts, and a composable set of controllers for different resource types. The README describes v2 as using Kubernetes API extension system and integrating with Prometheus and other core Kubernetes ecosystem components, features that were not in v1. ### Does Flux v2 support Helm releases? Yes. The Helm Controller manages Helm releases using the HelmRelease CRD. The HelmRepository CRD can point to a Helm chart repository, and the HelmChart CRD describes which chart to use. Flux reconciles the HelmRelease resource against the cluster continuously. ### What is the GitOps Toolkit in Flux v2? The GitOps Toolkit is the set of composable Kubernetes custom resource APIs and controllers that form the runtime for Flux v2. It includes the Source Controller, Kustomize Controller, Helm Controller, Notification Controller, and Image Automation Controllers. The README states the toolkit can also be used to extend Flux or to build custom continuous delivery systems. ## Sources - [fluxcd/flux2 on GitHub](https://github.com/fluxcd/flux2) - [License: Apache-2.0](https://github.com/fluxcd/flux2/blob/main/LICENSE) - [Project website](https://fluxcd.io) - [README](https://github.com/fluxcd/flux2/blob/main/README.md) - [Releases](https://github.com/fluxcd/flux2/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/fluxcd-flux2