Kubernetes Just Buried Its Own Dashboard: Why Headlamp Is Now the Default Operator UI for a CAPI-Managed Fleet

For nearly a decade, "the Kubernetes Dashboard" meant one thing: the general-purpose web UI that shipped alongside the project, the first thing a new operator port-forwarded to, the screenshot in every intro tutorial. On January 21, 2026, that era ended quietly — the kubernetes/dashboard repository was archived, its README updated to say the project "is now archived and no longer maintained due to lack of active maintainers and contributors." Then, on June 1, 2026, the Kubernetes project's own blog made it official policy rather than repo housekeeping: a post titled "From Kubernetes Dashboard to Headlamp: Understanding the Transition" walked operators through retiring the Dashboard in favor of Headlamp, the extensible UI now maintained under Kubernetes SIG UI. A step-by-step migration guide followed on July 13.

If you run a fleet of clusters through Cluster API — say, as the substrate of a self-hosted PaaS — here is the short version of what this means, up front: embedding Headlamp in your management cluster, with its new Cluster API plugin, is now the lower-maintenance default for your operator UI. Building a bespoke operator dashboard from scratch stopped making sense the moment the officially recommended UI became plugin-extensible and grew CAPI, Knative, and Volcano views in a single month. The one carve-out — and it matters — is your customer-facing dashboard, which Headlamp was never meant to replace. The rest of this post substantiates that verdict: what actually changed, which Headlamp plugin features map onto which operator surfaces a Render-style platform needs, and what the embed-versus-build trade really looks like.

What Actually Changed Between January and July 2026​

The transition happened fast once it started. The timeline:

The June 1 post is the "why and what": it maps Dashboard workflows (browsing workloads, editing manifests, scaling, deleting — all RBAC-enforced) onto their Headlamp equivalents and spells out what improves. The July 13 guide is the "how": a pre-migration checklist, a choice between parallel rollout and hard cutover, and the two deployment modes.

Three changes matter most for anyone who administered the old Dashboard:

• Authentication grows up. The Dashboard's infamous pasted-ServiceAccount-bearer-token login gives way to kubeconfig-based auth on the desktop and ServiceAccount or OIDC/SSO auth in-cluster. If your operators authenticate to kubectl through your identity provider today, Headlamp rides the same rails.
• Multi-cluster is the default, not a hack. The old Dashboard was one instance per cluster. Headlamp treats multiple clusters in one interface as the normal case — which is precisely the shape of a CAPI management cluster overseeing a fleet of workload clusters.
• Extensibility is the product. The Dashboard was a fixed feature set that slowly fell behind the ecosystem. Headlamp is a shell plus a plugin system, and the plugin catalog — KEDA, Karpenter, Gateway API, Prometheus, and now CAPI, Knative, Volcano, Kubeflow — is where the momentum lives.

That last point is the strategic one. The Kubernetes project didn't just swap one monolithic UI for another; it moved the official UI to an architecture where domain-specific views (like cluster lifecycle management) are plugins that ship on their own cadence.

The CAPI Plugin, Mapped Onto a Fleet Operator's Surfaces​

The Cluster API plugin for Headlamp — announced June 25, 2026, currently at 0.2.0-beta on Artifact Hub — is the piece that turns "Headlamp is the recommended UI" into "Headlamp is your operator UI" for a CAPI-managed fleet. It was built through the CNCF LFX mentorship program under the Headlamp project, and its first release already covers an unusual amount of ground.

If you operate a self-hosted PaaS on Cluster API, you already know the surfaces your on-call operators need, whether you've built them or (more likely) left them as kubectl incantations in a runbook. Here is how the plugin's shipped features map onto those surfaces:

Read that left column again: it is, more or less, the spec of the "hand-rolled status page" that most self-hosted platforms either half-built or deferred. The plugin's first release covers all of it — not perfectly, not GA, but covered, maintained upstream, and improving on someone else's engineering budget.

The Knative plugin announced the same day matters for a narrower but real slice of platforms: anyone exposing scale-to-zero or request-driven services. It bridges the gap between the kn CLI, kubectl, and the UI — KService and Revision detail pages, per-revision request-rate breakdowns for validating an in-progress traffic split, and a genuinely clever touch: it reads config-autoscaler and config-defaults and shows the effective autoscaling configuration per service, flagging whether a value is explicitly set or inherited from the cluster default. If your platform does progressive delivery on Knative, that traffic-split view is an operator surface you'd otherwise have to build.

The honest caveat: 0.2.0-beta is a first release from June 2026. Expect rough edges, expect breaking changes before GA, and expect to file issues. That argues for adopting it as your operator UI with kubectl kept warm as the escape hatch — not for wiring it into customer-facing anything.

Embed Headlamp or Build Your Own? The Actual Trade​

"Should we build a dashboard?" is a perennial platform-team debate, and the June announcements shift its terms. Lay the trade out honestly:

What embedding Headlamp gives you for free:

