Dora NodaOn January 21, 2026, the project that taught a generation of operators what their clusters look like was switched off. The official Kubernetes Dashboard was archived — deprecated, unmaintained, with its own docs page pointing new installs at Headlamp instead. Within weeks of that retirement, Mirantis kept tightening the screws on the other end of the market: Lens now wants a Lens ID account, roughly $25 per user per month for commercial use, exec/logs/shell behind the subscription wall, and offline activation reserved for Enterprise tiers. If you run an air-gapped or self-hosted fleet, the two default answers to "how do I look at my cluster" both got worse in the same quarter.
That is the gap Skyhook's Radar launched into in January 2026. The pitch is printed right on the repo: "Modern Kubernetes visibility. Local-first. No account. No cloud dependency." One Go binary, your kubeconfig, a live dashboard in about 15 seconds — with resource topology, event timelines, Helm management, Argo CD and Flux status, and live service traffic in the same window. Free, Apache-2.0, maintained by Skyhook (YC W23), with the open-source build fully featured rather than a teaser for a hosted tier.
So here is the answer up front, and the receipts for every row follow below.
| Radar | Headlamp | k9s | Lens | |
|---|---|---|---|---|
| License / cost | Apache-2.0, free, OSS fully featured | Apache-2.0, free (CNCF Sandbox → SIG UI) | Apache-2.0, free TUI | Proprietary; ~$25/user/mo commercial, account required |
| Trust boundary | Local process, kubeconfig RBAC; no account, agent, CRD, cloud sync, or telemetry | Local desktop or in-cluster pod; no account | Local terminal; no account | Lens ID + vendor cloud; offline only on Enterprise |
| Install footprint | Single Go binary (kubectl radar, brew, Scoop, desktop, or in-cluster Helm) | Electron desktop or in-cluster Helm chart | Single terminal binary | Electron app + subscription activation |
| Topology / timeline / Helm depth | Topology, event Timeline, Helm view (values, manifests, revision diffs) built in | Resource browsing + plugin system (Flux plugins exist) | No topology or timeline views; wraps kubectl semantics | Full IDE-style views, gated by tier |
| GitOps depth | Argo CD + Flux side-by-side fleet view with sync/suspend/resume/reconcile/rollback | Via community plugins | None native | Via extensions, gated by tier |
| Network visibility | Traffic view auto-detecting Hubble, Istio, Caretta, or Beyla + per-resource Reachability | None native | None | Via extensions |
| Auditability | Cluster audit + RBAC views; actions run as you under kubeconfig RBAC | Actions run as your RBAC identity | Same (terminal) | Centralized team features on paid tiers |
Three things jump out before we open anything. First, nobody else in the free column ships GitOps and network traffic and an audit view in one install — that combination is Radar's actual differentiator, not the 15-second startup. Second, the local-first tools all share one structural property: actions run as your kubeconfig identity, which is both the security story and the ceiling. Third, Lens still wins on team-wide workflow — which is exactly where this post draws the line. The rest is about which side of that line your fleet lives on.
What Radar actually is (and what "15 seconds" measures)
Radar (skyhook-io/radar) is a single Go binary with no dependencies: no in-cluster agent, no CRDs to install, no sidecar, no account, no cloud sync, no cluster telemetry. You point it at the kubeconfig you already have — brew install skyhook-io/tap/radar then kubectl radar, or Krew, Scoop, a .deb, a native desktop app for macOS/Linux/Windows, or a Helm chart if you want it in-cluster for shared team access. A February 2026 hands-on put it plainly: it runs locally, connects directly to the kubeconfig, and was up in minutes end to end.
About that 15 seconds: read it as the time from launching the binary to a rendered live dashboard against a warm kubeconfig — process start, API discovery, first topology paint — not the full install-to-value loop on a cold machine. That is still a meaningful number, because the thing it excludes is the point: there is no cluster-side install to wait for, no token to mint, no OAuth dance. The stopwatch starts when you already have access, which, for the on-call operator at 2 AM, is the only stopwatch that matters.
Inside, the view list is wide: Topology, Resources, Image Filesystem, Timeline, Helm, Compare, TLS, GitOps, Traffic, Cost, Audit, Upgrade impact, RBAC, MCP, and Auth. Two details deserve emphasis because they shape everything below. Cost auto-discovers a local Kubecost aggregator or reads Prometheus cost metrics, so spend views work without a SaaS billing integration. And the whole thing is private by design — the project states it does not upload manifests, logs, events, metrics, or resource data to Skyhook. For an air-gapped fleet, "the UI phones home to nobody" is not a nice-to-have; it is the admission ticket.
Head to head: one differentiator per tool
The matrix above compresses the decision; this section expands each row to the single fact that should settle it for a Cluster-API fleet operator.
Lens: the account is the product now. Lens remains the most polished Kubernetes IDE, with over a million users. But the direction of travel is unambiguous — subscription-gated commercial use, a mandatory Lens ID, exec/logs/shell behind the paywall, and air-gapped activation as an Enterprise feature you arrange with an administrator. For a fleet whose entire premise is "no vendor in the control path," that is not a pricing complaint; it is a disqualifying architecture. You cannot put a tool that requires phoning a vendor cloud in front of clusters that are not allowed to reach one.
Headlamp: the safe default, and the official heir. Headlamp is Apache-2.0, lives under Kubernetes SIG UI after incubating in CNCF Sandbox, runs either as an Electron desktop off your kubeconfig or as an in-cluster deployment, respects your RBAC, needs no cluster-side agent for core use, and is what kubernetes.io now recommends where the Dashboard used to be. Its superpower is the plugin system — homelabs already run Flux and cert-manager plugins that add GitOps pages to the stock UI. The honest tradeoff: every capability beyond resource browsing is a plugin you evaluate, install, and maintain separately. VMware ships it as a vSphere add-on; individuals run the desktop. It is a platform for building your dashboard, where Radar is a dashboard that already made the choices.
k9s: the speed bar, and the floor. The Apache-2.0 terminal UI is still the fastest way to move through a cluster once the keybindings are in your fingers, and it respects RBAC the same way everything kubeconfig-native does. What it cannot do is show you anything: no topology graph, no event timeline, no traffic map, no GitOps fleet state. For incident response it is the scalpel; the question this post asks is what holds the patient still, and a TUI is not that.
Radar: the only free option where GitOps and network views are built in, not bolted on. That sentence is the whole case. If your operator workflow is "check the Argo app, check the traffic, check the events," Radar is the only tool in the free column where all three are first-party views in one binary. The price is youth — a January 2026 launch means a smaller plugin ecosystem than Headlamp and less battle-testing than Lens or k9s — and opinionation: you get Skyhook's chosen views, not a framework for composing your own.
Day-2 work without leaving the window
Dashboards die in the demo when the operator has to drop to a terminal for the second task. Radar's bet is that topology, timeline, Helm, and GitOps in one window covers the actual day-2 loop.
Topology and Timeline are the "what broke and what changed" pair from the repo's own tagline. Topology renders resource relationships with pan, zoom, and multi-select; Timeline gives the event history behind the current state. The pairing matters for the most common on-call question, which is never "what is the state" but "what changed just before the state got bad."
Helm gets a dedicated view: releases across namespaces with status, chart and app versions, resource health, stored values and rendered manifests, revision diffs, and failed-upgrade identification. For a PaaS fleet where tenant apps arrive as charts, "diff this failed release against the previous revision" inside the same UI that shows the broken pods removes an entire context switch from the rollback decision.
GitOps is the deepest cut. A fleet view shows Argo CD (Application, ApplicationSet, AppProject) and FluxCD (GitRepository, OCIRepository, HelmRepository, Bucket, Kustomization, HelmRelease, Alert) applications side by side with sync, health, source, destination, and lifecycle state, each with a per-app detail page (Topology / Changes / Activity tabs). Actions — sync, suspend, resume, reconcile, rollback — are exposed with lifecycle-aware refusal, meaning the tool declines operations that would violate the resource's own lifecycle rather than firing the API call and letting the controller sort it out. Resources carry a Managed by chip cross-linked from topology, timeline, and Helm views, and Flux source CRs get a Consumed by panel. This is the "without sacrificing GitOps" half of the title's promise, stated concretely: both engines, one fleet view, guarded actions, bidirectional links between the GitOps object and the live resources it manages.
Network visibility: the half of the promise everyone else punts on
This is the "without sacrificing network visibility" half, and it is where the comparison stops being close. None of Headlamp, k9s, or the free tier of Lens ships a service-traffic view. Radar's Traffic view auto-detects whichever telemetry your cluster already runs — Cilium Hubble, Istio, Caretta, or Grafana Beyla — and renders live service traffic from it, with a Reachability tab on each resource's detail view answering "what can actually talk to this workload."
Two honest caveats, because a view is only as good as its data source. First, Radar does not generate traffic telemetry; on a bare Cluster-API fleet with Cilium but no Hubble enabled, or with no mesh at all, the Traffic view has nothing to paint until you install one of the four sources. Auto-detection meets Hubble where it lives on a Cilium fleet and meets Caretta's eBPF service-dependency map where a Grafana-centric shop already runs it — but budget the data-source install, not just the UI install. Second, reachability answers need read access on those sources' APIs, which your operator RBAC has to grant. Neither caveat is a flaw; both are why "network visibility included" should always name the required backend, which this one does.
The honest limit: whose actions are these, and who can audit them?
Everything above runs on one structural fact: a local-first UI acts as you, under your kubeconfig's RBAC, on your machine. That is the security story — no third-party data path, no shared credential store, nothing to breach except the operator's laptop — and it is also the ceiling. For an air-gapped Cluster-API fleet, the line falls here:
| Keep it local | Needs auditable, API-backed control-plane actions |
|---|---|
| One operator diagnosing one cluster: topology, timeline, Helm diffs, GitOps syncs as your own RBAC identity | Many operators acting on shared tenant clusters: who synced which app, when, and with what result |
| Air-gapped or regulated environments where no vendor cloud may sit in the path | Delegated access: on-call gets break-glass without handing out cluster-admin kubeconfigs |
Agent-assisted diagnosis scoped to a single session (Radar's built-in MCP server exposes diagnose, get_cluster_audit, and get_subject_permissions to an AI agent — disable it with --no-mcp) | Agent-operated remediation at fleet scale: guardrailed, policy-checked, logged actions across clusters, not one laptop's tool calls |
Audit views as information (missing probes, latest tags, single-replica Deployments, absent PDBs, same-node replicas, orphan Services, deprecated APIs) | Audit findings as workflow: tickets, approvals, and verified remediation with a trail a second human can replay |
The MCP point deserves one paragraph, because "built-in MCP server" is the feature most likely to be misread. An agent that can call manage_gitops (sync/suspend/resume/reconcile/rollback with lifecycle-aware refusal) through your local Radar is an agent borrowing your authority — fine for assisted diagnosis, wrong as a fleet automation substrate. The moment agent actions must outlive your laptop session, follow policy, and be replayable by someone who was not in the room, they belong behind an API-backed control plane with its own audit log, not inside a desktop UI's tool server. Local-first is the safer observability boundary; it is not a substitute for a governed action boundary.
Verdict: who should switch, and who should stay
Switch to Radar if: you operate self-hosted or air-gapped clusters, you live in Argo or Flux plus Helm, you already run Hubble/Cilium or another supported traffic source, and your operators act as individuals under their own RBAC. You get the only free UI where GitOps, traffic, audit, and cost views are first-party, installed in one binary, with no vendor in the path.
Stay where you are if: you need Headlamp's plugin framework because your dashboard is really a bespoke internal developer platform; you live in k9s and genuinely never want a graph; or you pay for Lens because centralized team workflow, shared contexts, and vendor-supported collaboration are worth the subscription and the account. Those are real needs — they are just not observability needs, and a local UI was never going to meet them.
The larger pattern is worth naming. The Dashboard archival and the Lens paywall are the same event viewed from two sides: the middle of the Kubernetes UI market — free, graphical, maintained, respectful of your trust boundary — hollowed out, leaving a terminal on one side and a subscription on the other. Radar, Headlamp's promotion to SIG UI, and the eBPF telemetry it all rides on are the middle filling back in, as open source, running where your clusters run. For a self-hosted PaaS, that is not a tooling preference. It is the only UI story consistent with owning the machines.
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.
