FluxCD 2.8 GA: Helm v4, Server-Side Apply, and a Release Inventory That Actually Works

You know that moment when you're staring at a HelmRelease that says Ready: True and you're still not quite sure what's actually running in the cluster? You've got the chart, you've got the values, but the definitive answer to "what Kubernetes resources did this release create?" has always required either running helm get manifest or squinting at the chart templates until something clicked. It's a gap. And it matters more than it sounds because drift detection, auditing, and debugging all depend on being able to compare what Flux says it deployed against what's actually there.

FluxCD 2.8, released in February 2026, fixes that with the HelmRelease resource inventory — .status.inventory now tracks every resource a release created. That's the headline for me. But there's more: Helm v4 is now the default, which brings server-side apply and kstatus health checking, and the way those work has implications for how upgrades and health assessment behave. Not scary changes, but worth understanding before you upgrade.

Quick takeaways¶

Helm v4 is now the default — server-side apply and kstatus health checking are on by default for HelmReleases; test against any admission controllers or CRD validation webhooks before rolling to production
.status.inventory is now populated on every HelmRelease, giving you a proper resource-level view of what a release actually created
CancelHealthCheckOnNewRevision is more responsive — it now triggers on ConfigMap/Secret changes and manual reconcile calls, not just new chart versions
Check the migration guide for API removals — some v1beta2 APIs are gone; this is the thing most likely to bite you on upgrade

Check for v1beta2 API usage before upgrading

The v1beta2 HelmRelease API is removed in 2.8. If you're generating or templating HelmRelease manifests anywhere — CI pipelines, Helm charts that include HelmRelease templates, scripts — verify you're using helm.toolkit.fluxcd.io/v2 before upgrading. This is the most likely breaking change for teams upgrading from 2.6 or earlier.

Helm v4 as the default — what actually changed¶

The shift to Helm v4 as the default brings two meaningful changes to how HelmReleases behave: server-side apply (SSA) instead of three-way merge, and kstatus health checking on by default.

Server-side apply is how Kubernetes itself manages field ownership. Rather than client-side diffing between your desired state, the live state, and the last-applied annotation, SSA lets the API server track who owns what field. It handles conflicts more reliably, integrates better with how other controllers manage resources, and generally produces less surprising behaviour when multiple actors are touching the same object. For most workloads you won't notice the difference in day-to-day operation — but it's a more correct model.

kstatus health checking is also worth understanding. Instead of relying on the simpler ready-condition checks, kstatus evaluates resource health using the same conventions the Kubernetes ecosystem broadly uses for structured conditions. Your HelmReleases will get more accurate health signals as a result.

Here's what a HelmRelease looks like with the new defaults in place — the spec itself doesn't change much, but it's worth being explicit about remediation settings now that defaults have shifted:

apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
  name: my-app
  namespace: default
spec:
  chart:
    spec:
      chart: my-app
      version: "1.2.3"
      sourceRef:
        kind: HelmRepository
        name: my-charts
  # Server-side apply is now the default in 2.8
  # kstatus health checking is now on by default
  install:
    remediation:
      retries: 3
  upgrade:
    remediation:
      retries: 3
      remediateLastFailure: true

The important caveat: if your workloads use CRDs with validation webhooks or have custom admission controllers, test SSA behaviour carefully before rolling out to production. Server-side apply has different field conflict semantics to three-way merge. In most cases it's more lenient, but admission controllers that were written with three-way merge assumptions can behave unexpectedly. Test first.

Apply this: make remediation settings explicit after upgrading

With the shift to Helm v4, some default behaviours around install and upgrade remediation have changed. Don't rely on inherited defaults — be explicit in your HelmRelease specs about retry counts and remediateLastFailure. Takes five minutes per release and prevents surprising non-remediation behaviour after the upgrade.

The resource inventory — finally knowing what you deployed¶

This is the feature worth getting genuinely excited about. Before 2.8, the question "what Kubernetes resources does this HelmRelease own?" had no clean answer from Flux's perspective. You could look at the chart, run helm get manifest, or check the release secret — but none of that was surfaced as structured data in the HelmRelease status. Now it is.

.status.inventory tracks the full list of resources a release created. Here's what it looks like:

status:
  inventory:
    entries:
    - id: default_my-app-deployment_apps_Deployment
      v: v1
    - id: default_my-app-service_/v1_Service
      v: v1
    - id: default_my-app_networking.k8s.io_Ingress
      v: v1

Think about what this unlocks. Drift detection tooling can now compare what Flux says it deployed against what's actually in the cluster — and do it resource by resource, not just at the HelmRelease level. Audit trails get real: you have a timestamped record of what existed at any point, embedded in the object itself. And when you're debugging a missing resource, you don't have to excavate the chart templates to figure out whether Flux was ever supposed to create it. You just check the inventory.

