Headlamp Ate the Kubernetes Dashboard: What Cluster API Operators Actually Get (and What a Git-Push PaaS Should Still Hide)

For a decade, the Kubernetes Dashboard was the first window most of us ever opened into a cluster. That window is now boarded up: upstream archived the Dashboard project, froze its release line, and pointed everyone at a successor most operators had only heard of in passing — Headlamp. If you run Cluster API on machines you own, this is not a cosmetic UI swap. It is a changing of the guard, complete with a brand-new Cluster API plugin, and it forces a decision every self-hosted platform has been postponing: where does a cluster console earn its place, and where is it just the complexity a git-push PaaS exists to hide?

The Dashboard is archived. Here is what that actually means​

Three hard facts, no euphemism. First, the Kubernetes Dashboard project has been archived and its repository moved to kubernetes-retired — there will be no more releases and no more CVE fixes. Community migration notes report the retired Helm chart line frozen at 7.14.0, and the project's old documentation site now returns a 404. Second, the official successor is Headlamp, and the recommendation comes from the top: a June 1 transition post by Will Case explaining the move, followed by a step-by-step migration guide on July 13 by Vincent T. Third, Headlamp is not some random third-party console anymore — the Kinvolk-created project (CNCF Sandbox since May 2023) officially joined Kubernetes SIG UI in 2025, announced during Microsoft's keynote at KubeCon Europe in London, and with the Dashboard gone it is now SIG UI's only project. The code lives at kubernetes-sigs/headlamp.

The verdict up front, for the impatient: adopt Headlamp as your operators' debugging console, keep it out of your tenants' path. It earns its place the moment someone needs to debug a stuck Cluster API reconciliation or inspect a Machine's conditions. It does not earn a place in the daily git-push flow, and it is not a substitute for your platform's own UX. The rest of this post is the evidence for that ruling.

Dashboard vs Headlamp: the before/after that matters to operators​

Both tools show you what is running in a cluster, but they work on different models. The migration guide puts it crisply: Dashboard is a UI that lives with the cluster; Headlamp is a UI that follows your identity. Here is the comparison that matters if you operate a fleet:

Two rows deserve emphasis. The identity row is the real migration work: if your team reaches the Dashboard through kubectl port-forward plus a long-lived service-account token, that whole access pattern goes away in favor of per-user kubeconfig identity (and ideally OIDC for the in-cluster deployment). The plugins row is the real payoff: the Dashboard could never show you a Cluster API MachineDeployment or a Flux reconciliation state, and Headlamp's plugin system means it now can.

The part CAPI operators should care about most: the Cluster API plugin​

Managing Cluster API resources has historically meant raw kubectl commands and deep familiarity with ownership hierarchies — Cluster owns control plane and MachineDeployments, MachineDeployments own MachineSets, MachineSets own Machines, and every layer has its own conditions to correlate by hand. On June 25, the Kubernetes blog introduced the Cluster API plugin for Headlamp, built by Chayan Das as a CNCF LFX mentorship project and released in alpha. It is the single biggest reason a CAPI operator should take this migration seriously:

• Cluster API health dashboard — centralized view of clusters, Machines, MachineDeployments, MachineSets, MachinePools, and control planes, with active condition issues surfaced and remediation guidance plus diagnostic commands when something degrades. This replaces the "explain to the new hire which ten kubectl get commands to run" onboarding ritual.
• Machine visibility — dedicated list and detail views for MachineDeployments, MachineSets, Machines, and MachinePools with replica counts, provider IDs, versions, and conditions on one page.
• Scale from the UI — adjust MachineDeployment and MachineSet replicas directly, with guardrails that redirect you to Cluster-level scaling for ClusterClass-managed (topology) clusters. Small feature, large trust signal: the plugin understands CAPI semantics instead of just editing replicas fields.
• Ownership-hierarchy map view — a visual graph of Cluster, control plane, and worker relationships. Anyone who has ever traced a stuck Machine up three levels of ownerReferences knows exactly what this replaces.
• Structured KubeadmConfig inspection — bootstrap configs rendered as structured data (files, kubelet args, volumes, join/init settings) instead of raw YAML fished out of Secrets.
• Inline Prometheus metrics — when the Headlamp Prometheus plugin is installed, live metrics render inside CAPI resource detail pages, so infrastructure state and performance data correlate in one screen.
• v1beta1 and v1beta2 support — dynamic API versioning matters right now, while the ecosystem is mid-migration to v1beta2 and a fleet may serve both.

Alpha means alpha: expect rough edges and shape the roadmap with feedback. But the direction is unmistakable — CAPI operations are getting a visual layer for the first time, built by someone who did the LFX mentorship specifically to study real-world CAPI usability pain.

It is not one plugin, it is a changing of the guard​

