Blog: Announcing Flux 2.8 GA

Published: (February 24, 2026 at 06:00 AM EST)
7 min read

Source: Flux CD Blog

Flux v2.8.0 Release

We are thrilled to announce the release of Flux v2.8.0! In this post we highlight some of the new features and improvements included in this release.


Highlights

  • Helm v4 support – brings server‑side apply and enhanced health checking to Helm releases.
  • Big thanks to the Helm maintainers for their work on Helm v4 and for collaborating with us to ensure a smooth integration with Flux!
  • New features for the Flux controllers:
    • Reduced mean time to recovery (MTTR) of Flux‑managed applications.
    • Readiness evaluation of Helm‑managed objects with CEL expressions.
    • ArtifactGenerator support for extracting and modifying Helm charts.
    • Support for commenting on Pull Requests directly from Flux notifications.
    • Custom SSA apply stages for ordering resource application in kustomize-controller.
    • Automatic GitHub App installation‑ID lookup from the repository owner.
    • Support for Cosign v3 for verifying OCI artifacts and container images.

Ecosystem news

  • Flux Operator now ships with a dedicated Flux Web UI and new providers for preview environments.

Helm v4 Support

Flux now ships with Helm v4, delivering two major improvements to how Flux manages Helm releases:

  1. Server‑side apply – the API server merges fields, reducing conflicts when multiple controllers or tools manage overlapping resources and providing more accurate drift detection out of the box.
  2. kstatus‑based health checking – replaces Helm’s legacy readiness logic with the same library used by kustomize-controller. Flux can now understand the actual rollout status of Deployments, StatefulSets, Jobs, and other resources (including custom resources that follow standard status conventions).

For teams that rely on custom readiness logic, Flux now supports CEL‑based health‑check expressions on HelmReleases, giving you the same flexibility already available in the Kustomization API.

  • Both server‑side apply and kstatus health checking are the new defaults.
  • Because Helm persists the apply method in its release storage, existing HelmReleases will continue to use client‑side apply until explicitly opted‑in.
  • Health checking, however, will switch to kstatus for all HelmReleases.
  • If you prefer Helm v3’s behavior across the board, enable the UseHelm3Defaults feature gate to restore the previous defaults.

Finally, HelmReleases now track an inventory of managed resources in .status.inventory, giving you full visibility into what Flux has deployed—useful for debugging, auditing, and building tooling on top of Flux.


Faster Recovery from Failed Deployments

A common pain point with GitOps is the wait time after pushing a fix for a broken deployment. When a release fails health checks, Flux previously waited for the full timeout before acting—even if a new revision was already available. This delay directly impacts the mean time to recovery (MTTR).

  • In Flux 2.7, the kustomize-controller introduced the CancelHealthCheckOnNewRevision feature gate, allowing ongoing health checks to be canceled when a new source revision is detected.

  • In Flux 2.8, this capability is extended to helm-controller and expanded to react to more kinds of changes:

    • Changes in the resource spec (e.g., path, patches, images, values).
    • Changes in referenced ConfigMaps and Secrets (var substitutions, SOPS decryption keys, Kubeconfig).
    • Reconciliations triggered manually with flux reconcile or via notification-controller receivers.

In all these cases, Flux cancels the ongoing health checks and immediately starts reconciling the new state. Instead of waiting several minutes for a failing release to time out, the fix is picked up as soon as it lands.

  • For observability, a new HealthCheckCanceled reason is added to the Ready condition when this happens.
  • This feature gate is opt‑in for now; we plan to enable it by default once the implementation is stable across both controllers.

Ecosystem News

Flux Operator Web UI

At KubeCon Atlanta 2025, the Flux maintainers from ControlPlane gave a sneak peek of the new Flux Web UI, which is now available in the latest release of Flux Operator.

The Flux Web UI provides a modern, user‑friendly interface for managing and monitoring your Flux‑managed clusters. It offers a comprehensive view of your GitOps resources, including:

  • Cluster dashboard with sync statistics and overall system health.
  • Deep‑dive views for ResourceSets, HelmReleases, and Kustomizations.
  • Workload monitoring from deployment rollouts to pod statuses.
  • Powerful search and filtering.
  • Favorites for quick access to critical resources.
  • SSO support via OIDC & Kubernetes RBAC for multi‑tenant clusters.
  • GitOps graphs for visualizing the delivery pipeline.
  • GitOps actions guarded by RBAC for manual interventions and incident response.

