Dora NodaOn June 25, 2026, the Kubernetes blog published not one but three Headlamp plugin announcements in a single day: a Cluster API plugin, a Volcano plugin for batch workloads, and a Knative plugin for serverless. Two weeks later came a Kubeflow plugin and a Dashboard-to-Headlamp migration guide. That is not a coincidence. The official Kubernetes Dashboard was archived in early 2026 — "no longer maintained due to lack of active maintainers" — and Headlamp, now under kubernetes-sigs as the SIG-UI-endorsed successor, is absorbing everything the old Dashboard never did.
The Cluster API plugin is the most consequential of the batch for anyone running their own machines. It puts Machines, MachineDeployments, MachineSets, MachinePools, KubeadmControlPlanes, and KubeadmConfigs into a free, self-hostable browser UI — the exact objects a Cluster-API-based platform reconciles all day. The question this post answers is the practical one: which fleet-ops tasks can you now do in the browser, and which still need kubectl? Here is the verdict up front.
| Fleet-ops task | In Headlamp with the CAPI plugin? |
|---|---|
| See every cluster's control-plane and worker replica status at a glance | Yes — cluster list view with live replica status |
| Find out why a Machine is unhealthy without reading raw YAML | Yes — centralized dashboard surfacing active condition issues plus remediation guidance and diagnostic commands |
| Trace Cluster → MachineDeployment → MachineSet → Machine ownership | Yes — owned-resource hierarchy views plus a visual map view |
| Scale a MachineDeployment or MachineSet | Yes — built-in Scale action in the UI |
| Scale a ClusterClass-managed (topology) cluster's workers | Partial — the plugin tells you to scale at the Cluster level instead; the intent is right, the action still redirects you |
| Inspect bootstrap config (cloud-init files, kubelet args, join settings) | Yes — structured KubeadmConfig view, no secret-decoding by hand |
| Correlate a failing Machine with live metrics | Yes, if you also install the Prometheus plugin — metrics embed inline on detail pages |
| Roll out a Kubernetes version upgrade across the fleet | No — replica/version tracking is visible, but the upgrade itself is still kubectl and controller reconciliation |
| Manage providers, ClusterClasses, or air-gapped installs | No — provider lifecycle and supply chain are out of scope |
| Show tenants "your apps on your machines" in one view | No — generic CAPI objects only; the tenant-facing dashboard is still yours to build |
That table is the whole post in miniature: a genuinely useful operator console for the management cluster, still an Alpha, and not a replacement for the dashboard your tenants see. The rest of this post fills in each row.
What the plugin actually ships
The announcement post by Chayan Das reads like a release checklist, and the checklist is strong. The plugin adds a dedicated Cluster API section to Headlamp's sidebar with consistent list and detail views across the core resources, plus three things that go beyond pretty kubectl output.
First, the Cluster API dashboard: a centralized health view across the management cluster summarizing clusters, Machines, MachineDeployments, MachinePools, MachineSets, and control planes, with active condition issues called out alongside provider information and config-template counts. Selecting a cluster opens a health view with control-plane and worker status, machine info, infrastructure details, and resource conditions — and when something is wrong, it offers remediation guidance with diagnostic commands. That last part matters more than it sounds: the failure mode of CAPI operations has always been "a condition you have never seen before on an object three ownership levels down." Surfacing the condition and the next command in one place is the difference between a five-minute triage and a forty-minute one.
Second, write actions where they are safe: a built-in Scale action on MachineDeployments and MachineSets. Scaling is the one mutating fleet operation that is both frequent and low-risk — no template rendering, no version skew to reason about — so it is the right first write op. For topology-managed (ClusterClass) clusters, the plugin correctly refuses to pretend a MachineDeployment scale is the right move and points you at the Cluster object instead.
Third, context around the objects: a map view of Cluster → control plane → worker relationships, topology-awareness labels for ClusterClass-managed resources, structured KubeadmConfig inspection (inline files, kubelet args, extra volumes, init/join settings), support for both CAPI v1beta1 and v1beta2, and inline Prometheus metrics on Cluster, MachineDeployment, MachineSet, and Machine detail pages when the Prometheus plugin is installed.
The install bar is low: Headlamp >= 0.13.1, Cluster API v1beta1 or v1beta2, Kubernetes 1.26+ — see the plugin README. Version honesty matters here: it shipped as 0.1.0-alpha, with a 0.2.0-beta following in the headlamp-k8s/plugins repo. Alpha means the API surface and views can still shift under you; plan to pin the plugin version alongside your Headlamp deploy rather than floating.
Why the timing matters: the Dashboard is gone, and mentorship is the engine
Two pieces of context turn this from "nice plugin" into "plan around it."
The first is the vacuum. The Kubernetes Dashboard — the default kubectl proxy UI a generation of operators learned on — was archived in early 2026 after its maintainers ran out. Its own repo points at Headlamp, which graduated from CNCF Sandbox into kubernetes-sigs under SIG-UI. VMware now ships Headlamp as a vSphere Kubernetes Service add-on, and community distros pin it by Helm chart version. When the ecosystem's default UI changes, every "just look at the dashboard" runbook entry needs a new target. For CAPI fleets, this plugin is that target taking shape.
The second is how the plugins get built. The CAPI plugin was developed inside the CNCF LFX Mentorship program under the Headlamp project — a mentee working with maintainers, shaped by real usability discussions, with work explicitly continuing beyond the Alpha. The same pipeline produced the Volcano and Knative plugins and has the Kubeflow, Strimzi, and Knative-Eventing efforts in flight (the September–November 2026 mentorship term lists Knative Eventing UI plus Prometheus integration as deliverables). That is a durable feature factory, not a one-off contribution: expect the plugin surface to keep widening roughly quarterly. Betting an internal runbook on the CAPI plugin is therefore betting on a maintained upstream with a staffing model — a much safer bet than the last eighteen months of the old Dashboard.
The one-console story is the payoff. A small ops team running AI-agent sandboxes next to ordinary tenant apps can now keep Cluster API (fleet lifecycle), Volcano (batch queues), Knative (serverless revisions and traffic splits), and Prometheus (live metrics) in one browser tab instead of four CLIs. None of these plugins is deep on its own yet — all Alpha — but the composition is the point: one auth model, one navigation tree, zero bespoke frontend code to maintain.
Where it falls short of "your machines, your apps, one view"
The TODO item that prompted this post names the gap precisely, and it holds up: Headlamp's generic plugin model is not a purpose-built tenant dashboard. Four limits are worth stating plainly.
It shows infrastructure objects, not tenant reality. A MachineDeployment at 3/3 replicas with clean conditions can still be serving 500s to every tenant on it. The plugin answers "is the fleet reconciled?" — it does not answer "are my customers' apps healthy?" Bridging that gap (joining CAPI machine state with workload health per tenant) is product-specific logic no generic plugin can ship. If you run a PaaS, your tenant dashboard still needs to exist; Headlamp becomes the operator console behind it, not the console itself.
Write operations stop at scaling. Upgrades, remediation application, provider installs, ClusterClass edits — the consequential mutations — remain kubectl, clusterctl, and GitOps pipelines. That is arguably correct for an Alpha (a UI "upgrade cluster" button with no dry-run would be a footgun), but it sets the ceiling: Headlamp shortens diagnosis, not intervention, for anything beyond replica counts.
Topology-managed clusters get guidance, not action. The plugin detects ClusterClass-managed resources and tells you to scale at the Cluster level. Good advice, but the operator still context-switches to do it. Until the plugin can edit the topology replicas field inline, the most modern CAPI setups get the least UI leverage.
Alpha means pinning and patience. Conditions schemas differ between v1beta1 and v1beta2, the plugin supports both today, and views may churn before GA. Treat it as a read-mostly triage console in production now; gate any automation or screenshots-in-runbooks on pinned versions.
None of these is a reason to skip it. They are reasons to deploy it for the team that owns the management cluster while keeping tenant-facing status exactly where it is.
What a Cluster-API-based PaaS should do this quarter
Concretely, for a platform shaped like ours — Cluster API provisioning Hetzner machines, git-push tenants on top:
- Deploy Headlamp with the CAPI + Prometheus plugins against the management cluster now. The triage value (conditions + remediation commands + inline metrics) is real at Alpha, and the install cost is one Helm release.
- Rewrite fleet runbooks to start at the dashboard, not
kubectl get machines. "Open the Cluster API dashboard, read the active condition issues, run the suggested diagnostic" is a strictly better on-call first step than paging through CRDs — especially for responders who don't live in CAPI daily. - Do not expose it to tenants. RBAC it to the platform team. The tenant view ("your apps, your machines") stays a product surface with your auth, your multi-tenancy model, and your workload-health joins.
- Track the mentorship pipeline, not just releases. The LFX terms are a public roadmap: Knative Eventing, Strimzi, and Kubeflow views landing over the next two quarters tell you when "one tab for everything" graduates from plausible to default.
The old Dashboard died because a generic UI with no maintainers is worse than no UI. Headlamp's answer — a maintained core plus a mentored plugin ecosystem — is structurally healthier, and the CAPI plugin is its best evidence so far. It will not run your fleet for you. It will show you your fleet, with the next command attached, for free, on hardware you own. For a self-hosted platform, that is exactly the right size of promise.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.
