AI
Flux 2.8: Helm v4 and Server-Side Apply
Flux 2.8 went GA with Helm v4 integration after roughly three months of migration work. The headline change is Kubernetes server-side apply inside helm-controller. Helm CLI users running one release in a CI runner don’t care about memory or latency. Flux does: it must upgrade hundreds of Helm releases in parallel and keep charts sealed inside the controller for security. Server-side apply reduces cluster operations, making helm-controller lighter and better at scale.
Custom Resource Health Checks in Helm Charts
Before 2.8, dropping a custom resource into a Helm chart meant the chart reported “release ready” even when the resource was not. Flux now accepts CEL expressions on a HelmRelease to define readiness for any custom resource, whether a PGCluster, a Cluster API cluster, or anything else. The CEL library is documented. Customization-controller had this capability from the start; helm-controller now matches it, giving a uniform health-check model across all Flux controllers.
Upgrade Cancellation: Cutting Mean Time to Recovery
A Helm release with a 30-minute timeout blocked every subsequent change until that timeout expired. Fix a typo in values, push the commit, wait anyway. Six months of work produced a signal that tells the controller to cancel ongoing health checks, mark the release as failed with a cancellation reason, and start the next upgrade immediately. The feature is behind a feature gate now. Flux plans to make it the default in Q1 next year. Teams with high-commit-velocity dev clusters should test it first.
Why Flux Ships No Official UI
Flux is designed as loosely coupled controllers and APIs. Owning an official UI would force API design decisions around that UI. The project chose not to do that, leaving UI work to the community. The result: Freelens updates its Flux plugin faster than any other desktop app and already supports Flux Operator custom resources. Headlamp integrates Flagger and Prometheus and suits users who want a holistic cluster view. Capacitor takes a focused debugging approach. K9s has had a stable plugin for years, and flux9s, a Rust rewrite, is in beta.
The Flux Operator UI: SSO, RBAC, and 10,000 Helm Releases at 32 MB
The UI built into flux-operator is mobile-first and requires only an ingress to expose. It integrates with Dex for SSO, reads group claims from the IDP JWT, and impersonates those groups exactly as Flux does. A developer with access to three namespaces sees only those three namespaces. Because the UI runs inside flux-operator, it reads the controller-runtime cache rather than querying the cluster per operation. That lets it search and filter 10,000 Helm releases using 32 megabytes of memory. All actions map to custom Kubernetes RBAC verbs, so permissions like “suspend” are granted through standard role bindings.
Q&A
Is the flux-operator UI a multicluster dashboard? No. It runs per cluster inside flux-operator; hub-and-spoke setups work but running Flux everywhere is the recommended approach. ▶ 32:27
Will Flagger get a dedicated view in this UI? Yes. A Flagger UI is planned once the Flagger API is refactored and promoted to v1. ▶ 32:59
Is there a plugin system for custom UIs? Not yet. Untrusted code running inside flux-operator is a security concern and a plugin system may never arrive. ▶ 33:32
Notable Quotes
we finally have Helm before support. Stefan Prodan · ▶ 01:20
if you put a custom resource in a chart good luck the chart says yes it’s all okay release ready Stefan Prodan · ▶ 05:15
We designed Flux as a set of controllers and loose couple APIs. Stefan Prodan · ▶ 15:15
we can allow you to search and filter 10,000 hand releases on a cluster in using 32 megabyte of memory Stefan Prodan · ▶ 28:00
Key Takeaways
- Flux 2.8 adds server-side apply to helm-controller, reducing cluster queries for large Helm workloads.
- Upgrade cancellation ends 30-minute timeout waits when values change mid-rollout; default in Q1.
- The flux-operator UI filters 10,000 Helm releases at 32 MB using controller-runtime cache, not live queries.
About the Speaker(s)
Stefan Prodan is a Principal Engineer at ControlPlane and a core maintainer of the CNCF Flux project. He created Flagger, the progressive delivery operator for Kubernetes, and brings over 20 years of software experience to cloud-native open source work.