The CAPI plugin did not land alone. June 2026 also brought Headlamp plugins for Volcano (batch scheduling, gang-scheduled job queues) and Knative (serverless workloads), and July 13 brought a Kubeflow plugin for operating AI/ML workloads — every one of them announced on the official Kubernetes blog, several of them LFX mentorship projects. Add the previously shipped Flux (GitOps state beside the resources Flux manages), Prometheus, and AI-assistant plugins, and the pattern is clear: SIG UI is rebuilding the cluster-console ecosystem as composable plugins rather than one monolithic dashboard.

The enterprise signal arrived on August 12, when VMware shipped Headlamp as a VKS add-on on VCF 9.1 — notable because VKS clusters are themselves provisioned through Cluster API. When a vendor whose control plane is CAPI-based picks Headlamp as the console, the "third-party UI nobody asked for" objection loses most of its force.

Where Headlamp earns its place in a git-push PaaS — and where it does not​

Here is the ruling, in full. A self-hosted PaaS sells the promise that most operators — and all developers — should never need to open a Kubernetes UI. Adopting Headlamp does not contradict that promise, as long as you are deliberate about which side of each line it sits on.

Headlamp earns its place when:

• Debugging a stuck reconciliation. A MachineDeployment that will not roll, a Machine stuck provisioning on a Hetzner node, a control plane mid-upgrade — the CAPI dashboard's condition surfacing plus remediation guidance is genuinely faster than kubectl archaeology, especially at 3 AM.
• Inspecting Machine and condition status. Provider IDs, versions, replica counts, and conditions across the ownership hierarchy in one view is the daily bread of fleet ops.
• Onboarding new operators. The map view teaches the CAPI ownership model in minutes; the kubectl equivalent takes weeks of osmosis.
• Serving on-call through a shared in-cluster deployment. One bookmarked URL with SSO and RBAC beats "DM someone for the port-forward command" every time.
• Working across environments from the desktop app. Multi-cluster out of the box, using the kubeconfig the operator already has, with zero cluster resources consumed.

Headlamp does not earn a place when:

• It leaks into the tenant-facing path. Your tenants push git and get HTTPS; the moment a tenant needs a cluster console to understand their app, your platform UX has failed, no matter how nice the console is.
• It displaces GitOps as the source of truth. Scale-from-UI is a debugging convenience, not a deployment strategy. Click-ops that bypass the declared state recreate exactly the drift CAPI exists to eliminate.
• It replaces kubectl for operators who live in the terminal. Headlamp complements the CLI; mandating the console for people who debug faster in a terminal buys nothing.
• Plugin sprawl substitutes for platform thinking. Every plugin is another surface to version, secure, and explain. Install the three or four your team actually opens (CAPI, Prometheus, Flux if you run it) and stop.

The through-line: Headlamp is the fleet mechanic's diagnostic tablet, not the driver's dashboard. A git-push PaaS should run it, bless it, and keep it firmly on the operator's side of the glass.

The migration in one checklist​

Distilled from the official July 13 guide — the full post walks through desktop and in-cluster installs in detail:

1. Inventory today's usage. Which clusters and namespaces, which actions (view, edit, scale, delete, debug), how you reach the Dashboard (port-forward or ingress), and which service-account tokens and RBAC bindings that implies. This is your baseline and your rollback criterion.
2. Verify kubeconfig works. kubectl config current-context plus a read you expect to succeed. If kubectl can do it with your identity, desktop Headlamp can too — same identity, same RBAC.
3. Roll out in parallel (recommended). Install Headlamp, let the team try it, keep the Dashboard briefly, then remove it. Cutover is fine for personal clusters; parallel is safer for anything shared.
4. Pick desktop, in-cluster, or both. Desktop for day-to-day multi-cluster work with zero cluster footprint; in-cluster for the shared, team-managed, SSO-backed on-call URL. Most teams end up with both.
5. Cover the optional dependencies. metrics-server for CPU/memory graphs, an ingress for the in-cluster URL, OIDC/SSO for browser sign-in.
6. Delete the old world. Remove the Dashboard namespace and, critically, audit and delete its leftover service accounts and RBAC bindings — orphaned highly-privileged tokens are the part of this migration most teams forget.

One UI lineage to track​

Step back and the shape of 2026 is clear: SIG UI consolidated from two projects to one, the surviving UI speaks kubeconfig identity and multi-cluster natively, and the ecosystem's operational knowledge — CAPI fleet health, Volcano queues, Kubeflow pipelines, Flux state — is being rebuilt as plugins on top of it instead of scattered across vendor consoles. For a Cluster API operator on owned hardware, that consolidation is good news: one console to run, one plugin catalog to watch, and a CAPI debugging surface that will only mature past its current alpha.

The migration itself is small — an afternoon for a personal fleet, a sprint of parallel rollout for a shared one. The decision that matters is the one in the section above: bless Headlamp as the operator's console, and keep the tenant promise intact. Your developers should never need to know what a MachineDeployment is. Your on-call should be able to see all of them, with their conditions, in one screen.

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.