Radar: A Single-Binary Kubernetes UI With an MCP Server for Agents
The missing open-source Kubernetes UI with a built-in MCP server for AI agents. See what's broken, why, and what changed. Issues, Topology, event timeline, Helm, GitOps, live service traffic, and cluster audits - all in one Go binary.
At a glance
- What is it?
- Radar is an Apache-2.0 Go binary that reads your cluster through the Kubernetes API and serves a browser UI plus a Model Context Protocol endpoint. It is aimed at engineers who want cluster inspection without installing anything into the cluster, and the trade-off is that its in-cluster mode is a separate deployment path with its own RBAC surface.
- Who is it for?
- Adopt Radar if you debug Kubernetes from a workstation and want topology, Helm, GitOps and timeline views without deploying an agent or CRD into the cluster, or if you need an MCP server that exposes the same cluster view to an AI agent. Do not adopt it if your only requirement is a shared, long-lived dashboard for a large team with centrally managed authentication, because that path is the in-cluster Helm install and it carries its own RBAC and ingress configuration.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap Radar targets: kubectl output that does not show relationships
Kubernetes troubleshooting usually means reading several resource types in sequence and holding the relationships in your head. A pod is crashing, so you check its events, then the ReplicaSet, then the Deployment, then the Helm release that owns the Deployment, then the Argo CD or Flux resource that owns the Helm release. Each step is a separate command with a separate output format. Radar's stated purpose is to collapse that sequence into one view: the README lists topology, resources, Helm, GitOps, traffic, audit and upgrade impact as views inside a single binary. The audience is the engineer who already knows kubectl and wants the relational context without writing the joins by hand. The README also positions it for AI agents through a built-in MCP server, which is a different audience: a tool that needs to read cluster state through a stable interface rather than parse kubectl text. Both audiences share one requirement, which is that the tool must not require anything installed in the cluster to be useful.
How the data path works: informers on the API server, SSE to the browser
The README states that Radar watches your cluster via informers and pushes updates to the browser via SSE. That is the whole architecture in one sentence, and it explains the deployment story. Informers are the client-go mechanism for maintaining a local cache of a resource type by watching the API server; running them in a process outside the cluster means the process needs a kubeconfig with read access and a network path to the API server. The SSE side means the browser does not poll. It holds an open connection and receives pushed diffs as the informer cache changes. This is why the README can claim the views stay responsive under cluster churn: the browser is not re-querying, it is receiving. The practical consequence is that Radar's memory footprint scales with the number of objects it caches, not with the number of browser tabs. On a cluster with tens of thousands of pods, that cache lives on whatever machine runs the binary. The README says Radar has been tested at that scale but does not publish a memory figure, so the actual ceiling on a given laptop is something you would have to observe yourself.
Install paths: laptop binary, desktop app, or Helm chart
The README gives a one-line install: `curl -fsSL https://get.radarhq.io | sh && kubectl radar`. Homebrew users can run `brew install skyhook-io/tap/radar`. Krew users get `kubectl krew install radar`. Windows users have Scoop and a PowerShell installer. There is also a desktop app distributed as a Homebrew cask, a `.deb`, an `.rpm`, and a Scoop package. The distinction between the CLI install and the desktop install matters: the README notes that quick install, PowerShell, Homebrew and Scoop set up the bare `radar` shorthand, while Krew and direct downloads use `kubectl radar` unless you add your own symlink. That is a small thing that will bite someone following a blog post rather than the README. The in-cluster path is separate: `helm repo add skyhook https://skyhook-io.github.io/helm-charts` followed by `helm install radar skyhook/radar -n radar --create-namespace`. The README points to an in-cluster deployment guide for Gateway API and ingress exposure, authentication, and RBAC configuration. Those three topics being delegated to a separate document is a signal about where the operational complexity lives.
The MCP server is the differentiating piece, and the least documented here
Most Kubernetes UIs are read-only dashboards. Radar ships a Model Context Protocol server, which means an AI agent can call into the same cluster view the UI renders. The README describes it as letting agents inspect, investigate, and operate your cluster through Radar, and links to `docs/mcp.md`. The word operate is doing real work in that sentence. Inspect and investigate are read operations; operate implies write operations, and the README does not enumerate which verbs the MCP server exposes or how they are gated. That is the single most important thing to verify before enabling it, and it is not answered in the material available here. The mitigation is structural rather than documentary: because Radar reads through whatever kubeconfig or service account it is given, the blast radius of an MCP-exposed write is bounded by the RBAC of that identity. A laptop kubeconfig with cluster-admin is a very different risk profile from an in-cluster service account scoped to one namespace. The README's own framing, that in-cluster deployment offers RBAC-scoped permissions, suggests the project expects that distinction to be handled at deployment time.
Where Radar is the wrong tool
Radar is a client, not a control plane. It has no server-side component in the laptop mode, which means there is no shared state, no audit log of who looked at what, and no way for two engineers to see the same view unless they both run it. The README's answer to that is the in-cluster Helm deployment for shared team access, but that reintroduces exactly the thing the laptop mode avoids: a workload in your cluster with a service account, plus ingress and authentication to configure. If your requirement is a long-lived dashboard behind your existing SSO, you are choosing the heavier path, and the README does not describe what authentication options that path supports beyond pointing at the guide. A second boundary: Radar is a Kubernetes API client, so it shows you what the API server knows. If your problem is at the node, kernel, CNI or storage layer, the topology view will show a pod in a bad state and the event timeline will show you what the kubelet reported, but the diagnosis continues in whatever tool owns that layer. The README's support list is Kubernetes resources plus Helm, GitOps, traffic and audit, not host-level observability.
Compared with k9s and with a hosted dashboard
The closest comparison in daily use is k9s, which is a terminal UI over the same Kubernetes API. The difference is the interface model, not the data source. k9s renders resource lists and lets you drill in with keystrokes; Radar renders a topology graph in a browser and pushes live updates over SSE. If you work over SSH or in a terminal-only environment, k9s fits and Radar's browser UI does not, though the README notes Radar works in locked-down environments with outbound egress blocked, which covers the airgap case rather than the no-browser case. Against a hosted dashboard, the difference is where the data goes. Radar's README states that cluster data stays on your machine, with no account, no agents and no cloud sync. A hosted product by definition receives your cluster metadata. For teams under data-residency or egress constraints, that is the deciding factor, and it is the reason the airgapped claim appears in the README at all. What Radar does not offer in the laptop mode is the shared, always-on view a hosted dashboard provides, so the comparison is between privacy and centralization rather than between feature lists.
Maintenance cost, licence, and what to check before adopting
Radar is Apache-2.0, which permits commercial use, modification and redistribution provided the licence and notices are preserved; the repository ships a LICENSE file. That is a permissive licence with no copyleft obligation on your own code, and it is the reason a tool like this can be bundled into an internal platform without a legal review cycle. This is not legal advice, and if you are redistributing a modified binary you should read the licence text and the NOTICE handling rather than rely on a summary. On maintenance: the release cadence visible in the supplied data is roughly weekly, with v1.13.0 on 2026-09-07, v1.12.2 on 2026-08-31 and v1.12.1 on 2026-08-26, and the last push to the default branch is 2026-09-10. A weekly cadence on a client tool means you should expect to upgrade the binary to get fixes, and the upgrade cost is low because there is nothing to migrate in the cluster for the laptop mode. The in-cluster mode is where upgrade cost appears: a Helm release means a chart version bump and a rollout, and the README's mention of a separate helm-charts repository means chart and binary versions can drift. Before adopting, run `radar --help` on the installed version, since the README states that command is authoritative and that the flag table in the README covers only common startup flags.
The cloud status command and the diagnostic pattern it implies
One command in the README is worth reading closely because it shows how the project thinks about a failure mode. `radar cloud status` reports installation ownership, chart and image, agent readiness, and Cloud configuration without printing the connection token. It accepts `--context`, `--namespace` and `--release`, and passing both namespace and release selects an exact installation. The design detail is the fallback: if the Secret or Hub is unavailable, local installation diagnostics still run. That is a deliberate choice to make the command useful when the thing it is diagnosing is broken, which is the opposite of the common pattern where a status command fails because the dependency it checks is down. The token handling is also explicit: the command reports configuration without printing the token, and the README notes that live tunnel status is reported by Radar Cloud using the token in the referenced Kubernetes Secret. For anyone running Radar in-cluster behind a corporate network, that command is the first thing to run when the UI stops updating, because it separates a local installation problem from a connectivity problem.
Editorial conclusion
Adopt Radar if you debug Kubernetes from a workstation and want topology, Helm, GitOps and timeline views without deploying an agent or CRD into the cluster, or if you need an MCP server that exposes the same cluster view to an AI agent. Do not adopt it if your only requirement is a shared, long-lived dashboard for a large team with centrally managed authentication, because that path is the in-cluster Helm install and it carries its own RBAC and ingress configuration. Before rolling it out, verify the CLI flag set against `radar --help` for your installed version, confirm that the in-cluster chart's RBAC scope matches your namespace boundaries, and check whether the MCP server is enabled by default in your deployment.
Community notes