Get started by installing the latest version of Flux Operator and following the Flux Web UI documentation.

Preview Environments

Flux Operator’s ResourceSet API makes it easy to deploy ephemeral preview environments from GitHub Pull Requests and GitLab Merge Requests. With Flux 2.8, closing the feedback loop on these environments is now much simpler thanks to new notification-controller provider types:

  • githubpullrequestcomment
  • gitlabmergerequestcomment

JavaScript Example (unchanged)

if (!jQuery) {
    alert("jquery is not loaded");
}
$(document).ready(() => {
    const gallery = $("#gallery-4857f48b2006deaad0ac3a72e5512a43-0");
    let swipeboxInstance = null;
    gallery.on('jg.complete', () => {
        $(() => {
            $('.lazy').Lazy({
                visibleOnly: true,
                afterLoad: element => element.css({ filter: "none", transition: "filter 1.0s ease-in-out" })
            });
        });
        swipeboxInstance = $('.galleryImg').swipebox(
            jQuery.extend({},
                { }
            )
        );
    });
    gallery.justifiedGallery({
        rowHeight: "150",
        margins: "5",
        border: 0,
        randomize: false,
        waitThumbnailsLoad: false,
        lastRow: "nojustify",
        captions: false,
    });
});

Enjoy the new capabilities in Flux v2.8.0!

## gitea pull‑request comment

Previously, posting deployment status on a Pull Request required:

  1. Setting up a githubdispatch provider.
  2. Adding a GitHub Actions workflow to parse the event payload and post a comment.

With the new providers, notification‑controller posts and updates comments directly on the PR or MR page – no CI workflow is needed. Comments are automatically deduplicated, so the PR stays clean with a single status comment that gets updated on each deployment.


Commit‑status reporting

  • Works with any Flux API – not just Kustomizations and GitRepositories.
  • HelmReleases deployed for preview environments can now report their status as commit checks on the PR, giving developers immediate visibility into whether their changes deployed successfully.

Annotating Flux resources

Use the standard event‑metadata keys:

KeyPurpose
event.toolkit.fluxcd.io/change_requestIdentifies the PR/MR number for comment providers
event.toolkit.fluxcd.io/commitIdentifies the commit SHA for commit‑status providers

Complete setup guides

  • Ephemeral Environments for GitHub Pull Requests – Flux Operator documentation
  • Ephemeral Environments for GitLab Merge Requests – Flux Operator documentation

Supported Versions

  • Flux v2.5end‑of‑life (no longer supported)
  • Flux v2.8 – supports the following Kubernetes versions:
DistributionVersions
Kubernetes1.33, 1.34, 1.35
OpenShift4.20

Enterprise support – The CNCF Flux project offers support only for the latest three minor versions of Kubernetes.
Backwards compatibility with older Kubernetes and OpenShift versions is provided by vendors such as ControlPlane, which offer enterprise support for Flux.


Upgrade Procedure

API changes in Flux v2.8

The following APIs have reached end‑of‑life and have been removed from the CRDs:

  • source.toolkit.fluxcd.io/v1beta2
  • kustomize.toolkit.fluxcd.io/v1beta2
  • helm.toolkit.fluxcd.io/v2beta2

Before upgrading to Flux v2.8, migrate all resources to the stable APIs using the flux migrate command.

Steps

  1. Run migration
    flux migrate --to-version=v2.8
  2. Upgrade the Flux components (HelmRelease, Kustomization, etc.) to the new versions.
  3. Verify that all resources are reconciled without errors.

See the “Upgrade Procedure for Flux v2.8” and “Upgrade Procedure for Flux v2.7+” sections in the official documentation for detailed instructions.


Over and out

If you have any questions—or just want to get involved—here are a few good ways to reach us:

  • Join our upcoming dev meetings
  • Talk to us in the #flux channel on CNCF Slack
  • Participate in planning discussions
  • Follow Flux on Twitter or join the Flux LinkedIn group

We look forward to hearing from you!

0 views
Back to Blog

Related posts

Read more »

How OPA Changed Our Go-No-Go Forever

Learn how Open Policy Agent OPA transformed go/no-go releases from subjective meetings into automated, auditable, policy-driven decisions embedded directly in t...