winget install --id=skyhook-io.Radar -e Make sense of a live Kubernetes cluster - topology, events, Helm, GitOps, image internals, audits - over two surfaces: a UI optimized for humans, and an MCP server optimized for AI agents. Open source, on your laptop or in your cluster.
The missing open-source Kubernetes UI. Single binary. No account required. Free forever.
🌐 radarhq.io · Docs · Releases
Topology, resources, Helm, GitOps, traffic, audit, and MCP context for AI agents — from your laptop or in-cluster.
Table of contents
Install and run in 30 seconds:
curl -fsSL https://get.radarhq.io | sh && kubectl radar
> "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 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.
More install options — Desktop App (macOS/Linux/Windows), Krew, Scoop, In-Cluster Helm
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
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 ingress, 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
| Flag | Default | Description |
|---|---|---|
--kubeconfig | ~/.kube/config | Path to kubeconfig file |
--kubeconfig-dir | Comma-separated directories containing kubeconfig files | |
--namespace | (all) | Initial namespace filter (supports multi-select in the UI; also used as RBAC fallback for namespace-scoped users) |
--namespaces | (all) | Initial namespace filters as a comma-separated list, e.g. --namespaces ns1,ns2,ns3. Use this when your identity can list resources in specific namespaces but cannot list namespaces cluster-wide. |
--namespace-scope | false | Pin namespaced informer caches to a single namespace for large clusters (scoping to multiple namespaces is not supported yet). Requires --namespace, a kubeconfig context namespace, or a saved local single-namespace pick. Local mode can rebuild the cache when switching namespaces; auth/cloud mode locks the shared cache to the startup namespace. |
--port | 9280 | Server port |
--listen-address | 127.0.0.1 | HTTP listen address. Use 127.0.0.1 or localhost for local-only access; use 0.0.0.0 explicitly for containers, VMs, WSL, or remote/shared access, together with authentication and network controls. |
--no-browser | false | Don't auto-open browser |
--browser | Browser to use when opening the UI, e.g. firefox, google-chrome, or Google Chrome on macOS | |
--timeline-storage | memory | Timeline storage backend: memory or sqlite |
--timeline-db | ~/.radar/timeline.db | Path to SQLite database (when using sqlite storage) |
--timeline-max-size | 1Gi | Maximum SQLite DB + WAL size before pruning oldest events (e.g. 800Mi, 8Gi; 0 disables) |
--history-limit | 10000 | Maximum events to retain in timeline |
--disable-exec | false | Disable terminal and debug shell |
--disable-helm-write | false | Disable Helm write operations |
--disable-local-terminal | false | Disable local terminal feature |
--debug-image | busybox:latest | Image for ephemeral debug containers and node debug pods. If built-in restricted PodSecurity rejects the default pod debug container, Radar retries with a restricted-compatible Linux security context using the target/pod non-root UID, or UID 65532 by default; point at a compatible mirror for air-gapped / private-registry clusters. |
--list-page-size | 0 (off) | Paginate the initial LIST of high-cardinality kinds (Pods, ReplicaSets) at this size. Helps very large clusters that fail to sync; only used when WatchList streaming is unavailable. Try 2000. |
--context-switch-timeout | 30s | Maximum time a kubeconfig context switch may take. Widen on high-latency control planes — see Tuning for slow clusters. Env: RADAR_CONTEXT_SWITCH_TIMEOUT. |
--first-paint-backstop | 5m | Hard upper bound on the initial critical-cache sync wait before Radar falls through to a partial-data render. Env: RADAR_FIRST_PAINT_BACKSTOP. |
--namespace-list-timeout | 5s | Timeout for the cluster-wide namespace LIST used to decide if the user is RBAC-namespace-restricted. A timeout on a slow control plane is misreported in the UI as "Limited list — RBAC". Env: RADAR_NAMESPACE_LIST_TIMEOUT. |
--max-scope-candidates | 20 | Cap on the namespace-fallback probe fanout (used by accounts that can list namespaces cluster-wide but not list a specific kind cluster-wide). Raise above 20 for clusters with more than 20 namespaces. Env: RADAR_MAX_SCOPE_CANDIDATES. |
--prometheus-url | (auto-discover) | Manual Prometheus/VictoriaMetrics URL (skips auto-discovery) |
--prometheus-header | HTTP header sent with every Prometheus request, format Key=Value (repeatable). Required for auth-protected backends. | |
--prometheus-header-from-env | HTTP header sent with every Prometheus request, sourced from an environment variable, format Key=ENV_VAR (repeatable). | |
--auth-mode | none | Authentication mode: none, proxy, or oidc (details) |
--no-mcp | false | Disable MCP server for AI tool integration |
--mcp-catalog-stdio | false | Start only the MCP catalog over stdio for registry introspection |
--version | Show version and exit |
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.
Topology View — Visualize resource relationships
Table-based resource browser with smart columns per resource kind.
Resources View — Browse and filter all cluster resources
Inspect container image filesystems directly from the Pod view — no need to pull images locally or exec into containers.
Image Filesystem Viewer — Browse container image contents
Unified timeline of Kubernetes events and resource changes.
Timeline View — Track cluster activity in real-time
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.
Helm View — Manage your Helm deployments
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 View — Side-by-side YAML diff with field-level highlighting
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/name
Compare mode in the resource table — pick two rows, hit Compare
View TLS certificate details and expiry dates across all namespaces — catch expiring certificates before they cause outages.
Monitor, diagnose, and manage FluxCD and ArgoCD resources from a dedicated GitOps workspace.
GitOps fleet view — Argo + Flux applications side-by-side with sync, health, source, destination, and lifecycle state
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 or Caretta.
Traffic View — See how services communicate in real-time
Track Kubernetes spending with OpenCost integration — no additional configuration needed.
Proactive best-practices scanner with 31 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 versionsget_cluster_audit) for AI-assisted cluster analysisInspect 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, Cursor, Copilot, and others — query 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. Read tools are strictly read-only; write tools (restart, scale, sync, and the like) carry explicit destructive-action hints and run under your cluster's RBAC, so the apiserver enforces what each identity is allowed to do.
Enabled by default. Disable with --no-mcp. See the MCP Guide for setup instructions.
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. RBAC objects (Roles, ClusterRoles, RoleBindings, ClusterRoleBindings) are opt-in via rbac.viewRBAC=true. CRD-based integrations (Gateway API, VerticalPodAutoscaler, 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. (e.g. gatewayApi, verticalPodAutoscaler); check values.yaml or add custom rules via rbac.additionalRules.
| Category | Resources |
|---|---|
| Workloads | Deployments, DaemonSets, StatefulSets, ReplicaSets, Pods, Jobs, CronJobs |
| Networking | Services, Ingresses, NetworkPolicies, Endpoints, EndpointSlices, PodDisruptionBudgets |
| Configuration | ConfigMaps, Secrets (names only, values hidden), LimitRanges, ResourceQuotas |
| Storage | PersistentVolumeClaims, PersistentVolumes, StorageClasses |
| Autoscaling | HorizontalPodAutoscalers, VerticalPodAutoscalers |
| Cluster | Nodes, Namespaces, ServiceAccounts, Events |
| GitOps (FluxCD) | GitRepository, OCIRepository, HelmRepository, Kustomization, HelmRelease, Alert |
| GitOps (ArgoCD) | Application, ApplicationSet, AppProject |
| Argo Rollouts | Rollout |
| Argo Workflows | Workflow, WorkflowTemplate |
| cert-manager | Certificate, CertificateRequest, Order, Challenge, Issuer, ClusterIssuer |
| Gateway API | Gateway, GatewayClass, HTTPRoute, GRPCRoute, TCPRoute, TLSRoute |
| Istio | VirtualService, DestinationRule, Gateway, ServiceEntry, PeerAuthentication, AuthorizationPolicy |
| Traefik | IngressRoute, IngressRouteTCP, IngressRouteUDP, Middleware, MiddlewareTCP, TraefikService, ServersTransport, ServersTransportTCP, TLSOption, TLSStore |
| Contour | HTTPProxy |
| Knative Serving | Service, Configuration, Revision, Route, DomainMapping |
| Knative Eventing | Broker, Trigger, EventType, Channel, InMemoryChannel, Subscription |
| Knative Sources | PingSource, ApiServerSource, ContainerSource, SinkBinding |
| Knative Flows | Sequence, Parallel |
| Knative Networking | Ingress, Certificate, ServerlessService |
| Karpenter | NodePool, NodeClaim (+ provider-specific NodeClasses via auto-discovery) |
| KEDA | ScaledObject, ScaledJob, TriggerAuthentication, ClusterTriggerAuthentication |
| Prometheus Operator | ServiceMonitor, PodMonitor, PrometheusRule, Alertmanager |
| Security (Trivy) | VulnerabilityReport, ConfigAuditReport, ExposedSecretReport, ClusterComplianceReport, SbomReport, RbacAssessmentReport, InfraAssessmentReport |
| Velero | Backup, Restore, Schedule, BackupStorageLocation, VolumeSnapshotLocation |
| External Secrets | ExternalSecret, ClusterExternalSecret, SecretStore, ClusterSecretStore |
| CloudNativePG | Cluster, Backup, ScheduledBackup, Pooler |
| Crossplane | Managed Resources (any provider), Composite Resources, Claims, Provider, ProviderConfig, Function, Configuration, Composition, CompositionRevision, XRD |
| Kyverno | Policy, ClusterPolicy, PolicyReport, ClusterPolicyReport |
| Sealed Secrets | SealedSecret |
| Dynamic Resource Allocation | ResourceClaim, ResourceClaimTemplate, DeviceClass, ResourceSlice (resource.k8s.io, K8s 1.32+) |
| NVIDIA GPU Operator | ClusterPolicy, NVIDIADriver |
| Cost (OpenCost) | Namespace/workload/node cost breakdown via Prometheus (no CRDs) |
| CRDs | Any Custom Resource Definition in your cluster (auto-discovered) |
| Shortcut | Action |
|---|---|
g then a letter | Switch view — g h Home, g r Resources, g i Issues, g t Topology, g a Applications, g l Timeline, g f Traffic, g m Helm, g o GitOps, g u Checks, g c Cost |
t | Toggle dark/light theme |
? | Show keyboard shortcuts |
⌘K | Open command palette |
/ | Focus search (context-aware) |
f | Fit topology to screen |
+ / - / 0 | Zoom in / out / reset (topology) |
j / k | Navigate rows (resources, helm) |
g g / G | Jump to first / last row |
Enter / d | Open selected resource detail |
y | Open YAML view |
l | Open logs (pods/workloads) |
[ / ] | Previous / next resource kind |
Escape | Close panel/modal/search |
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 security@skyhook.io — see SECURITY.md for the process and response timelines.
See the Development Guide for building from source, architecture details, API reference, and contributing.
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
Open source. Free forever.
Built by Skyhook