Radar v1.14.1 puts cluster evidence and actions in one local UI
Radar v1.14.1 runs as a kubectl plugin, desktop application, or in-cluster service. It covers resources, topology, events, Helm, GitOps, traffic, cost data, audits, and upgrade impact. Radar makes sense when an operator keeps bouncing between kubectl, a Helm command, a metrics screen, and a GitOps console to explain one failure.
Our checkout contained 2,684 files and about 761,633 source lines before dependencies, despite occupying only 44.7 MB. Radar is mostly Go with React and TypeScript frontends, plus a Wails desktop shell. It is a local operations console rather than a light resource viewer. Released local mode talks directly to the Kubernetes API through your existing kubeconfig and needs no cluster agent.
The source build requires Go 1.26+, Node.js 20+, npm, and Make
The development guide names Go 1.26+, Node.js 20+, npm, kubectl access, and Make as prerequisites. make deps installs Go and frontend dependencies. Separate targets build the embedded binary, run Go tests, type-check TypeScript, build the desktop application, and create a Docker image. Source evaluation should follow those entry points instead of treating the root package manifest as the whole project.
Our npm harness installed 443 packages in 14 seconds and left 455 MB on disk. It found no npm build or test script, so both stages were skipped. This does not mean Radar has no build or tests. An npm-default automation job simply cannot exercise them. The repository had 10 CI workflow files and a Dockerfile, while documented checks live behind Make.
What happened when we ran it
Our run used commit e7b176b in an unprivileged Node 22 container with 3 CPUs, 8 GB of RAM, and no secrets. Installation succeeded in 14 seconds. The checkout held 2,684 files, about 761,633 source lines, and 44.7 MB. npm added 443 packages and expanded disk use to 455 MB. These are source-checkout costs, not a release binary size or runtime memory result.
Build and test were skipped because npm exposed no matching script or target. We did not substitute Make commands, so our run gives no pass or fail result for Radar's documented build and Go test suite. npm audit reported 4 known vulnerabilities, split between 2 high and 2 moderate, with none critical or low. The supplied log did not identify packages or fixes, so we cannot narrow those findings.
The MCP server is enabled by default on port 9280
Radar starts MCP at http://localhost:9280/mcp. It reduces Kubernetes output before an agent sees it, adding topology, health assessments, selected events, and filtered logs. Claude Code, Codex, Cursor, and other HTTP MCP clients can connect to the same process. Diagnosis is read-only by default. Restart, scale, apply, and rollback tools are marked for client confirmation and still pass through Kubernetes RBAC.
A codebase of roughly 761,633 source lines deserves a careful permissions review. The MCP guide says Radar omits Secret values and redacts environment values plus common credentials in logs. An MCP client is still attached to a process holding your Kubernetes identity. Use a least-privilege kubeconfig, remove write rights when the agent only needs evidence, and pass --no-mcp when you only want the UI.
Shared authentication filters most namespaced reads by namespace
Radar's authentication guide says most namespaced reads are authorized at namespace granularity instead of checking every resource kind per user. Secrets and cluster-scoped resources get tighter checks. One shared in-memory cache watches resources through Radar's service account, then the application filters results for each user. Teams needing harder tenant walls should run separate namespace-scoped instances for separate trust boundaries.
The repository included 10 CI workflows and a Dockerfile, and the project ships a Helm path for shared access. Production still needs choices about ServiceAccount permissions, ingress exposure, OIDC or proxy headers, session secrets, and metrics credentials. Local mode has no authentication by default. The README warns that non-loopback access needs authentication and network controls, an important limit for a console that can edit resources and open terminals.
Open issue 1785 makes node drains a manual verification step
Open issue 1785 says Radar treats accepted eviction requests as completion instead of waiting for every pod to disappear. The interface warns that pods may still be terminating, but the drain path returns early. Both the HTTP action and MCP's manage_node drain use that path. Before rebooting a node, verify separately that workloads with a termination grace period have exited.
GitHub showed 3,433 stars, 43 open issues, and 40 open pull requests on September 22, 2026. The last push landed that day, several pull requests changed the same day, and v1.14.1 arrived on September 17. Those are strong maintenance signals. Open Ubuntu desktop crash reports for the YAML editor and related-resource navigation still matter because Radar can sit in an operator's write path.
Radar is the right fit when one cluster question crosses several tools
Radar v1.14.1 is worth trying if you want cluster data to stay local and an agent to receive structured evidence instead of raw YAML. K9s is leaner for terminal work. Headlamp is the better pick when UI plugins drive the decision. Devtron suits teams seeking a wider delivery platform rather than a workstation-centered diagnostic console.
Our 14-second install and 455 MB dependency footprint make the frontend workspace easy to obtain, though they do not prove the Make build. Start with the released binary, a read-only kubeconfig, and one non-production cluster. Keep shared deployments behind real authentication. Until the drain behavior changes, verify that pods are gone before powering down a node.