Power your agent
The publisher's own command. Not a PlugMCP endpoint.
Host a copy with our keys and logs.
docker run -i --rm ghcr.io/skyhook-io/radar:1.20.2Claude Code has no install link for a local command. Copy the command below and run it in a terminal.
claude mcp add skyhook-io-radar -- docker run -i --rm ghcr.io/skyhook-io/radar:1.20.2Run in a terminal.
{ "mcpServers": { "skyhook-io-radar": { "command": "docker", "args": [ "run", "-i", "--rm", "ghcr.io/skyhook-io/radar:1.20.2" ] } }}claude_desktop_config.json
Remote URL or a command on your machine? How the two installs differ
Chạy trên PlugMCP
A new server you create. It is not this listing's official endpoint. Use the publisher install when you want their URL and their credentials.
MởOverview
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.
Tools
No tool list yet. Remote servers get one after the first health check.
FAQ
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 clus
{ "mcpServers": { "skyhook-io-radar": { "command": "docker", "args": [ "run", "-i", "--rm", "ghcr.io/skyhook-io/radar:1.20.2" ] } }}Copy the stdio config for Cursor, Claude Desktop, Claude Code, or VS Code on this page. It uses the publisher's install, not a PlugMCP proxy.
No required environment variable is listed on this record.
Radar runs locally over stdio.
Last checked 2026-11-11. Zero install on your cluster — runs on your laptop, talks to the K8s API directly. Single binary — no dependencies, no agents, no CRDs. Fast on big clusters — tested on tens of thousands of pods, with responsive views and live updates under real cluster churn
From the publisher
The missing open-source Kubernetes UI. Single binary. No account required. Free forever.
🌐 radarhq.io · Docs · Releases
Topology, resources, Helm, GitOps, traffic, audit, upgrade impact, and MCP context for AI agents — from your laptop or in-cluster.
"Have Radar deployed at work. As far as Kubernetes dashboards go, this is one of the best." — u/TheRealNetroxen
Quick Install:
curl -fsSL https://get.radarhq.io | sh
Homebrew:
brew install kubectl-radar
Also available from our tap: brew install skyhook-io/tap/radar.
Then run: kubectl radar. Quick install, PowerShell, Homebrew, and Scoop also set up the radar shorthand. Krew and direct downloads use kubectl radar unless you add your own radar symlink.
Krew (kubectl plugin manager):
kubectl krew install radar
Scoop (Windows):
scoop bucket add skyhook https://github.com/skyhook-io/scoop-bucket
scoop install radar
PowerShell (Windows):
irm https://get.radarhq.io/install.ps1 | iex
Custom install location (macOS/Linux):
curl -fsSL https://get.radarhq.io | INSTALL_DIR="$HOME/.local/bin" sh
Quick install writes to /usr/local/bin unless INSTALL_DIR says otherwise. The directory is created if missing, and needs to be on your PATH for radar and kubectl radar to resolve.
Direct download — GitHub Releases for macOS, Linux, or Windows.
Native desktop app — no terminal needed.
Homebrew (macOS):
brew install --cask skyhook-io/tap/radar-desktop
Debian/Ubuntu — download the .deb from GitHub Releases, then:
sudo apt install ./radar-desktop_*.deb
Fedora/RHEL — download the .rpm from GitHub Releases, then:
sudo rpm -i radar-desktop_*.rpm
Scoop (Windows):
scoop bucket add skyhook https://github.com/skyhook-io/scoop-bucket
scoop install radar-desktop
Windows (direct download) — GitHub Releases.
Deploy to your cluster for shared team access:
helm repo add skyhook https://skyhook-io.github.io/helm-charts
helm install radar skyhook/radar -n radar --create-namespace
See the In-Cluster Deployment Guide for Gateway API and ingress exposure, authentication, and RBAC configuration.
# Opens browser automatically
kubectl radar
# Quick install, PowerShell, Homebrew, and Scoop also set up the bare command
radar
To inspect an in-cluster Radar Cloud installation without changing it:
radar cloud status
radar cloud status --context my-cluster
radar cloud status --context my-cluster --namespace radar --release radar
The command reports installation ownership, chart and image, agent readiness,
and Cloud configuration without printing the connection token. Passing both
--namespace and --release selects an exact installation. Live tunnel status
is reported by Radar Cloud using the token in the referenced Kubernetes Secret.
If the Secret or Hub is unavailable, local installation diagnostics still run.
Interactive terminals use restrained status colors; set NO_COLOR (or pipe the
output) for plain text. URLs, tokens, and suggested commands remain unstyled.
CLI Flags
The table below covers common startup flags. See the full CLI reference; radar --help is authoritative for the installed version.
See Configuration Guide for details on cluster connection precedence, multiple kubeconfig files, and context switching.
The default deadlines (30 s context switch, 5 m first-paint backstop, 5 s namespace LIST, 20 scope candidates) are tuned for healthy clusters reached over fast, low-latency connections. They are too tight for clusters reached over SSH tunnels, geographically distant control planes, or accounts subject to API-server throttling, where they surface as one of three symptoms:
Widen the four flags via CLI or via the matching environment variables
(RADAR_CONTEXT_SWITCH_TIMEOUT, RADAR_FIRST_PAINT_BACKSTOP,
RADAR_NAMESPACE_LIST_TIMEOUT, RADAR_MAX_SCOPE_CANDIDATES) — env vars
keep secrets out of ps and let in-cluster deployments source the values
from a ConfigMap:
# CLI
kubectl radar \
--context-switch-timeout=120s \
--first-paint-backstop=10m \
--namespace-list-timeout=30s \
--max-scope-candidates=200
# Environment (e.g. in a Deployment manifest)
RADAR_CONTEXT_SWITCH_TIMEOUT=120s \
RADAR_FIRST_PAINT_BACKSTOP=10m \
RADAR_NAMESPACE_LIST_TIMEOUT=30s \
RADAR_MAX_SCOPE_CANDIDATES=200 \
kubectl radar
Defaults are preserved when neither the flag nor the env var is set, so existing deployments are unaffected.
Interactive graph showing how your Kubernetes resources are connected in real-time.
Table-based resource browser with smart columns per resource kind.
Inspect container image filesystems directly from the Pod view — no need to pull images locally or exec into containers.
Unified timeline of Kubernetes events and resource changes.
Manage Helm releases deployed in your cluster — inspect values and rendered manifests, diff revisions, identify failed upgrades and rollback-after-failure patterns, diagnose failed hooks, upgrade, rollback, and uninstall. Radar tracks available chart upgrades (from your configured repos or your own OCI registries) and lets you pick a specific target version. See Helm Support for the detailed behavior and limits.
Diff any two Kubernetes resources of the same kind side-by-side — like comparing a staging Deployment to its production sibling, or two pods that should be identical but aren't.
Compare button in the resource detail drawer, or compare mode in the resource table (toggle, pick two rows, hit Compare)status fields to focus on intent rather than observed statemanagedFields, resourceVersion, kubectl.kubernetes.io/last-applied-configuration) is stripped automatically so the diff stays signal — flip Raw metadata on if you actually want to see it/compare?kind=&apiGroup=&a=ns/name&b=ns/nameView TLS certificate details and expiry dates across all namespaces — catch expiring certificates before they cause outages.
Monitor, diagnose, and manage FluxCD and ArgoCD resources in one place.
Application, ApplicationSet, AppProject) and FluxCD (GitRepository, OCIRepository, HelmRepository, Bucket, Kustomization, HelmRelease, Alert)Terminating chip replaces stale Sync/Health badges; severity ramps with deletion age; mutating ops refuse on zombiesManaged by chip in resource drawers, GitOps routing from Topology + Timeline + Helm view, Consumed by panel on Flux source CRsmanage_gitops exposes sync / suspend / resume / reconcile / rollback with lifecycle-aware refusalSee the GitOps guide for the full feature matrix, RBAC requirements, demo cluster, and single-cluster scope notes.
Visualize live network traffic between services using Hubble, Caretta, Istio, or Beyla.
network feature enabled, and per-port edges additionally need dst.port and transport named in attributes.select — both are off by default, and Radar says so in the Traffic view rather than showing partial edges silently/, a node's details, or Live traffic on its page once a traffic source is detected) to see only it and what it talks to; the focus is in the URL, so it can be sharedOpen a Deployment, StatefulSet or DaemonSet's Metrics tab to investigate request rate, HTTP errors, latency, CPU, memory and throttling. Radar reads an existing Prometheus-compatible backend; resource charts do not require HTTP instrumentation, and request charts use supported Beyla or Istio observations.
See Workload metrics for screenshots, prerequisites, supported configurations and local multi-cluster setup limitations.
Read-only diagnosis for Karpenter-managed fleets — why is my pod pending, which NodePool could take it, why aren't my nodes joining, what is disruption doing to my fleet? Appears automatically when Karpenter NodePools are detected (RBAC-gated).
= ≥ ≤ ?) — unavailable is never rendered as zero, partial is never rendered as exactSee docs/capacity.md for the full reference.
Track Kubernetes spending from OpenCost metrics in a PromQL-compatible backend or a Kubecost 3 Aggregator. Auto mode keeps working Prometheus cost metrics, then discovers a local Kubecost Aggregator; a federated agent-only cluster can use its central Aggregator URL in Settings, config, or Helm. Radar reads the configured currency from a running OpenCost or Kubecost workload when available and otherwise uses USD. Source changes are tested and applied separately from the display-currency preference, which can be saved even when a source is unavailable. Radar labels values but does not convert them.
Proactive best-practices scanner with 44 checks across security, reliability, and efficiency — inspired by Polaris, Kubescape, Trivy, and NSA/CISA guidelines. Runs instantly against cached data with zero cluster-side installation.
latest, single-replica deployments, missing PDB/topology spread, pod HA risk (all replicas on same node), orphan services/ingresses, deprecated API versionsradarhq.io/ignore-checks annotation (comma-separated check IDs) — set on the resource a finding is attributed to, so the exclusion travels with the manifest instead of living in one operator's local settingsget_cluster_audit) for AI-assisted cluster analysisHop-ordered diagnosis for Service, Ingress, HTTPRoute, GRPCRoute, and Gateway - answering "if traffic is sent toward this resource, does it reach a healthy process, and if not which hop breaks first?"
get services/proxy, get pods/proxy); in-cluster mode goes directly to the data path.diagnose tool for AI consumers) - see docs/reachability.mdOpen Checks → Upgrade impact before upgrading the control plane. Radar compares the current cluster with a target Kubernetes minor and orders evidenced compatibility, health, admission, drain, runtime, and configuration checks by required action. Release-specific checks appear only when their Kubernetes minor lies in the selected upgrade path; the current catalog is reviewed through Kubernetes 1.37.
gitRepo volume driver disabled in Kubernetes 1.36, and removed or locked Kubernetes 1.37 feature gates or scheduling.k8s.io/v1alpha2 objectsexternalIPs remains reviewSee the Kubernetes upgrade impact guide for the check catalog, coverage semantics, and RBAC notes.
Inspect what any ServiceAccount can actually do — without three kubectl describe calls.
system:authenticated, system:serviceaccounts), and "Used by Pods" closing the loopcreate podssystem:authenticated, system:unauthenticated, system:masters)SelfSubjectRulesReview for the current user — for fast "why can't I do X" debuggingget_subject_permissions tool exposes the same data to AI agents for "is this SA over-privileged?" / "blast radius if compromised?" queriesRead-only visibility ships first; the considered follow-ups (RBAC audit checks, verb × resource matrix, subject explorer, graph view, in-UI edits, "can-i" queries) are tracked in #1090.
Radar includes a built-in Model Context Protocol (MCP) server that lets AI agents — Claude Code, Codex, Cursor, GitHub Copilot (VS Code and CLI), OpenCode, Google Antigravity, and any other MCP client — inspect, investigate, and operate your cluster through Radar.
Instead of raw kubectl output (verbose YAML that burns through LLM context windows), your AI gets pre-processed, token-optimized data: topology graphs, health assessments, deduplicated events, and filtered logs. Diagnosis is read-only by default; optional in-cluster route probing uses short-lived, self-deleting probe pods. Write operations such as restart, scale, apply, and rollback are identified for client confirmation and enforced through Kubernetes RBAC.
Enabled by default. Disable all MCP endpoints with --no-mcp, or expose only
read-only MCP tools with --mcp-read-only and connect to /mcp-readonly.
This setting does not restrict UI or REST API writes. See the
MCP Guide for setup and configuration precedence.
For shared in-cluster deployments, Radar supports optional user authentication with per-user Kubernetes RBAC.
No auth by default (local use). See the Authentication Guide for setup.
Radar auto-discovers any CRD in your cluster. Popular tools get dedicated integrations with topology edges, detail views, and AI summaries.
Default chart RBAC covers the built-in Kubernetes kinds listed below — Workloads, Networking (including NetworkPolicies and PodDisruptionBudgets), Configuration, Storage (PersistentVolumes, PersistentVolumeClaims, StorageClasses), HorizontalPodAutoscalers, ServiceAccounts, LimitRanges, ResourceQuotas, Nodes, Namespaces, and Events. On Kubernetes 1.37, Radar also surfaces the Workload, PodGroup, CompositePodGroup, PodCertificateRequest, and ClusterTrustBundle APIs when the API server advertises them; the scheduling APIs are feature-gated, while the certificate APIs are stable and enabled by default. These use the generic resource browser rather than dedicated renderers. RBAC objects (Roles, ClusterRoles, RoleBindings, ClusterRoleBindings) are opt-in via rbac.viewRBAC=true. CRD-based integrations (Gateway API, VerticalPodAutoscaler, Calico, ArgoCD, FluxCD, cert-manager, etc.) need both the CRD installed in your cluster and read access granted — most groups are default-on under rbac.crdGroups.<name> (e.g. gatewayApi, verticalPodAutoscaler, calico); check values.yaml or add custom rules via rbac.additionalRules.
Upgrade impact also gets list-only access to CSIStorageCapacities, FlowSchemas, PriorityLevelConfigurations, and PodSecurityPolicies on clusters where those kinds are served. These reads inspect source-manifest evidence and do not add the kinds to Radar's resource browser.
Topology: Pan (drag), Zoom (scroll), Select (click), Multi-select (Shift+click)
Radar reads your cluster through your own credentials and keeps cluster data local. It does not upload manifests, logs, events, metrics, or resource data to Skyhook, and it does not require an account, agent, or cloud backend. Found a vulnerability? Please report it privately to [email protected] — see SECURITY.md for the process and response timelines.
See the Development Guide for building from source and contributing. For automation and integrations, see the HTTP API reference.
Quick start:
git clone https://github.com/skyhook-io/radar.git
cd radar
make deps
# Terminal 1: Frontend with hot reload (port 9273)
make watch-frontend
# Terminal 2: Backend with hot reload (port 9280)
make watch-backend
Contributions are welcome! Please read our Contributing Guide for details on the development workflow, pull request process, and coding standards.
Questions or ideas? GitHub Discussions is the place — or come say hi at radarhq.io/community.
Radar is built and maintained by Skyhook (YC W23) and is open source under Apache-2.0. The OSS version is fully featured and the recommended way to run Radar.
For teams that want hosted multi-cluster Radar with SSO and shared dashboards, we also offer Radar Cloud.
Apache 2.0 — see LICENSE
