Kubernetes Dashboard Is Officially Dead: What Breaks When You Move to Headlamp

The Kubernetes Dashboard repository was archived on January 21, 2026. It now lives under kubernetes-retired/dashboard — read-only, no more commits, no more releases. On June 1, the Kubernetes project made it official on the main blog: Headlamp is the recommended successor, and a follow-up migration guide landed on July 13. If your team still has a bookmark pointing at a kubectl proxy URL and a service account token taped to the inside of a runbook, here's exactly what carries over, what doesn't, and what a Cluster-API fleet specifically gains from the switch.

What Actually Breaks​

Start with the access pattern, because it's the thing most likely to be muscle memory. The classic Dashboard workflow was kubectl proxy followed by a URL that looked like this:

http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/

That URL is gone. Headlamp doesn't replicate the Dashboard's aggregated-API-server proxy path, so no bookmark pointing at it will resolve to anything. In its place, Headlamp supports two access models: a desktop app that reads your existing kubeconfig directly (no proxy step at all), or an in-cluster deployment reached through kubectl port-forward or a regular ingress, the same way you'd reach any other service you run. If your team's documented "how to open the dashboard" instructions are literally the proxy command above, they need to be rewritten, not patched.

The underlying deployment model shifted too, not just the URL:

The desktop option is new territory for teams used to Dashboard: point Headlamp at your existing kubeconfig and it lists every context you already have kubectl access to, with zero cluster-side deployment at all. For a platform team juggling more than one cluster — which describes almost anyone running Cluster API — that alone removes a login step Dashboard never had a way around.

Two more things don't carry over cleanly:

• Resource creation is YAML-first. Dashboard's guided forms for creating a Deployment or ConfigMap have no equivalent — Headlamp gives you a YAML editor. If your team relied on the forms because nobody had kubectl apply memorized, that's now a real onboarding gap, not a UI preference.
• Bookmarked deep links break. Headlamp's URL structure isn't compatible with Dashboard's, so any saved link to a specific pod or namespace view needs to be re-bookmarked after migration, not just redirected.

What Doesn't Break​

The good news is narrower but real: RBAC is where the two tools actually agree. Headlamp authenticates the same way Dashboard did in-cluster — a service account token bound to whatever ClusterRole or Role you want the UI to be limited to — and existing bindings transfer without modification. If you scoped a read-only viewer role for Dashboard, that same RoleBinding works unchanged for Headlamp. Both tools ultimately just call the Kubernetes API as whatever identity you hand them and let the API server's RBAC layer decide what's visible; neither tool invents its own permission model on top. The view/edit/scale/delete operations you're used to running against pods, deployments, and namespaces are all present in Headlamp too — it's not a narrower tool, it just gets you there through a different UI shell.

Why Headlamp, Not Just "a New Dashboard"​

The one-line summary the Kubernetes project gives for why Headlamp: it's not a rewrite of Dashboard's feature list, it's a different architecture. Dashboard was a monolith — one binary, one fixed set of views, extended only by upstream PRs against the Dashboard repo itself. Headlamp, a CNCF Sandbox project maintained by Kinvolk (now part of Microsoft) under Kubernetes SIG UI, is built around a plugin system instead: a third party can ship a plugin that adds first-class views for a CRD-based system without touching Headlamp's core codebase at all, and the plugin ecosystem that's shown up in the months since backs that up. Kubeflow's plugin gives ML platform teams dedicated views for training jobs and pipelines. Knative's plugin turns serverless Revisions and Routes — normally invisible unless you already know the CRD names — into first-class list views. Volcano's plugin exposes queue state and gang-scheduling behavior for batch workloads. Karpenter's plugin surfaces node-provisioning decisions. Each shipped as an independent package, on its own release cadence, without Headlamp's core team having to build or maintain domain expertise in ML pipelines or batch scheduling themselves. And, most relevant to anyone running a fleet of Kubernetes clusters instead of one, Cluster API.

That last one is the actual reason this transition matters beyond "the old tool got archived, use the new one."

The Cluster API Plugin: What It Actually Gives an Operator​

