Kubernetes Dashboard is retired. Here's what to run instead.
Archived January 2026, no more security patches. Your real options - including the ones that aren't ours.
- January 21, 2026: the kubernetes/dashboard repository was archived and moved to kubernetes-retired/dashboard, citing a lack of active maintainers.
- No more updates of any kind - security patches included. Existing deployments continue to run, unmaintained.
- Headlamp now sits under kubernetes-sigs, and SIG UI pointed Dashboard users toward it - worth knowing before you read the rest of this page from a competing vendor.
What should you run instead of Kubernetes Dashboard?
Which one is right depends on who used Dashboard at your org and what for.
Radar
Full disclosure: this is our toolApache 2.0 · no-relicense pledge · OSS + optional CloudThe strongest general replacement: resource browsing like Dashboard had, plus Issues, topology, retained event and resource-change evidence, logs, exec, Helm, GitOps, traffic, audit, and MCP in one model. Run Radar Desktop or locally with zero cluster-side install, deploy it in-cluster for a shared URL, or add Cloud for fleet workflows.
What's in Radar OSSHeadlamp
The governance pickApache 2.0 · Kubernetes SIG UIA kubernetes-sigs project under SIG UI. Its real edge is vendor-neutral governance and an open-ended plugin SDK - the operational depth is not in the box, you choose, install, version, and maintain it. Choose it when governance or custom UI plugins are a hard requirement. Radar is the stronger operational product out of the box because supported capabilities share one Issues, topology, timeline, resource, GitOps, and MCP model.
k9s
The terminal routeApache 2.0 · freeIf Dashboard was only used by terminal-native operators, k9s covers resource browsing, logs, and exec through a fast keyboard-first TUI. It does not replace the shareable webpage role Dashboard played, and it does not provide Radar's visual relationships, retained evidence, integrated controllers, or MCP endpoint.
Freelens / Lens
The desktop IDE routeMIT fork · free / commercialA different model entirely: per-laptop desktop apps reading each engineer's kubeconfig rather than one shared in-cluster UI. Strong for individual power users; doesn't replace the 'one URL the whole team opens' role Dashboard played.
How do the replacements compare to Dashboard?
Dashboard keeps its own column. It browsed resources and gave a team one URL, and it still does - the case against it is the first row.
| Feature | Dashboard archived | Radar | Headlamp | k9s | Freelens |
|---|---|---|---|---|---|
Receiving security patches The reason this page exists. Dashboard is a privileged web UI in front of the Kubernetes API, and it has had no maintainer since the repository was archived on January 21, 2026. | No | Yes | Yes | Yes | Yes |
One shared URL the whole team opens The role Dashboard actually played. Desktop-only tools do not replace it. | Strong: Yes - its whole point | Strong: Helm chart or Cloud | Strong: In-cluster web app | No | No |
Resource browsing, logs, exec | Yes | Yes | Yes | Yes | Yes |
Topology graph | No | Strong: Live workload graph | Partial: Resource map | No | Partial: Official extension |
Retained event and resource-change history Cluster events and resource changes the product itself retains for look-back - not live API state, not your monitoring stack's storage, and not a log of user actions in the product. | No | Strong: Memory · SQLite · Cloud up to 1 year | No | No | No |
GitOps correlation (Argo CD + Flux) Generic CRD access is useful; typed sync status, drift, ownership, activity, and actions wired into the rest of the product is a deeper integration. | No | Strong: Argo CD + Flux, in core | Partial: Separate plugins | No | Partial: Official + community extensions |
Cluster security audit (Trivy / Kyverno) Configuration, reliability, and security findings surfaced on the affected resources - and whether that ships with the product or arrives as a separately installed, separately licensed scanner. | No | Yes | Partial: Kyverno plugin + third-party Trivy | Partial: Built-in Popeye view | Partial: Generic resources + extensions |
MCP for external AI agents What an external agent actually gets from the endpoint: a wrapper over the raw Kubernetes API, or operational context already correlated for agent use. Benchmarked against raw kubectl on 54 live-cluster faults, Radar's MCP server was more accurate and reached a correct diagnosis about four times sooner. | No | Strong: Correlated read + write tools · 4x sooner to a correct diagnosis than kubectl | Partial: In-app client only | No | Partial: In-app client only |
Organization SSO Dashboard authenticated with a bearer token or kubeconfig upload, which is the workflow most teams wanted to stop doing. | Partial: Token or kubeconfig upload | Strong: In-cluster OIDC · Cloud SAML/OIDC | Partial: OIDC only · self-configured | No | No |
License | Apache 2.0 · archived | Apache 2.0 · no-relicense pledge | Apache 2.0 | Apache 2.0 | MIT |
Receiving security patches
The reason this page exists. Dashboard is a privileged web UI in front of the Kubernetes API, and it has had no maintainer since the repository was archived on January 21, 2026.
- Dashboard
- No
- Radar
- Yes
- Headlamp
- Yes
- k9s
- Yes
- Freelens
- Yes
One shared URL the whole team opens
The role Dashboard actually played. Desktop-only tools do not replace it.
- Dashboard
- Strong: Yes - its whole point
- Radar
- Strong: Helm chart or Cloud
- Headlamp
- Strong: In-cluster web app
- k9s
- No
- Freelens
- No
Resource browsing, logs, exec
- Dashboard
- Yes
- Radar
- Yes
- Headlamp
- Yes
- k9s
- Yes
- Freelens
- Yes
Topology graph
- Dashboard
- No
- Radar
- Strong: Live workload graph
- Headlamp
- Partial: Resource map
- k9s
- No
- Freelens
- Partial: Official extension
Retained event and resource-change history
Cluster events and resource changes the product itself retains for look-back - not live API state, not your monitoring stack's storage, and not a log of user actions in the product.
- Dashboard
- No
- Radar
- Strong: Memory · SQLite · Cloud up to 1 year
- Headlamp
- No
- k9s
- No
- Freelens
- No
GitOps correlation (Argo CD + Flux)
Generic CRD access is useful; typed sync status, drift, ownership, activity, and actions wired into the rest of the product is a deeper integration.
- Dashboard
- No
- Radar
- Strong: Argo CD + Flux, in core
- Headlamp
- Partial: Separate plugins
- k9s
- No
- Freelens
- Partial: Official + community extensions
Cluster security audit (Trivy / Kyverno)
Configuration, reliability, and security findings surfaced on the affected resources - and whether that ships with the product or arrives as a separately installed, separately licensed scanner.
- Dashboard
- No
- Radar
- Yes
- Headlamp
- Partial: Kyverno plugin + third-party Trivy
- k9s
- Partial: Built-in Popeye view
- Freelens
- Partial: Generic resources + extensions
MCP for external AI agents
What an external agent actually gets from the endpoint: a wrapper over the raw Kubernetes API, or operational context already correlated for agent use. Benchmarked against raw kubectl on 54 live-cluster faults, Radar's MCP server was more accurate and reached a correct diagnosis about four times sooner.
- Dashboard
- No
- Radar
- Strong: Correlated read + write tools · 4x sooner to a correct diagnosis than kubectl
- Headlamp
- Partial: In-app client only
- k9s
- No
- Freelens
- Partial: In-app client only
Organization SSO
Dashboard authenticated with a bearer token or kubeconfig upload, which is the workflow most teams wanted to stop doing.
- Dashboard
- Partial: Token or kubeconfig upload
- Radar
- Strong: In-cluster OIDC · Cloud SAML/OIDC
- Headlamp
- Partial: OIDC only · self-configured
- k9s
- No
- Freelens
- No
License
- Dashboard
- Apache 2.0 · archived
- Radar
- Apache 2.0 · no-relicense pledge
- Headlamp
- Apache 2.0
- k9s
- Apache 2.0
- Freelens
- MIT
What replaces each Kubernetes Dashboard feature?
Try Radar Desktop or local mode without changing the cluster. Move to the Helm chart only when you want a shared in-cluster URL.
| You used Dashboard for | In Radar |
|---|---|
| Browsing workloads, pods, events | Resources view - same job, with search across kinds and a detail drawer |
| kubectl proxy + token login | Local mode: kubectl radar uses your kubeconfig RBAC directly. In-cluster: ServiceAccount + OIDC SSO instead of copying tokens |
| Viewing container logs | Live log streaming, multi-container, with filtering |
| Exec into a pod | In-browser exec terminal (RBAC-gated, like everything else) |
| Watching events during an incident | Unified event and resource-change timeline - memory by default, SQLite for local persistence, or cloud-backed retention up to one year with Radar Cloud |
| In-cluster Helm install | helm install radar skyhook/radar - or skip cluster-side install entirely and run it locally |
Published · Last updated .
Common questions.
Is the Kubernetes Dashboard deprecated?
Retired outright. The repository was archived on January 21, 2026 and moved to the kubernetes-retired org. It receives no security updates, bug fixes, or new features. Existing installs keep working, but running an unmaintained, privileged web UI against your cluster is a growing liability.
What is the official replacement for Kubernetes Dashboard?
There isn't a formal one. When Dashboard was archived, SIG UI suggested users look into Headlamp, and Headlamp now sits in the kubernetes-sigs org - but no project was designated a successor. Its edge is governance, not features: vendor-neutral, so it outlasts any one company, though CNCF lists it at Sandbox, the earliest maturity tier. As a tool it's a resource browser plus plugins, which is roughly what Dashboard already was. If a semi-official project is a hard requirement, pick Headlamp. If you want a tool that's better at the job - topology, history, GitOps, and incident workflow in core - that's where Radar comes in.
Can I keep running the old Dashboard for now?
It will not stop working immediately, but the archived project no longer receives security fixes or dependency updates. Because Dashboard is a privileged interface to the Kubernetes API, keep the remaining exposure explicit and plan a replacement rather than treating the install as maintained software.
Why consider Radar over Headlamp?
Radar is the stronger all-around replacement because Issues, topology, retained change evidence, GitOps for Argo CD and Flux, traffic, Helm, audit, integrations, and MCP ship as one connected operational model. Headlamp is the better choice when vendor-neutral kubernetes-sigs governance or hosting arbitrary custom UI plugins outweighs that integrated depth. Both are Apache 2.0, so the decision can be validated directly.
Do I need to install anything in the cluster to try Radar?
No. brew install skyhook-io/tap/radar && kubectl radar runs locally against your current kubeconfig and opens a browser. The in-cluster Helm chart exists for when you want a permanently shared instance - the thing Dashboard used to be.
Replace it in the time it took to read this page.
Try Radar locally first, then move to the Helm chart only when you want a shared in-cluster URL.
$curl -fsSL https://get.radarhq.io | sh && kubectl radarApache 2.0 · No account for local use · Run Radar OSS forever