skyhook-io/radar: A Kubernetes UI and MCP Server in One Go Binary

The gap Radar is aimed at: kubectl, three terminals, and no memory

Debugging a Kubernetes incident usually means holding several unrelated tools open. kubectl get events shows you a window of recent events and forgets them. kubectl describe gives you one object with no relation to the objects around it. Helm state lives in another command, Argo CD or Flux in another UI, and the actual service traffic somewhere else entirely. The README frames Radar as "The missing open-source Kubernetes UI", and the feature list maps directly onto that fragmentation: topology, resources, Helm, GitOps, traffic, cost, audit and upgrade impact in one binary.

The intended user is an engineer with a kubeconfig and a cluster that is misbehaving. The README states that Radar runs on your laptop and talks to the Kubernetes API directly, so nothing is installed on the cluster for the default mode. That matters in environments where you cannot add CRDs or agents, and the README calls out airgapped operation with outbound egress blocked. The second user is an AI agent: the project ships an MCP server, and the topics list includes kubernetes-mcp and model-context-protocol. That is the differentiator against the older dashboards, and it is also the part with the least documentation in the repository.

How Radar works: informers on the client, SSE to the browser

The architecture visible in the repository is a Go backend with an embedded web frontend. The Dockerfile builds the frontend with Node 20 and npm workspaces, copies the result into internal/static/dist/, and then compiles a single static Go binary with CGO_ENABLED=0. The go.mod shows the pieces that do the work: k8s.io/client-go for cluster access, helm.sh/helm/v3 for release inspection, github.com/modelcontextprotocol/go-sdk for the MCP server, modernc.org/sqlite for local storage, and github.com/wailsapp/wails/v2 for the desktop app.

The README states that Radar watches the cluster via informers and pushes updates to the browser over SSE. That is the mechanism to understand before you point it at a large cluster. Informers keep a local cache of watched resources and stream changes; the cost is memory and watch connections proportional to the number of objects you watch. The README claims testing on tens of thousands of pods with responsive views and live updates under churn. That is a project claim, not an independent measurement, and the repository does not publish the cluster shape or resource limits behind it. Treat the claim as a starting hypothesis and watch your own process memory.

The MCP server is a separate surface on the same backend. The README describes it as letting AI agents "inspect, investigate, and operate your cluster through Radar". The word operate is doing real work in that sentence: an agent that can act on the cluster inherits whatever credentials Radar holds. The docs/mcp.md file is linked, but its contents are not reproduced in the README.

Installing Radar and opening the topology view

The README gives a one-line install for macOS and Linux. The script installs the binary and the kubectl plugin, so the command afterwards is kubectl radar.

curl -fsSL https://get.radarhq.io | sh && kubectl radar

After that command the README says the browser opens automatically. Homebrew users have a package instead of a pipe-to-shell script, and the README notes that the quick install, PowerShell, Homebrew and Scoop routes also set up a bare radar command, while Krew and direct downloads use kubectl radar unless you add your own symlink.

brew install skyhook-io/tap/radar

For shared team access the README documents a Helm install into its own namespace. This is the mode where Radar runs inside the cluster rather than on your laptop, and the README points to docs/in-cluster.md for Gateway API and ingress exposure, authentication and RBAC configuration.

helm repo add skyhook https://skyhook-io.github.io/helm-charts
helm install radar skyhook/radar -n radar --create-namespace

The CLI reference is not fully reproduced in the README, but the kubeconfig flags are documented: --kubeconfig defaults to ~/.kube/config and --kubeconfig-dir takes comma-separated directories of additional kubeconfig files. --namespace defaults to all namespaces. The README states that radar --help is authoritative for the installed version, which is the right habit with a project releasing as often as this one.

Where Radar gets in the way: memory, credentials, and the desktop caveat

The first limitation is structural. A client-side informer cache is convenient and it is not free. On a cluster with a large number of pods, secrets or custom resources, the process on your laptop holds a copy of what it watches. The README does not document a way to narrow the watch set beyond the --namespace flag, and the flag table in the README is explicitly a subset of the full CLI reference. If your cluster is large and your laptop is small, test before you rely on it.