Cluster API turns clusters, machines, and control planes into Kubernetes custom resources — which means without a purpose-built UI, inspecting fleet health means kubectl get across half a dozen CRD types and mentally reassembling the ownership chain (which Machines belong to which MachineDeployment, which MachineDeployment belongs to which Cluster) from ownerReferences by hand. The Headlamp Cluster API plugin, published April 10, 2026, replaces that with dedicated list and detail views for the CAPI resource types a fleet operator actually touches:

Concretely: say a MachineDeployment is stuck mid-rollout — new machines aren't joining, and the old ones haven't been drained yet. The kubectl version of debugging that is kubectl get machinedeployment, then kubectl get machineset -l <selector> to find the sets it owns, then kubectl get machine filtered again to find which specific node is failing, then kubectl describe that Machine and cross-reference its KubeadmConfig for a possible bootstrap failure — four or five separate commands, each requiring you to already know the CAPI ownership hierarchy by heart. The plugin's Cluster API dashboard shows the same chain as one relationship map — Cluster → control plane → MachineDeployment → MachineSet → Machine — with conditions and a remediation suggestion surfaced inline, and it supports both the v1beta1 and v1beta2 CAPI API versions plugin-side, so a fleet mid-upgrade between them doesn't lose the view. Scaling the stuck MachineDeployment, once you've found the bad node, happens from the same screen instead of a separate kubectl scale call.

That's the actual trade a Cluster-API-managed fleet is making by moving off Dashboard: not a like-for-like UI swap, but going from zero purpose-built visibility into CAPI's ownership graph to a dedicated one, for free, as a plugin.

Migrating Without Breaking a Shared Cluster​

The July 13 migration guide's core recommendation is to run both tools in parallel rather than cut over in one step, which matters most on a cluster other people already rely on. In practice:

1. Document current usage before touching anything — which clusters, which namespaces, which service accounts, and whether access today is via kubectl proxy, port-forward, or ingress.
2. Install Headlamp in-cluster alongside the still-running Dashboard:

   bash

   helm repo add headlamp https://headlamp-k8s.github.io/headlamp/
   helm repo update
   helm install my-headlamp headlamp/headlamp --namespace kube-system

3. Mint a service account token scoped the same way your Dashboard token was — the existing ClusterRole/RoleBinding can usually be reused as-is; only the token needs regenerating.
4. Add the Cluster API plugin (and any other relevant plugin) if the cluster in question is CAPI-managed.
5. Validate against your documented workflows from step 1 — namespace views, scaling, RBAC — with both tools live, before decommissioning Dashboard's deployment.
6. Update bookmarks and runbooks last, once Headlamp is the confirmed daily driver, since the old kubectl proxy URLs and Dashboard deep links won't resolve regardless of what's running.

The Bigger Point: An Operator View You Didn't Have to Build​

The reason this is worth covering for a self-hosted platform team specifically — not just "a CNCF tool got deprecated" — is what it replaces. A platform built on Cluster API (ours included: Bex.co runs Cluster API against owned Hetzner hardware, not a managed control plane) has always had two choices for giving a human operator visibility into fleet state: hand-roll a view from kubectl get output and CRD watches, or go without one and debug via raw kubectl every time. Headlamp plus its Cluster API plugin is a third option that didn't require either — a maintained, extensible, RBAC-respecting UI that already understands CAPI's ownership graph, arriving as upstream tooling instead of internal tooling debt.

It's worth being precise about what it doesn't replace, though. Headlamp is a human-facing visual layer — someone opens a browser and clicks around. It has nothing to say about an AI agent that needs to check fleet health, decide a MachineDeployment is stuck, and act on it without a human in the loop; that's a job for an API or MCP surface a platform exposes deliberately, not a dashboard UI at all. For the human side of operating a Cluster-API fleet, though, the migration is a straightforward net gain: less to build, less to maintain, and — for anyone whose fleet is CAPI-managed — more visibility than Dashboard ever offered in the first place.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, managed by Cluster API under the hood. Star the repo on GitHub or deploy your first app today.