Headlamp's Cluster API Plugin: Browser-Native Fleet Management Arrives for Clusters You Actually Own

Kubernetes Dashboard is archived. If you're running a fleet of clusters on hardware you own — Hetzner boxes managed with Cluster API rather than a rented EKS control plane — that leaves a real gap: no vendor console shows up for free the way it does on managed cloud Kubernetes. Until June 25, 2026, the honest answer to "how do I check on a stuck machine rollout" was kubectl get machines -o yaml, a text wall of conditions, and enough Cluster API muscle memory to read it. Headlamp's new Cluster API plugin puts that same reconciliation state in a browser tab instead.

The gap Dashboard's archival actually left​

Kubernetes Dashboard was built for one cluster at a time, browsed by one person, at a moment when "a cluster" was usually the whole deployment. It never really caught up to fleets. When the Kubernetes project archived it, the SIG UI group didn't recommend a fork — it recommended Headlamp, a CNCF Sandbox project (accepted May 2023) that joined SIG UI outright in 2025.

That matters more if you don't have a vendor console at all. A team on EKS or GKE gets AWS's or Google's own cluster UI whether they ask for it or not — it's part of what they're paying for. A team running Cluster API Provider Hetzner (CAPH) against owned hardware gets exactly what it builds or adopts, because there's no vendor bundling a console into the invoice. For roughly three years that meant Dashboard, then Dashboard-archived-and-frozen, then nothing but kubectl — the single biggest practical argument for Headlamp existing at all is that self-hosted, owned-hardware fleets are the ones with no fallback console when the official one goes away.

Headlamp's pitch beyond that is multi-cluster visibility, plugin extensibility, and both in-cluster and desktop deployment — a wider remit than Dashboard ever had. But until June 2026, none of its plugins spoke Cluster API specifically. A CAPI fleet's actual reconciliation objects — Cluster, Machine, MachineDeployment — were still kubectl-only, even inside a UI built to replace kubectl for everything else.

What the plugin actually puts in the browser​

The Cluster API plugin for Headlamp, built by Chayan Das through the CNCF LFX Mentorship program, closes that gap directly. It's not a generic "here are your custom resources" list — it understands the CAPI object model and renders it accordingly:

• Resource types: Cluster, Machine, MachineDeployment, MachineSet, MachinePool, KubeadmControlPlane, and KubeadmConfig all get dedicated views, not a raw YAML dump.
• A fleet health dashboard: a management-cluster-wide summary of cluster/machine/control-plane counts, active condition issues surfaced up front, provider info, and — per the release notes — remediation guidance and diagnostic commands alongside a flagged problem, not just a red status dot.
• A map view: a visual graph of how a Cluster, its control plane, and its worker MachineDeployments/MachineSets relate, instead of mentally reconstructing ownership chains from ownerReferences.
• Scale from the UI: MachineDeployment and MachineSet detail pages carry a Scale action that edits .spec.replicas directly — no kubectl scale or kubectl edit. For topology-managed (ClusterClass) clusters, the plugin instead flags that scaling belongs at the Cluster level and points there.
• Prometheus metrics inline: when Headlamp's Prometheus plugin is also installed, CPU/memory metrics render directly on Cluster, MachineDeployment, MachineSet, and Machine detail pages.
• Both CAPI API versions: the plugin detects and renders v1beta1 and v1beta2 resources, so it doesn't force a Cluster API upgrade just to get a UI.

That resource list is the actual artifact this plugin ships — not "a nicer dashboard" in the abstract, but these seven object types, this specific set of actions, on this data.

The before/after: a stuck machine rollout​

Here's the concrete case the plugin is built for, worked both ways.

Today, without the plugin. A MachineDeployment rollout stalls — a new machine set isn't reaching Ready. The diagnosis path is:

kubectl get machinedeployments -o wide
kubectl get machinesets -l cluster.x-k8s.io/deployment-name=<md-name>
kubectl get machines -l cluster.x-k8s.io/set-name=<ms-name> -o yaml

Then you read through each Machine's .status.conditions block by hand, cross-reference which MachineSet is old and which is new, check whether the infra provider (CAPH, in this case) has flagged a node as failed, and only then form a hypothesis — did the new machine's KubeadmConfig fail to bootstrap, or is Hetzner's API rejecting the server create? That's three-plus kubectl invocations and a mental join across four object kinds before you even know where to look next.

