Dora NodaOn January 21, 2026, the original Kubernetes Dashboard project was archived. No CVE, no scandal — just a slow drain of maintainers until the Kubernetes project pulled the plug and pointed everyone to its replacement: Headlamp, the CNCF Sandbox project that the Kubernetes SIG UI adopted as its official recommendation in 2025. Five months later, on June 25, 2026, Headlamp released something specific for fleet operators: an official Cluster API plugin.
That timing is not a coincidence — it's a changing of the guard. The old Dashboard showed you Pods and Deployments inside a single cluster. The new plugin is built for a completely different job: watching the clusters themselves, across an entire fleet, as Cluster API (CAPI) machines are created, drained, and replaced underneath them. If you run a self-hosted PaaS on CAPI-managed infrastructure — including bex's Hetzner node pools — that used to mean kubectl get machines -o yaml on every management cluster you operate, reading raw CRD state by hand. Here's exactly what the plugin replaces, what it doesn't, and whether a small platform team should adopt it instead of building a custom fleet dashboard.
What the Plugin Actually Exposes
The Kubernetes blog announcement is specific about scope, so here's the concrete feature list instead of a vague "it has a nice UI":
- A fleet-level CAPI dashboard — a screen summarizing health status across Clusters, Machines, MachineDeployments, MachineSets, MachinePools, and control planes on a management cluster.
- Active condition highlighting with remediation guidance — degraded or unhealthy resources appear with attached diagnostic commands, not just a red dot you then have to debug blindly.
- Owner resource hierarchy tracing — click a Cluster and see the MachineDeployment → MachineSet → Machine chain underneath it, instead of cross-referencing
ownerReferencesmanually across fourkubectl getcalls. - Dedicated KubeadmControlPlane and KubeadmConfig views — control plane replica counts and versions, plus bootstrap configuration details (files, kubelet arguments, join/init settings) that today live in base64-encoded Secret data most people never actually open.
- Automatic ClusterClass topology detection — clusters built from a
ClusterClasstemplate are tagged and grouped accordingly, without manual labeling. - In-UI scaling for MachineDeployments and MachineSets — no
kubectl editrequired for a routine replica bump. - Dynamic v1beta1/v1beta2 API versioning — the plugin detects which CAPI API version a management cluster runs and adapts, so a fleet mid-migration between versions doesn't need two different tools.
That list is worth being precise about, because it's tempting to bundle Cluster API v1.12's headline features — in-place updates and chained upgrades, released five months earlier — as things "the plugin shows you." They aren't, at least not yet. v1.12 lets you change a Machine's Kubernetes version in place instead of deleting and recreating it, and lets a single Cluster spec jump multiple minor versions in one operation with CAPI calculating the intermediate steps. That's real complexity, shipped separately, in what a Machine's lifecycle state can now look like — an in-flight upgrade, mid-chain, versus terminal — and the June plugin announcement doesn't claim to represent that state distinctly. It's the next obvious thing a CAPI-focused UI needs to catch up on, not something it already does.
Where the UI Really Replaces Manual CLI Work
For a small platform team — two or three people running a fleet, not a dedicated platform organization — the plugin's real benefit shows up at 3 a.m., not in a demo.
Today, debugging "why is client X's application unreachable" when the underlying cause is an unhealthy Machine means: kubectl get machines -A, spot the one with a weird status, kubectl describe it, trace its ownerReferences to the MachineSet and MachineDeployment manually, cross-reference the KubeadmConfig Secret to check if it was a bootstrap failure, and do all this while context-switching across every management cluster your fleet spans. None of that is hard individually. All of it is slow exactly when slow is expensive, and it's the kind of multi-step correlation that's easy to get wrong under pressure or when the on-call engineer isn't the person who wrote the CAPI configuration.
The plugin collapses that into a single screen with the hierarchy already traced and the condition already flagged with a suggested diagnostic command. That's a genuine reduction in cognitive load during an incident — not a new capability, but fewer distinct steps a tired human has to chain together correctly. It's also a real onboarding win: a new hire can look at fleet health without first learning the CAPI CRD graph.
Where kubectl and GitOps Still Win
None of that makes the plugin a replacement for how a fleet's state is actually changed. Current fleet management practice converges on a clear split: dashboards for visibility and debugging, GitOps for source of truth. That split holds here for a specific reason — the plugin is a read-and-observe layer sitting on top of the Kubernetes API, not a desired-state store itself. Every Cluster, MachineDeployment, and ClusterClass it renders was declared somewhere else, in a manifest, and a GitOps controller is still what reconciles that manifest against reality.
That distinction has teeth. A platform team that starts treating the plugin UI's scale button as their normal workflow for changing MachineDeployment replica counts has just recreated the exact problem GitOps exists to solve: a live cluster whose actual state has silently drifted from what's recorded in Git, with no diff, no review, no audit trail, and no way to reconstruct why a change happened after the fact. The plugin won't warn you about this — it happily lets you scale a MachineDeployment that a Git-tracked manifest still says should be a different size, and the next git push-triggered reconciliation will fight you over it. Use it to see what changed and why a Machine is unhealthy; use Git and a reconciler to actually change anything, and treat the UI scale button as an emergency action, not a routine one.
Why Headlamp, and Not One of the Other Dashboards
The Dashboard's archive left a real gap, and the ecosystem noticed — Kubernetes UI option surveys published after the retirement list nine or more contenders: Lens, K9s, Portainer, Rancher, OpenLens forks, various Octant successors, and Headlamp among them. Most of those tools solve the job the original Dashboard solved — navigating Pods, Deployments, Services inside a single cluster — competently. None of them shipped a Cluster API plugin built by the people who maintain the Cluster API tooling ecosystem.
That's the detail that really matters for a fleet management decision, rather than a single-cluster navigation one. Headlamp's plugin architecture — the same extensibility model that let SIG UI ship a Knative plugin the same week as the CAPI one — means the tool isn't a generic dashboard with CAPI resources tacked on as just another CRD it happens to render. It's a plugin surface where the people building Cluster API can (and did) ship first-class views for their own CRDs, including the ownership hierarchy tracing and remediation guidance that a generic "show me any CRD" browser has no way to know how to build. A tool like K9s or Portainer would need someone to build that same CAPI-aware logic from scratch and then maintain it as CAPI CRD shapes evolve through v1beta1, v1beta2, and whatever comes next. Headlamp gets that maintenance for free by being the upstream's own answer.
That's also why "officially recommended successor to the retired Dashboard" is doing real work in the adoption case below, and not just a credibility garnish — it's a signal about who's going to keep this thing alive and updated five Cluster API versions from now, which is precisely the maintenance burden question a small platform team should ask before hooking a dashboard into their operator workflow.
Should Bex Ship It?
This is the concrete question worth answering instead of rambling: given that bex already runs Cluster API against Hetzner node pools, should the operator-facing fleet view be a custom dashboard built from scratch, or Headlamp with this plugin?
Adopt it. Three reasons, in order of how much they matter:
- It's already the officially recommended tool, actively maintained under CNCF/SIG-UI governance with a monthly release cadence — not a side project bex would inherit maintenance risk from by depending on it.
- The feature set is exactly the shape of the problem — fleet-level CAPI status, condition-based health, ownership hierarchy tracing — that a custom dashboard would spend real engineering time rebuilding, badly, as a v1.
- It composes instead of competing. Because the plugin is a pure observability layer on top of the Kubernetes API, embedding it (or building bex's own operator view against the same CAPI resources it reads) doesn't require touching how bex's actual desired-state changes propagate — that stays exactly where it already is: a
bex.ymlin a tenant's repository, applied viagit push, never via a UI edit.
The honest scope: this wins bex's own fleet operations surface — the view an operator or support engineer reaches for when debugging a customer's deployment — not the mechanism by which deployments happen. That remains the git-push-to-running-service path around which bex is built, intact.
Bex.co is the open-source, AI-native alternative to Render — push a git repo, get a running HTTPS service on machines you own, with the underlying fleet managed by Cluster API instead of hand-rolled scripts. Star the repo on GitHub or deploy your first app today.
Sources
- Introducing the Cluster API Plugin for Headlamp — kubernetes.io.
- Cluster API v1.12: Introducing In-place Updates and Chained Upgrades — kubernetes.io.
- Headlamp — CNCF Projects.
- Kubernetes Dashboard Alternatives in 2026: Best Web UI Options After Official Retirement — DEV Community.
- Cluster API v1.12: Introducing in-place updates and chained upgrades — CNCF.