The second is the credential surface. Running Radar on your laptop means it uses your kubeconfig, so it has exactly your permissions. That is a clean security story for the laptop mode and a poor one for the in-cluster mode if RBAC is left at defaults, because every user of the shared URL inherits the service account's rights. The README defers the details to docs/in-cluster.md, which is not reproduced in the README, so the RBAC defaults are something you must read in the chart before exposing the service.

The third is the MCP server. An MCP client is an AI agent, and the README's own wording includes operating the cluster. The README does not describe a read-only mode, an allowlist of verbs, or a confirmation step for mutating calls. If you cannot answer what an agent is permitted to do through Radar in your environment, do not enable the MCP endpoint against a production cluster.

Finally, the desktop app is a separate artifact with its own packaging: a Homebrew cask, a .deb, an .rpm and a Scoop package. The README does not state that the desktop app and the CLI stay in lockstep on features, so treat them as two products with one name until you check.

Radar versus Headlamp, k9s and Lens

The closest comparison in kind is Headlamp, the CNCF Kubernetes UI. Both are open source, both run as a desktop or in-cluster application, and both aim at the same gap. The difference in approach is the plugin model. Headlamp is built so that functionality is added through plugins, which is how a team extends it with its own resource views. Radar instead ships a fixed set of views in a single Go binary and adds the MCP server as its extension surface for agents. If your requirement is a UI your platform team can extend in JavaScript, Headlamp's model is the one to evaluate; if your requirement is a binary you can drop on a laptop and an MCP endpoint for an agent, Radar is the more direct fit.

k9s is the other common answer, and it is a terminal UI rather than a web UI. It is faster to start and lighter, and it has no browser, no SSE stream and no MCP server. For an engineer who lives in a terminal, k9s covers most of the daily inspection work. Radar's argument is the views k9s does not have: topology, image filesystem, upgrade impact, GitOps state and live service traffic. That is a real difference in scope, and it is also more surface area to verify.

The traffic view deserves a specific note because the go.mod lists github.com/cilium/cilium as a dependency. Live service traffic in Kubernetes generally means either a service mesh or an eBPF-based data source, and the presence of the Cilium module suggests Radar reads from that family of tooling rather than capturing packets itself. The README does not explain the traffic view's data source, so confirm what your cluster must run before expecting that view to populate.

Maintenance, releases and the Apache-2.0 licence

The repository is not archived, and the last push was on 2026-09-10. The release cadence is visible and tight: v1.12.1 on 2026-08-26, v1.12.2 on 2026-08-31, and v1.13.0 on 2026-09-07. That is roughly a release a week, which cuts both ways. Fixes arrive quickly. So does churn, and the README's own instruction to treat radar --help as authoritative for the installed version is an acknowledgment that flags move.

Upgrade cost is mostly your own operational work. The CLI and desktop app upgrade through Homebrew, Scoop or a fresh download. An in-cluster install upgrades through the Helm chart, and the README lists an upgrade impact view among Radar's own features, which is a neat bit of dogfooding: you can use Radar to see what a chart change would do to the workloads it manages. The README does not document a rollback procedure for the Helm release, so plan that with helm rollback and your own values file rather than expecting guidance in the README.

Radar is Apache-2.0, which permits commercial and internal use and requires that you preserve the licence and notice files when redistributing. The repository ships a LICENSE file and a SECURITY.md. If you redistribute Radar inside a product, the usual Apache-2.0 obligations apply, including the patent grant and the notice requirements. That is a description of the licence text, not legal advice, and the bundled dependencies (Helm, client-go, Cilium, the MCP Go SDK and others) carry their own licences that you should enumerate from go.mod if redistribution matters to you.

Editorial conclusion

Radar fits platform and application engineers who debug Kubernetes by hand and want topology, event history and GitOps state in one place without installing anything in the cluster. Skip it if you need a long-lived shared dashboard with mature SSO, or if you cannot run an unvetted binary against a production kubeconfig. Before adopting, verify three things: that the latest release is v1.13.0 and the last push was 2026-09-10, that the MCP server's default exposure matches your security posture, and that the Apache-2.0 licence and the chart's RBAC defaults satisfy your own review.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. skyhook-io/radar on GitHub