Flux2 v2.9.0 - Plugin And Drift Control

Flux v2.9.0 was published on June 30, 2026, with the new flux plugin system as the main operator visible change. For platform teams running data workloads through GitOps, the release also changes drift handling, Helm rendering, secret access, receiver auth, and Kubernetes support boundaries.

The full release notes and downloads are on the GitHub release page.

The headline item is the Flux CLI Plugin System, exposed through flux plugin. The release notes call out Mirror and Schema plugins, and the CLI changelog ties the work to RFC 0013 and the plugin implementation. For teams that wrap Flux inside internal platform tooling, this moves extension points closer to the CLI instead of forcing every workflow through scripts around flux.

The plugin work also has a supply chain detail worth noting. flux plugin install adds digest pinning support, and plugin binary path validation landed in the same release train. Those are small controls, but they matter when a platform team lets automation install tools on build agents or operator workstations.

Local artifact handling also gets sharper. flux build ks and flux diff ks gain --in-memory-build, while build and push artifact commands gain --resolve-symlinks. The changelog also notes a fix for multiple symlinks to the same target in build artifact handling. That is relevant for monorepos where generated manifests, shared bases, and linked directories can make local validation diverge from cluster reconciliation.

For day to day inspection, flux get ks and flux get hr now support --show-source. flux diff ks also adds --ignore-not-found. These are operational changes more than product features: they reduce the number of manual lookups needed when checking which source a Kustomization or HelmRelease is using, or when comparing desired state against a cluster that does not yet have the object.

Flux v2.9.0 adds field ignore rules for server side apply drift control on Kustomization. That is the release item most likely to affect noisy GitOps estates. If a cluster has admission controllers, runtime agents, or platform controllers that write fields after apply, field level ignore rules let teams separate expected mutation from real drift.

Helm users get post render strategies on HelmRelease, including chart hooks support. Literal mode for Helm values references also mirrors helm --set-literal. Both changes are practical for platform charts that pass values containing characters that Helm would otherwise parse, or that need render behavior closer to direct Helm usage while still staying under Flux control.

The notes also mention empty kind support in CEL health check expressions for Kustomization and HelmRelease. This is a narrow change, but it matters for health checks that need to match resources without binding every condition to a concrete Kubernetes kind.

For large repositories, ArtifactGenerator adds path pattern directory discovery for monorepos. The release notes do not expand the behavior beyond that line, so treat it as a discovery improvement rather than a broad monorepo redesign.

The security related changes are mostly about reducing static secret handling and tightening verification. Kustomization gains SOPS decryption with the Age post quantum cipher, plus Kubernetes Workload Identity authentication for OpenBao and Vault. GitRepository adds AWS CodeCommit authentication using Workload Identity.

Git commit signing and verification with SSH keys now applies to GitRepository and ImageUpdateAutomation. OCIRepository adds a custom Sigstore trusted root for keyless verification in air gapped environments. Secret free OIDC secured webhook Receivers are also listed in the highlights, and the CLI adds both flux create secret receiver and flux trigger receiver.

For platform operators, these changes point in the same direction: fewer long lived credentials in cluster state, more workload native identity, and more explicit verification for Git and OCI inputs. There is still policy work to do outside Flux, but the release gives more primitives to wire into that policy.

Flux v2.9.0 is compatible with Kubernetes v1.34, v1.35, and v1.36, with the minimum patch versions listed as >= 1.34.1, >= 1.35.0, and >= 1.36.0. The notes also state that Flux supports only the latest three Kubernetes minor versions. If your clusters lag behind that window, the project points older Kubernetes and OpenShift support at vendor support paths.

The breaking change is explicit. The APIs image.toolkit.fluxcd.io/v1beta2 and notification.toolkit.fluxcd.io/v1beta2 have reached end of life and have been removed from the CRDs. Before applying the new CRDs, inventory existing ImageRepository, image automation, notification, and receiver resources that may still depend on those API versions.

The release notes point upgrades from older versions to the Flux v2.7 plus upgrade procedure. That is the route to follow before moving production controllers to the binaries and manifests from the GitHub release page.

The component set is also refreshed: source-controller v1.9.1, kustomize-controller v1.9.1, notification-controller v1.9.1, helm-controller v1.6.1, image-reflector-controller v1.2.1, image-automation-controller v1.2.1, and source-watcher v2.2.1. The CLI changelog also says source-watcher is now included in install.yaml manifests.