Headlamp's Cluster API Plugin: The Free Ops Console Your PaaS Team Doesn't Have to Build

In January 2026, the Kubernetes Dashboard — the web UI a generation of operators opened every morning — was moved to kubernetes-retired and stopped receiving maintenance. Its officially recommended successor is Headlamp, the extensible, multi-cluster Kubernetes UI that joined Kubernetes SIG UI in 2025. And on June 25, 2026, the Kubernetes blog introduced a Cluster API plugin for Headlamp that turns raw kubectl get machines output into a visual fleet-operations surface: cluster health dashboards, MachineDeployment scale actions, ownership map views, and inline Prometheus metrics. The verdict worth stating up front:

The rest of this post earns that table.

What the plugin actually ships​

Managing Cluster API resources has historically meant raw kubectl plus deep familiarity with ownership hierarchies — which object owns which, and which condition on which child explains a stuck rollout. The plugin adds a dedicated Cluster API section to Headlamp with consistent list and detail views. Concretely, the first release includes:

• Fleet health dashboard — one page summarizing every Cluster, Machine, MachineDeployment, MachinePool, MachineSet, and control plane on the management cluster, with active condition issues, provider info, and template counts surfaced instead of buried in kubectl describe.
• Cluster detail with remediation guidance — selecting a cluster shows control-plane and worker status, machine info, infrastructure references, and resource conditions; when something is degraded, the dashboard suggests remediation steps and diagnostic commands.
• Machine-level views — dedicated pages for MachineDeployments, MachineSets, Machines, and MachinePools with replica counts, ownership relationships, provider IDs, versions, and conditions.
• Scale from the UI — a built-in Scale action on MachineDeployments and MachineSets, with a guard for topology-managed (ClusterClass) clusters telling you to scale at the Cluster level instead.
• Ownership map view — a visual graph of Cluster → control plane → worker relationships, which is the fastest way to answer "what owns this failing Machine?"
• Structured KubeadmConfig inspection — bootstrap configs, inline files, kubelet args, and join/init settings rendered as structured data instead of raw YAML dug out of Secrets.
• Inline Prometheus metrics — when the Headlamp Prometheus plugin is installed, live metrics render inside the Cluster API detail pages, so infrastructure state and performance data sit side by side during debugging.
• v1beta1 and v1beta2 support — dynamic API versioning, so it works against both CAPI generations during the upgrade window.

Two things about that list matter for the build-vs-buy math. First, every item is something a platform team otherwise reimplements: condition aggregation, ownership tracing, and remediation runbooks are exactly what a hand-rolled "fleet status page" spends its first three months getting wrong. Second, it all arrives inside the console operators already use for pods, logs, and exec — one browser tab instead of a bespoke admin app plus three CLIs.

Picture the Tuesday morning it pays for. A worker Machine on your Hetzner fleet sticks in provisioning after a node image bump. Before: you kubectl get machines, spot the unready one, kubectl describe it, chase the owner reference up through MachineSet to MachineDeployment, then go read the bootstrap provider logs to find the cloud-init failure — fifteen minutes if you know the hierarchy by heart, longer if the on-call engineer doesn't. After: the fleet dashboard already flags the active condition issue, the map view shows exactly where the red node hangs in the ownership chain, the detail page pairs the condition with remediation guidance and the diagnostic command, and the structured KubeadmConfig view shows the failing join setting without spelunking Secrets. That is not a prettier kubectl — it's the difference between needing CAPI's object model in your head and reading it off a screen. Multiply the saved fifteen minutes by every stuck rollout across a year, then compare it against the cost of building and maintaining that screen yourself: there is no contest.

The buy-vs-build math for a small platform team​

A bespoke internal fleet console costs more than it looks. Industry analyses of internal platforms routinely put ongoing maintenance at 25–50% of the original build cost per year — a tool that cost a few engineer-months to build keeps taxing the team that owns it, forever. For a small team running a Cluster-API-managed fleet (say, a Hetzner-based setup with CAPH), the realistic comparison is:

What you'd have to build yourself. At minimum: list/detail views over six-plus CAPI resource types, ownership-hierarchy resolution (Cluster → KubeadmControlPlane → MachineDeployment → MachineSet → Machine), condition aggregation with human-readable health rollups, a safe scaling action that respects ClusterClass topology, and bootstrap-config rendering. Each of those is a weekend project; together, maintained across CAPI API-version upgrades, they're a permanent background tax on the one or two engineers who also run everything else.

What the plugin gives you for free. All of the above, maintained upstream — and notably, built through the CNCF LFX Mentorship program with direct input from platform teams about real usability pain, not as a side project. Improvements land without your team lifting a finger, and the plugin model means they compose: the same Headlamp instance already gained Volcano, Knative, and Kubeflow plugins in the same June–July 2026 window, so batch, serverless, and ML workload views arrive the same way.

What to verify before depending on it. Honesty requires the caveats. This is an alpha release (the registry tags it cluster-api-0.1.0-alpha), it requires Headlamp 0.13.1+ and Kubernetes 1.26+, and alpha means the feature set is still shaped by community feedback — bug reports go to kubernetes-sigs/headlamp, and the roadmap explicitly includes improvements beyond the first release. Treat it the way you'd treat any alpha dependency: run it as the operator console, keep kubectl and GitOps as the source of truth, and don't wire automation to anything the plugin shows until the API it reads is one you'd already trust.

Net: for internal fleet debugging, the plugin deletes a bespoke-tool project from your roadmap. That is the whole point — a git-push PaaS team should spend its engineering on the tenant experience, not on re-drawing the Machine hierarchy in React.

The boundary it can't cross: your tenants don't think in Machines​

Here is where the TODO-list framing earns its second half. Everything the plugin shows is a raw CAPI object. Your tenants think in apps, deploys, domains, and logs — the Render-compatible API surface a PaaS actually sells. No upstream plugin will ever close that gap, because it's your product, not shared infrastructure:

• Different object model. A tenant's "my deploy is stuck" maps internally to some combination of build pods, image pushes, and rollout status across your own custom resources — none of which are Cluster, MachineDeployment, or KubeadmConfig. The plugin visualizes the fleet layer; the tenant layer needs its own views over your own API.
• Different access model. An operator console assumes cluster-wide read access. A tenant dashboard needs strict per-tenant scoping — tenant A must never see tenant B's workloads, let alone the fleet's Machines. RBAC that slices CAPI objects per tenant is not something a generic plugin ships.
• Different vocabulary. Exposing MachineSets and provider IDs to tenants would be a leak, not a feature. The tenant dashboard translates platform state into "build failed at step X, here's the log" — a presentation layer only you can write, because only you define the API it speaks.

So the honest architecture is two consoles: Headlamp + CAPI plugin for the operators (free, upstream, speaks Kubernetes), and your own dashboard for the tenants (bespoke, speaks your API). Confusing the two in either direction costs money — building your own fleet-ops UI wastes engineering, and pointing tenants at raw CAPI objects leaks your internals.

Try it this week​

If you already run Headlamp against your management cluster, the install is a plugin build from the headlamp-k8s/plugins repository's cluster-api directory — clone, npm install, npm run build, point Headlamp at it per the README. If you haven't migrated off the old Dashboard yet, the Kubernetes blog published a transition explainer on June 1 and a step-by-step migration guide on July 13 — both worth reading before you move, since Headlamp's multi-cluster model and plugin system change a few assumptions the old Dashboard baked in. Then open the fleet dashboard and check one thing: the next time a Machine sticks in provisioning, time how long it takes to find the failing condition with the map view versus kubectl. If the answer isn't "much faster," file that as feedback — it's an alpha, and the maintainers are explicitly asking for it on the #headlamp Kubernetes Slack channel.

The larger signal is worth naming. The old Kubernetes Dashboard died because the operating model outgrew a single-cluster pod viewer. What's replacing it isn't one bigger dashboard — it's a workbench: a common shell with domain-specific plugins for CAPI fleets, Volcano queues, Knative services, and Kubeflow pipelines. For a small platform team, that shift is pure leverage: every plugin you adopt is a bespoke internal tool you never have to build, staff, or maintain. Spend that savings on the one console nobody can build for you — the one your tenants see.

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.