With the plugin. The fleet health dashboard flags the degraded MachineDeployment on load — no separate query needed. Opening it shows the map view: old MachineSet still Ready, new one stuck, with the specific Machine highlighted. Its detail page surfaces the exact condition and message (bootstrap failure vs. infra-provisioning failure) without a manual -o yaml read, and if Prometheus is wired up, the node's resource graphs sit right there too. The kubectl cross-referencing doesn't go away — the plugin is reading the same objects — but the four-kind mental join collapses into two clicks. That's the actual time saved: not "kubectl is gone," but "you stop doing the join in your head."

A drifted node pool is diagnosed the same underlying way. "Drift" here means a worker pool's live MachineSet no longer matches what its MachineDeployment (or, for topology-managed clusters, the ClusterClass) currently asks for — an old machine image still in rotation, a bootstrap config that changed without a rollout, a pool that was hand-edited outside of Git. Today, spotting that means comparing a MachineSet's template against its owning MachineDeployment's current spec by eye, across separate kubectl get -o yaml calls, because nothing surfaces the comparison for you. The plugin doesn't invent a new "drift detector," but it removes the manual object-hopping: topology awareness labels which resources are ClusterClass-managed, and the map view puts the MachineDeployment's spec and its MachineSet's current state in the same visual hierarchy, so a stale worker pool is something you notice by looking at one screen instead of something you have to go compute.

Where the plugin actually stands today​

Worth being honest about maturity before anyone routes on-call around it. The ArtifactHub listing has it at 0.2.0-beta, and the CNCF LFX Mentorship writeup describes the June release as an initial Alpha with "additional improvements and features planned" — this is a single mentee's mentorship deliverable, not a multi-year, multi-maintainer subsystem the way kubectl or the CAPI controllers themselves are. That doesn't make it unusable — a health dashboard that's occasionally behind on an edge-case condition string is still strictly better than no dashboard — but it does mean the Scale action and condition surfacing are new code paths worth spot-checking against kubectl get output for a while before anyone trusts them blind during an incident.

Practically, that maturity level sets the right adoption pattern for a self-hosted fleet: install it as a read-mostly aid — the health dashboard, the map view, the condition surfacing — before leaning on the Scale action as your primary path for a production change. Nothing about the plugin bypasses RBAC or introduces a new write path outside the Kubernetes API; a scale click is still just a PATCH against the same MachineDeployment object kubectl scale would touch, gated by whatever role the browser session already has. The risk isn't a new privilege-escalation surface, it's ordinary early-plugin risk — a UI that hasn't yet seen every CAPI provider's condition strings or every ClusterClass topology shape in production, and that's worth a few weeks of running it alongside kubectl, not instead of it, before it becomes the default lens.

The plugin ecosystem, and the console question​

The CAPI plugin didn't ship alone. The same week, Headlamp also released plugins for Knative (serverless traffic and autoscaling visibility) and Volcano (batch/HPC job-queue visibility) — and Headlamp's plugin catalog separately already lists a Karpenter plugin for node-autoscaler visibility. Four plugin releases covering cluster lifecycle, serverless workloads, batch scheduling, and autoscaling, landing within weeks of each other, is a stronger signal than any one of them alone: Headlamp isn't just "the thing that replaced Dashboard," it's accumulating the plugin surface to be the default console for whatever a self-hosted operator is actually running — CAPI fleets, Knative services, batch jobs, autoscaled node pools — under one browser tab instead of four different vendor tools, each with its own login and its own mental model.

That breadth is the actual case for standardizing on Headlamp over rolling a one-off internal UI for each subsystem: a plugin ecosystem means the next CNCF sub-project that matters to your fleet — whatever it turns out to be — has a reasonable chance of getting a Headlamp plugin before your team would otherwise get around to building a bespoke view for it.

That's a real gap-filler for a team that owns its hardware and wants a general-purpose cluster UI without writing one. It's also worth being precise about where it stops. A generic CAPI viewer shows you Cluster and Machine objects; it doesn't know that a Machine on your fleet maps to a specific tenant's app, doesn't gate a scale action behind your platform's own deploy/rollback semantics, and doesn't reason about your fleet's capacity plan. That's the line between "a cluster UI that understands Cluster API" and "a PaaS control plane that understands your fleet" — Headlamp is closing the first gap well; the second one is still a purpose-built platform's job.

Bex.co runs exactly this kind of Cluster-API-managed fleet on owned Hetzner hardware — push a git repo, get a running HTTPS service, no rented control plane in between. Star the repo on GitHub or deploy your first app today.