• RBAC enforcement you don't have to reimplement. Headlamp calls the Kubernetes API as the authenticated user or ServiceAccount; what an operator can see and click is exactly what their role allows. A bespoke dashboard has to rebuild this — and dashboard authorization bugs are security incidents.
• OIDC/SSO integration out of the box, aligned with how your team already authenticates.
• Multi-cluster navigation native to the tool — the CAPI management-cluster topology is its home turf.
• A maintained upstream. SIG UI, an active plugin ecosystem, LFX mentees shipping features. The Dashboard's fate is the cautionary tale here: UIs rot fast when they're nobody's job, and the archived repo proves even flagship UIs aren't immune.
• The plugin system as your extension point. If your platform has bespoke CRDs (an App resource, say), a Headlamp plugin that renders them is a far smaller artifact to own than an entire React application with auth, cluster proxying, and a component library.

What building bespoke still buys you:

• Product-branded, product-shaped UX. Headlamp shows Kubernetes resources; your end users think in apps, deploys, and domains. No plugin makes Headlamp a good customer experience.
• Abstraction control. A bespoke dashboard can hide Kubernetes entirely — which is the whole promise of a PaaS to its users.
• Roadmap independence. You're not waiting on an upstream beta to fix the view your on-call rotation depends on.

The resolution is that these are two different products, and the mistake is conflating them. A self-hosted PaaS has two UIs: the surface its users see (apps, builds, logs, domains — necessarily bespoke, because its entire job is hiding Kubernetes) and the surface its operators see (clusters, machines, control planes — where hiding Kubernetes is actively harmful). The June 2026 shift settles the second one. Before, "point operators at raw kubectl plus a runbook" was a defensible default because every alternative meant building or adopting something unmaintained. Now the officially recommended, actively maintained UI covers the CAPI operator surface out of the box, and the residual cost of adopting it is a Helm release on the management cluster plus a plugin install.

The strongest counter-argument is the plugin's youth — a beta weeks old is thin ice for the tool your 3 a.m. incident response leans on. That's real, and the mitigation is equally real: run it in parallel with your existing runbooks (the July 13 guide explicitly recommends parallel rollout over cutover), treat it as read-heavy triage tooling first, and keep write operations in kubectl/GitOps until the plugin matures. What the argument doesn't support is spending platform-team quarters building a bespoke operator console that duplicates what upstream now maintains.

Migrating a CAPI Management Cluster in Practice​

Distilling the July 13 guide and applying it to a management-cluster deployment, the path looks like this:

1. Inventory what your operators actually do today. The guide's pre-migration checklist applies directly: list the clusters in the fleet, the namespaces operators touch, the recurring tasks (triage, scaling, upgrade watching), and the RBAC bindings behind them. For a CAPI fleet, add: which CAPI resources your runbooks kubectl get most.
2. Choose parallel rollout. Install Headlamp alongside whatever exists — old Dashboard, status page, or nothing. Nobody's incident workflow should change on day one.
3. Install in-cluster on the management cluster via Helm. In-cluster mode is the right call for shared team access — it mirrors the old Dashboard's deployment shape (ServiceAccount auth, ingress or port-forward access) so the operational muscle memory transfers. Individual operators can additionally run the desktop app against their kubeconfig for multi-cluster work.
4. Wire authentication to your identity provider. OIDC in-cluster, so dashboard access follows the same joiner/leaver flows as everything else. Scope operator roles with normal RBAC — Headlamp will enforce them.
5. Install the CAPI plugin (plus Prometheus and, if relevant, Knative plugins) and validate the mapping table above against your fleet: does the dashboard surface the conditions your runbooks check? File upstream issues where it doesn't.
6. Keep kubectl as the escape hatch and only retire the old surfaces — including the archived Dashboard, which should not outlive its security-patch vacuum for long — once the team trusts the new one.

The archived Dashboard deserves emphasis: an unmaintained web UI with cluster credentials is not a neutral leftover, it's attack surface with no patch pipeline. "Parallel rollout" should be measured in weeks, not quarters.

The Consolidation Signal​

Step back and the June 2026 announcements read as more than a UI swap. The Kubernetes project let its own first-party Dashboard die of maintainer attrition, then consolidated UI effort into an extensible shell where the ecosystem — CAPI, Knative, Volcano, Kubeflow, Karpenter — ships views as plugins. That's the same pattern the ecosystem already followed for package management (Helm), GitOps (Argo/Flux), and cluster lifecycle (CAPI itself): the core project defines the substrate, a focused project owns the layer, and bespoke in-house builds of that layer become technical debt.

For platform teams, the actionable takeaways: if you maintain a hand-rolled cluster status page, put "replace with embedded Headlamp + CAPI plugin" on the backlog and watch the plugin's path to GA. If you point operators at raw kubectl, you can now hand them a real UI in an afternoon. And if you're designing a new platform, draw the line between operator UI and user UI explicitly — build only the second, embed the first.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, on clusters managed through Cluster API. Its operator surface is exactly the territory this post maps: machine-readable platform state that works with the tools above, not against them. Star the repo on GitHub or deploy your first app today.