For many people, Kubernetes Dashboard was their first window into Kubernetes. It offered a simple visual way to see what was running in a cluster, inspect resources, and build confidence without relying on the command line. For years, it helped developers, students, and operators make sense of Kubernetes, and it served as an important onramp into the ecosystem.
The Kubernetes Dashboard project has now been archived. We deeply respect the work the team did and the role Dashboard played in making Kubernetes more approachable for so many users.
Headlamp builds on that foundation and carries it forward. It keeps the clarity of a visual interface while adding capabilities that match how Kubernetes is used today. This includes multi-cluster visibility, application-centric views, extensibility through plugins, and flexible deployment options that work both in-cluster and on the desktop.
This guide is meant to help you navigate that transition with confidence. Before diving into the mechanics of migration, we start with familiar ground by looking at how common Kubernetes Dashboard workflows map to Headlamp. We also cover what stays the same and what improves after the switch. The goal is not just to replace a tool, but to honor a user-centered legacy and help you land in a UI that can grow with you as your Kubernetes usage evolves.
Mapping Kubernetes Dashboard workloads to Headlamp
If you have used Kubernetes Dashboard before, many workflows in Headlamp will feel familiar. Headlamp does not introduce a new way of thinking. Instead, it builds on workloads users already know and extends them in practical ways. The focus is continuity. What worked before still works, with more room to grow.
Viewing workloads and resources
In Kubernetes Dashboard, most users started by browsing workloads like pods, deployments, services, and namespaces. Headlamp keeps this same starting point. Workloads are easy to find and inspect, and moving between namespaces and clusters is simpler. Resources are still organized in familiar ways, and navigation feels smoother, especially when you work across multiple environments.
Editing and interacting with resources
Like Kubernetes Dashboard, Headlamp lets you view and edit manifests directly in the UI based on your permissions. You can delete resources, scale workloads, or update configurations from the interface. All actions follow standard Kubernetes RBAC. If you could perform an action in Dashboard, you will find the same capability in Headlamp, with the same respect for access controls.
Understanding relationships
Where Headlamp begins to expand the experience is in how it presents relationships between resources. In addition to list views, Headlamp offers visual ways to see how workloads, services, and configurations connect. This helps provide context without changing the underlying workloads users already rely on.
At a high level, the tasks you performed in Kubernetes Dashboard are still there. Headlamp keeps familiar workflows while making it easier to scale as clusters, teams, and applications grow.
Where Headlamp goes beyond Kubernetes Dashboard
Expanding from single cluster to multi-cluster workflows
Kubernetes Dashboard was designed to work with one cluster at a time. That model worked well for simple setups, but it became limiting as teams adopted multiple environments. Headlamp expands this view by letting you work with multiple clusters from a single interface without switching tools or losing context. This makes it easier to manage development, staging, and production environments side by side.
For teams running Kubernetes in more than one place, this shift reduces friction. You can stay oriented and move between clusters with confidence.
From resource lists to application context with Projects
Projects give you an application-centered way to view Kubernetes. Instead of jumping between lists, you can group related workloads, services, and supporting resources in one place. This makes applications easier to understand. You can see what belongs together, track changes in context, and troubleshoot without scanning the cluster piece by piece.
Projects are built on native Kubernetes concepts. Namespaces, labels, and RBAC continue to work the same way they always have. Headlamp adds a visual layer that brings related resources together.
Projects are optional. You can still work at the individual resource level when that fits your task. When you need more context, Projects help you step back and see the bigger picture.
Extend the Headlamp UI with plugins
Headlamp can be extended through plugins that bring common workflows directly into the UI. Instead of switching tools, you work in one place with the same context.
For example, the Flux plugin brings GitOps workflows into Headlamp. It allows teams to view application state alongside the Kubernetes resources that Flux manages, making it easier to understand how changes in Git relate to what is running in the cluster.
The AI Assistant follows a similar pattern. It adds a conversational layer to the UI that helps users understand what they are seeing, troubleshoot issues, or take action. All of this happens in the same screen where the problem appears.
Building your own plugins
Plugins are optional and not limited to community-built extensions. Platform and project teams can also create their own plugins. This allows organizations to add custom integrations that match their specific workflows and internal tooling, while keeping the user experience consistent.
Choosing how and where Headlamp runs
Headlamp gives teams flexibility in how they use a Kubernetes UI. You can run it directly in a cluster, use it as a desktop application, or combine both approaches based on your needs.
Running Headlamp in-cluster works well for shared environments. It provides a centrally managed UI with controlled access and fits naturally into Kubernetes setups, following the same authentication and RBAC rules as other in-cluster components.
The desktop application is often a better fit for local development and onboarding. It also works well when you need to manage multiple clusters from one place. Users can connect using their existing kubeconfig without deploying anything into the cluster.
These options are not mutually exclusive. Many teams use the desktop app for day-to-day work, while relying on an in-cluster deployment for shared or production environments.
Preparing for the Migration
Before moving from Kubernetes Dashboard to Headlamp, it can be helpful to pause and take stock of how you use the Dashboard today. A little reflection up front can go a long way toward making the transition feel smooth and familiar.
Start by noting which clusters and namespaces you access and how authentication works. Headlamp relies on standard Kubernetes authentication and RBAC. In most cases, existing access models carry over without change. If users already connect using kubeconfig files or service accounts, they will be able to access the same resources in Headlamp.
It is also useful to think about the workflows that matter most to your team. Some users rely on Dashboard for quick inspection or troubleshooting, while others use it for lightweight edits or validation. Headlamp supports these same workflows and adds optional capabilities on top. Knowing what you rely on today helps the transition feel predictable and confidence building.
If you would like to explore Headlamp or try it out before migrating, you can learn more at headlamp.dev.
This blog focused on understanding the transition and what to expect. A step by step migration guide is coming soon and will walk through installation and migration in detail.
Facts Only
Kubernetes Dashboard, a visual interface for managing Kubernetes clusters, has been archived.
Headlamp is presented as the successor to Kubernetes Dashboard.
Headlamp retains familiar workflows for viewing and editing Kubernetes resources like pods, deployments, and services.
Headlamp introduces multi-cluster visibility, allowing users to manage multiple clusters from a single interface.
The "Projects" feature in Headlamp groups related workloads and resources for application-centric views.
Headlamp supports extensibility through plugins, including integrations like Flux for GitOps and an AI Assistant.
Plugins can be custom-built by organizations to fit specific workflows.
Headlamp can be deployed in-cluster or as a desktop application, with both options supporting standard Kubernetes authentication and RBAC.
The desktop application allows users to connect via kubeconfig without in-cluster deployment.
Kubernetes Dashboard was limited to single-cluster workflows, which became a constraint as teams adopted multi-cluster environments.
Headlamp’s interface includes visual representations of resource relationships, providing additional context beyond list views.
Existing Kubernetes Dashboard users can migrate to Headlamp with minimal disruption to their workflows.
Executive Summary
Kubernetes Dashboard, a widely used visual interface for managing Kubernetes clusters, has been archived, marking the end of its active development. Headlamp emerges as its successor, offering a familiar user experience while introducing advanced features like multi-cluster visibility, application-centric views through "Projects," and extensibility via plugins. The transition aims to maintain continuity for users accustomed to Dashboard’s workflows—such as viewing and editing resources—while addressing modern needs like managing multiple clusters and integrating with tools like Flux for GitOps. Headlamp provides deployment flexibility, supporting both in-cluster and desktop applications, and retains Kubernetes’ native RBAC and authentication mechanisms. The shift reflects the evolving complexity of Kubernetes environments, where single-cluster tools like Dashboard have become limiting. For teams, this means a smoother onboarding process, better context for troubleshooting, and the ability to customize the interface with plugins tailored to specific workflows. The migration is positioned as a natural progression rather than a disruptive change, with resources available to guide users through the transition.
The archiving of Kubernetes Dashboard underscores the rapid pace of change in cloud-native tooling, where user interfaces must adapt to growing operational demands. Headlamp’s design prioritizes both familiarity and scalability, acknowledging that while Dashboard served as an essential onramp for many, its limitations in multi-cluster and application-centric scenarios necessitated a more robust solution. The emphasis on plugins and flexible deployment options suggests a recognition of diverse user needs, from individual developers to enterprise teams. However, the success of this transition will depend on how seamlessly existing workflows integrate with Headlamp’s new capabilities and whether the community adopts it as the de facto replacement.
Full Take
The transition from Kubernetes Dashboard to Headlamp reflects a broader pattern in cloud-native tooling: the tension between simplicity and scalability. Kubernetes Dashboard served as an onramp for newcomers, but its single-cluster design became a liability as adoption grew. Headlamp’s multi-cluster support and application-centric "Projects" feature address this gap, but the shift also raises questions about tooling fragmentation and the burden of migration. The emphasis on plugins and extensibility suggests a recognition that no single interface can meet all needs, yet it also risks creating complexity if plugins proliferate without standardization.
The narrative frames Headlamp as a natural evolution, but it’s worth asking: who benefits most from this transition? Developers and operators managing complex environments will likely gain from multi-cluster visibility, but smaller teams or individuals might find the added features unnecessary. The claim that Headlamp "honors a user-centered legacy" is compelling, but the real test will be whether it avoids the pitfalls of feature bloat while maintaining the simplicity that made Dashboard valuable. The mention of AI Assistant plugins, for example, could either streamline troubleshooting or introduce opacity—depending on how transparently these tools operate.
Root cause: The archiving of Kubernetes Dashboard highlights the lifecycle of open-source tools, where early simplicity often gives way to complexity as ecosystems mature. The assumption here is that users will naturally progress from basic to advanced needs, but this isn’t always true. What if some users prefer Dashboard’s simplicity? The narrative doesn’t fully acknowledge that trade-off.
Implications: For human agency, Headlamp’s flexibility is a double-edged sword. Custom plugins empower teams to tailor the UI, but they also shift the burden of integration onto users. The desktop vs. in-cluster deployment choice is practical, but it may create silos if teams adopt inconsistent setups. Second-order consequences could include increased cognitive load for users navigating plugins or a fragmentation of the Kubernetes UI landscape if alternatives emerge.
Bridge questions: How will Headlamp ensure backward compatibility for users who don’t need advanced features? What safeguards exist to prevent plugin sprawl from degrading performance or security? And critically, how will the community measure whether this transition truly serves users—or simply reflects the priorities of platform teams?
Counterstrike scan: If this were part of a coordinated influence campaign, the playbook would emphasize inevitability ("natural evolution") while downplaying trade-offs (e.g., complexity for simplicity). The actual content avoids this by acknowledging continuity and offering migration guidance, but the framing still leans toward progress as linear. No structural alignment with manipulation patterns detected.
Patterns detected: none
Sentinel — Human
The article functions effectively as a user-focused guide, exhibiting the natural flow and rhetorical intent of human technical content, though it leverages structured, predictable organization.