For teams running Flux at scale, this is the kind of operational visibility that was previously only available by building your own tooling around helm get manifest. Now it comes for free.

Resource inventory unlocks per-resource drift detection

With .status.inventory populated, you can compare what Flux says exists against what's actually in the cluster resource by resource — not just at the HelmRelease level. This is the data model that makes automated drift detection accurate. For teams building or using GitOps drift detection tooling, 2.8 removes the last major gap.

CancelHealthCheckOnNewRevision improvements¶

Previously, CancelHealthCheckOnNewRevision only activated when a new chart version was released. The logic was: if a new version is coming, cancel the current health check and start fresh. Sensible enough, but it meant the feature was blind to other kinds of changes.

In 2.8, it also responds to ConfigMap and Secret changes that a HelmRelease references, and to manual flux reconcile triggers. The practical effect is that health checks are now responsive to the full range of changes that matter — not just chart bumps. If you update a ConfigMap that drives a HelmRelease's values and trigger a reconcile, the health check starts fresh rather than running against stale assumptions. More correct behaviour, less head-scratching.

The Flux Web UI¶

It exists. It's early. It's available via the Flux Operator, previewed at KubeCon Atlanta in late 2025. Don't rush to production with it.

But here's why it's worth watching: the long-standing gap in the Flux ecosystem has been a read-only view of your GitOps state that doesn't require giving everyone kubectl access. The Web UI is a credible answer to that problem. If it matures well, it could meaningfully lower the barrier to GitOps visibility for teams where not everyone is comfortable in the CLI. Keep an eye on it.

Before you upgrade — check these¶

Don't just bump the version. Genuinely work through this list first:

Review the API removals in the migration guide. The v1beta2 HelmRelease API has been removed. If you're generating or templating HelmRelease manifests anywhere — in CI, in Helm charts, in scripts — make sure you're on helm.toolkit.fluxcd.io/v2.
Test HelmReleases with custom admission controllers against SSA behaviour. Especially anything with CEL-based validation or complex mutation webhooks. SSA's field ownership model interacts differently with these than three-way merge did.
Make your remediation settings explicit. Don't rely on previous defaults. With the shift to Helm v4, some default behaviours around install and upgrade remediation have changed. Be deliberate.
Check Helm chart compatibility with Helm v4's stricter validation. Some charts that passed validation under Helm v3 will fail under v4. Run helm lint against your charts with a Helm v4 client before you're surprised in a production reconciliation.

Run helm lint with a v4 client before upgrading

Helm v4 has stricter chart validation than v3. Charts that passed helm lint under v3 can fail under v4. Run helm lint against all your charts using a Helm v4 client in a test environment before the Flux upgrade — don't discover the validation failures during a production reconciliation cycle.

Frequently asked questions¶

Do I need to change my HelmRelease specs when upgrading to 2.8?

For most teams: no. The API version is still helm.toolkit.fluxcd.io/v2 (assuming you're already on v2 specs). The new defaults — SSA, kstatus health checking — activate without requiring spec changes. What you might want to do is make remediation settings explicit rather than relying on inherited defaults, since those have shifted slightly.

Will server-side apply break anything that worked with three-way merge?

Probably not, for standard workloads. The risk area is custom admission controllers and CRD validation webhooks, particularly ones written with three-way merge field semantics in mind. If you don't have either of those, SSA is broadly a drop-in improvement. If you do, test it in a non-production cluster first.

Is the resource inventory retroactively populated, or only for new releases?

It's populated on the next successful reconciliation. You don't need to reinstall or recreate your HelmReleases — once 2.8 is running, the inventory will be written the next time each release reconciles. For active clusters this usually happens quickly; for releases that haven't changed recently, trigger a manual reconcile with flux reconcile helmrelease <name>.

We're on Flux 2.6 — do we need to upgrade to 2.7 first?

Check the FluxCD upgrade guide for your specific version path, but in general Flux supports upgrading directly across minor versions rather than requiring sequential hops. The more important thing is the API removal check — make sure you're not using any APIs that were deprecated in 2.7 and removed in 2.8 before you jump.

Does the new Flux Web UI replace the Weave GitOps UI?

They serve similar purposes but are different products. The Flux Web UI is available via the Flux Operator and is still early. Weave GitOps (from Weaveworks) is a more mature option that some teams are already running. If you're evaluating UI options for Flux, look at both — the native Flux Web UI is the direction of travel but it's not production-ready for all use cases yet.

What you get¶

Full resource inventory on every HelmRelease via .status.inventory — finally a structured answer to "what did this release actually create?"
More reliable Helm reconciliation via server-side apply and kstatus health checking, with graceful overflow instead of hard failures
More responsive health checking on ConfigMap/Secret changes and manual reconcile triggers, not just chart version bumps
A Web UI on the horizon via Flux Operator — early, but worth watching for teams that need GitOps visibility without universal kubectl access