Headlamp Ships a Cluster API Plugin: Declarative Cluster Lifecycle Finally Gets the UI Kubernetes Dashboard Never Had

For most of Cluster API's life, operating a fleet meant living in a terminal. Provisioning status, rollout progress, machine health — all of it sat behind kubectl get machines and long walks through owner references in raw YAML. On June 25, 2026, that changed: the Headlamp project shipped a dedicated Cluster API plugin that puts clusters, control planes, machines, and their ownership hierarchy into a maintained graphical UI, with in-browser scaling, bootstrap-config inspection, and Prometheus metrics inline on resource pages.

This matters now for a structural reason, not just a convenience one. The Kubernetes Dashboard — the default web UI for a decade — was officially archived on January 21, 2026 and moved to kubernetes-retired/dashboard, where it will receive no further security patches or features. SIG UI now points users at Headlamp, which moved under kubernetes-sigs as the endorsed successor. So the Cluster API plugin isn't merely a nice add-on: it is the first maintained, community-governed visual layer for declarative cluster lifecycle management, arriving exactly as the old default goes dark.

What the Dashboard never had​

It is worth being precise about the gap this fills, because "a UI for CAPI" undersells it. The retired Dashboard was built around core workloads — Deployments, Pods, Services — and never understood Cluster API's resource model. It had no notion of a Cluster owning a control plane and a set of MachineDeployments, no view of MachineSet rollout state, no rendering of CAPI conditions, and no awareness of ClusterClass topology. Operators filled that gap with terminal workflows: kubectl get cluster,machinedeployment,machineset,machine -A, clusterctl describe cluster, and hand-read YAML to trace why a machine never joined.

The Headlamp plugin is the inverse approach. Instead of bolting CAPI onto a workload dashboard, it adds a dedicated Cluster API section to Headlamp's sidebar with list and detail views designed around CAPI's ownership hierarchy. That includes a map view that draws Cluster, control plane, and worker relationships as a graph — the single fastest way to answer "what owns what" during an incident — and topology awareness that labels ClusterClass-managed resources and steers scaling actions to the Cluster level where they belong.

One honest caveat up front: this is an alpha release, built during a CNCF LFX Mentorship under the Headlamp project, with more features planned. What follows is what the first release actually ships — and where it still stops short.

What the plugin actually ships​

The official announcement on the Kubernetes blog lays out eleven capabilities. Here is the inventory that matters for day-to-day fleet operations:

Three of these deserve emphasis because they map directly onto the most repetitive CAPI operator workflows.

First, the dashboard's remediation guidance. When the overview detects an issue, the cluster health view pairs the failing conditions with diagnostic commands and remediation hints. That turns the most common CAPI debugging loop — notice a stuck rollout, hunt through conditions across four resource types, guess the fix — into a single page that names the problem and suggests the next command. It does not replace understanding CAPI's condition model, but it compresses the distance between symptom and cause.

Second, structured KubeadmConfig inspection. Bootstrap configuration is one of the least readable corners of a CAPI install: files, kubelet arguments, and join settings buried in configs and secrets. Rendering them as structured detail pages removes a whole class of "decode the secret, scroll the YAML" chores from node-troubleshooting sessions.

Third, metrics where the resources are. The Prometheus integration embeds live metrics directly on CAPI detail pages (once the Headlamp Prometheus plugin is installed and configured), so infrastructure state and performance signals sit side by side. Correlating a Machine's condition timeline with node pressure during an incident, without switching dashboards, is a small thing that compounds across every future outage.

Try it in an afternoon​

The install path is deliberately short. The plugin lives in the official headlamp-k8s/plugins repository and installs through Headlamp's built-in Plugin Catalog from the UI — no manual manifest surgery. The requirements are:

• Headlamp >= 0.13.1 (the plugin builds against @kinvolk/headlamp-plugin ^0.13.1)
• A management cluster with Cluster API installed (v1beta1 or v1beta2 both work)

Detailed steps are in the plugin's README. The realistic afternoon plan: point Headlamp at a non-production management cluster, install the plugin from the catalog, and walk the dashboard against a cluster you already know — compare what the map view and health cards tell you with your usual kubectl sequence. Alpha means you should expect rough edges; bug reports go to the headlamp issue tracker, and the announcement explicitly says community feedback shapes what comes next.

It is also worth noting the company this plugin keeps. The same week brought a Volcano plugin for batch-scheduler Jobs, Queues, and PodGroups, and the catalog already covers Knative, Kueue, and Prometheus. The pattern is converging: one browser tab for the management cluster instead of a separate CLI per subsystem.

Where coverage still stops​

An honest accounting, because alpha plus enthusiasm is how teams over-commit:

• Operator-facing, not tenant-facing. The plugin visualizes CAPI resources for the people who run the fleet. It offers nothing a tenant would recognize as a platform: no app-level views, no deploy flows, no logs-per-service, no usage or billing surface. If you run a PaaS on CAPI, this improves your operators' lives; your tenants still need your own dashboard.
• Day-2 visibility, not full lifecycle. The first release centers on viewing, inspecting, and scaling what already exists. Fleet-wide provisioning workflows, upgrade orchestration, and provider management remain clusterctl-and-GitOps territory.
• Alpha maturity. The announcement is explicit that work is ongoing and feedback-driven. Pin versions, test against your CAPI version, and keep the kubectl runbooks until the plugin has earned their retirement.
• Kubeadm-centric depth. The richest views (control-plane monitoring, KubeadmConfig inspection) assume the kubeadm bootstrap/control-plane providers. Fleets on other providers get the generic resource views but less of the deep structured detail.

None of this diminishes the release; it scopes it. A maintained visual layer for CAPI's core resources, with a feedback channel that actually steers the roadmap, is precisely the foundation the ecosystem lacked.

Why this matters for a self-hosted PaaS on CAPI​

For a platform built on Cluster API — a management cluster reconciling workload clusters on owned machines — fleet state has always been visible to controllers but opaque to humans. Every team in that position eventually hand-rolls some version of a status page: scripts that scrape Machine conditions, dashboards that approximate rollout progress, wiki runbooks explaining which kubectl incantation answers which question. That bespoke tooling rots; the plugin replaces the most duplicative slice of it with a maintained, CNCF-governed view driven by the same resources the controllers already reconcile.

The deeper win is consolidation. A small ops team running CAPI plus batch or serverless workload types has historically juggled kubectl, clusterctl, vcctl, and per-subsystem dashboards. Headlamp's plugin model — CAPI, Volcano, Knative, Kueue, Prometheus in one console — collapses that into a single authenticated browser session against the management cluster. For a team with no spare headcount for dashboard maintenance, "install from the catalog" versus "build and maintain our own" is not a close call.

The boundary to respect is the one drawn above: adopt this for fleet operations, and keep investing in the tenant-facing surface separately. The plugin answers "is the fleet healthy and what owns what"; it will never answer "did my deploy succeed and how is my app doing." Platforms that confuse the two end up exposing machine internals to tenants or, just as bad, hiding fleet state from the operators who need it.

The Dashboard era is over; CAPI finally has a window​

January's archival of the Kubernetes Dashboard closed a chapter: the era when one generic web UI covered every cluster. What replaces it is narrower and better — extensible consoles with deep, subsystem-aware plugins maintained alongside the projects they visualize. The Cluster API plugin is the clearest proof of that model yet: declarative infrastructure finally gets a declarative-aware UI, built in the open, shaped by operator feedback, one catalog install away.

Point Headlamp at a test management cluster this week. Your next stuck MachineDeployment rollout is going to be debugged from a health card instead of a YAML scroll — and your kubectl history will be shorter for it.

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.