Radar
The missing open-source Kubernetes UI
764 followers
The missing open-source Kubernetes UI
764 followers
Radar is an open-source Kubernetes UI and MCP server. It shows topology, resources, events, Helm, GitOps, live traffic and security checks, and it gives AI agents the same view: click Investigate on any issue and your agent finds the root cause. Run it locally as a single binary or in-cluster with RBAC and OIDC, no account needed. Radar Cloud adds fleets, alerts and hosted investigations.
Hey PH 👋 Eyal, Roy, and Nadav here - the team behind Radar. We also build Skyhook, YC W23.
We've wanted a better Kubernetes UI for a long time. kubectl is powerful, but day-to-day cluster work still ends up split across terminals, dashboards, Helm, Argo/Flux, cloud consoles, and log tools.
The existing options all have tradeoffs. Lens lost the OSS trust that made people love it. FreeLens is a welcome fork, but still carries the same heavy Electron desktop model. Headlamp is useful, but shallow once you want deeper operations - Helm, GitOps, traffic, audits. k9s is excellent if you live in the terminal, but not everyone does. And the SaaS tools often price by node and ask for a work email before they let you look at your own cluster.
So we built the Kubernetes UI we wanted: fast, local-first, open source, and not locked behind an account. We quietly shipped it a couple of months ago. The community took it past 1.4k GitHub stars and gave us way more feedback than we expected, so we kept shipping. Today is the proper launch.
What's in it:
- Topology with real ownership chains, not force-directed spaghetti
- Live event stream across all resources using Kubernetes watches, not polling
- Helm release management with diff/rollback + native Argo CD / Flux sync
- Live traffic flows via Hubble/Cilium, Caretta, or Istio
- Cost insights via OpenCost - auto-detected per namespace, workload, and node
- Cluster audit - 31 checks across security, reliability, and efficiency
- Image filesystem viewer - read container files in the UI, no exec, no pull
- Built-in MCP server - point Cursor or Claude at your cluster
Plus first-class integrations for 20+ popular K8s tools - Argo Rollouts, Karpenter, KEDA, cert-manager, Trivy, Kyverno, Velero, Knative, and more.
Single Go binary. Apache 2.0. No account required. No usage tracking. No cloud dependency.
Site: https://radarhq.io
Repo: https://github.com/skyhook-io/radar
Discord: https://radarhq.io/community/chat
Also yes, we cared about making it beautiful. K8s tools don't have to look like punishment.
Would love your feedback - what's missing, what breaks, what we got wrong. We're here all day.
a cluster audit with 31 checks across security and reliability is a massive value-add for day-to-day ops. we usually run separate trivy or kyverno reports, so having that integrated into the primary ui workflow is a huge time-saver. does the audit allow for custom check injection? @nadav_erell
The MCP-for-AI-agents piece is the most interesting bit and the existing comments haven't poked at it. What can an agent actually do via Radar's MCP — read-only stuff (describe pods, fetch events, summarise an outage), or destructive ops (kubectl delete, rollout restart)? That boundary decides whether anyone runs this against a prod cluster.
@sounak_bhattacharya Hi, Roy from the Radar team here. Good question!
We had your considerations in mind when building it. Boundary is "non-destructive by design." No delete, no force-uninstall, no --cascade=orphan.
Reads: dashboard, resources, topology, events, pod / workload logs, changes timeline, Helm releases. Outputs are minified and secret-scrubbed (Secret .data never returned, env values redacted, logs scrubbed for token shapes).
Writes are a curated, non-destructive set: restart / scale / rollback workloads, trigger / suspend cronjobs, sync / reconcile GitOps, cordon / drain nodes, and apply_resource with dry_run. Nothing that deletes.
The other half is RBAC. Calls go through K8s with the user's identity (impersonation in OIDC / proxy mode, the agent's ServiceAccount otherwise), so the agent inherits exactly your perms - a 403 from K8s is a 403 from MCP. And in OSS, MCP listens on loopback only.
Full breakdown at /features/mcp.
Would love to hear your feedback on this approach - and if you've got ideas for where the boundary should sit differently, very open to it.
Local-first with zero cluster-side installation is the right call. When I was scaling an engineering org from 15 to 120, the biggest friction with K8s tooling was always the chicken-and-egg problem: you need cluster access to install the tool that helps you understand the cluster. Having this run as a single binary using existing kubeconfig means any engineer can get visibility without needing platform team approval first. That alone probably saves a week of onboarding time per new infrastructure hire.
@avrisimon 🎯
@jalcantara You deserve better than shoddiness :)
We basically built this because none of the existing options really did what we wanted well enough. Surprising that this is the case for k8s in 2026.
nice - gave it a star! good luck!
@nikolas_dimitroulakis thank you, much appreciated!