skyhook-io/radar

Radar

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.

Install and run in 30 seconds:

curl -fsSL https://get.radarhq.io | sh && kubectl radar

Why Radar?

• 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
• Private by design — your cluster data stays on your machine. No account, no agents, no cloud sync, no cluster telemetry
• Airgapped-friendly — runs as a single binary against the Kubernetes API and works in locked-down environments with outbound egress blocked
• Real-time — watches your cluster via informers, pushes updates to the browser via SSE
• Works everywhere — GKE, EKS, AKS, minikube, kind, k3s, or any conformant cluster
• AI-ready — built-in MCP server lets AI agents inspect, investigate, and operate your cluster through Radar
• In-cluster option — deploy with Helm for shared team access with RBAC-scoped permissions

"Have Radar deployed at work. As far as Kubernetes dashboards go, this is one of the best." — u/TheRealNetroxen

---

Installation

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.

kubectl krew install radar

scoop bucket add skyhook https://github.com/skyhook-io/scoop-bucket
scoop install radar

irm https://get.radarhq.io/install.ps1 | iex

brew install --cask skyhook-io/tap/radar-desktop

sudo apt install ./radar-desktop_*.deb

sudo rpm -i radar-desktop_*.rpm

scoop bucket add skyhook https://github.com/skyhook-io/scoop-bucket
scoop install radar-desktop

helm repo add skyhook https://skyhook-io.github.io/helm-charts
helm install radar skyhook/radar -n radar --create-namespace

---

Usage

# 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.

| Flag | Default | Description | |------|---------|-------------| | --kubeconfig | ~/.kube/config | Path to primary kubeconfig file | | --kubeconfig-dir | | Comma-separated directories containing additional 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. | | --base-path | | Serve Radar under a URL prefix such as /radar. Use when an ingress forwards a subpath without stripping it — everything, including /api/health, moves under the prefix. Not supported with --cloud-url. | | --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, sqlite, or postgres | | --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 (memory only) | | --disable-exec | false | Disable terminal and debug shell | | --disable-helm-write | false | Disable Helm write operations | | --disable-local-terminal | false | Disable the host local terminal | | --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 PromQL-compatible query URL, including Prometheus, VictoriaMetrics, Thanos, or Mimir (skips auto-discovery) | | --prometheus-single-cluster | false | Optional workload-metrics scope override: assert that the backend contains only this cluster. Replaces automatic identity matching; does not scope rightsizing or other metrics features. Scope and lifetime. | | --prometheus-cluster-label | (automatic matching) | Optional workload-metrics override for a shared backend, e.g. cluster=production (repeatable, ANDed). Alternative to --prometheus-single-cluster; leave both unset for automatic matching. Not persisted. | | --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). | | --beyla-job-selector | (empty) | Beyla Live Traffic matcher fragment (empty matches Beyla/Alloy jobs there). Workload charts use it only with an explicit scope override and accept one job equality or regex matcher. Automatic workload matching discovers custom jobs without it. Details. | | --opencost-currency | (auto-detect, then USD) | Override the ISO 4217 currency label for OpenCost values. Radar labels values but does not convert them. | | --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.

Tuning for slow or high-latency clusters

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:

• "Context switch timed out" toasts when the cache eventually does sync
• "Limited list — RBAC doesn't allow listing all namespaces" even though the

• Kinds silently marked denied because the namespace they live in fell past

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.

---

Views

Topology

Interactive graph showing how your Kubernetes resources are connected in real-time.

Topology View — Visualize resource relationships

• Two modes: Resources (full hierarchy) and Traffic (network flow path)
• Group by namespace, app label, or view ungrouped
• Filter by resource kind — click any node for full details
• Auto-layout powered by ELK.js, live updates via SSE

Resources

Table-based resource browser with smart columns per resource kind.

Resources View — Browse and filter all cluster resources

• Browse all resource types including CRDs
• Search by name, filter by status or problems (CrashLoopBackOff, ImagePullBackOff, etc.)
• Add custom columns from any label or annotation — sortable, filterable, and resizable
• Click any resource for YAML manifest, related resources, logs, and events
• Set regular or init-container images on Deployments, StatefulSets, DaemonSets, and Argo Rollouts, with live rollout progress in tables, drawers, workload views, and Applications

Image Filesystem Viewer

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

• Click any container image in a Pod to browse its complete filesystem
• Tree view with file sizes, permissions, and symlink targets
• Search files by name across the entire image
• Download individual files for inspection
• Works with public images (Docker Hub, Quay, GHCR) and private registries (GCR, ECR, ACR) using your cluster's ImagePullSecrets
• Disk-based layer caching for fast repeated access

Timeline

Unified timeline of Kubernetes events and resource changes.

Timeline View — Track cluster activity in real-time

• Filter by event type (all or warnings only)
• Resource change diffs showing what changed (replicas, images, etc.)
• Real-time updates as new events occur

Helm

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

• View all releases across namespaces with status, chart version, app version, resource health, storage namespace, and Flux ownership
• Inspect values, compare revisions across values/manifests/notes/resources, and view release history
• Surface failed upgrades, stuck pending operations, rollback history, and inferred atomic-style rollbacks
• Correlate failed/running hooks with remaining Job, Pod, Event, and redacted log evidence
• Upgrade, rollback, or uninstall releases directly from the UI

Compare Resources

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

• Two entry points: a Compare button in the resource detail drawer, or compare mode in the resource table (toggle, pick two rows, hit Compare)
• Side-by-side or unified view, with one-click swap of A ↔ B
• Diff-only mode collapses unchanged regions so you only see what differs
• Spec-only mode drops status fields to focus on intent rather than observed state
• Server-assigned noise (managedFields, 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
• Same-namespace candidates are surfaced first in the picker — usually the resource you want to compare against
• Shareable URLs: /compare?kind=&apiGroup=&a=ns/name&b=ns/name

Compare mode in the resource table — pick two rows, hit Compare

TLS Certificate Management

View TLS certificate details and expiry dates across all namespaces — catch expiring certificates before they cause outages.

• Parses TLS secrets to show certificate subject, issuer, and validity period
• Dashboard-level certificate expiry overview
• Available from the resource detail view for any TLS-type Secret

GitOps

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

• Fleet view + per-app detail page (Topology / Changes / Activity tabs) for ArgoCD (Application, ApplicationSet, AppProject) and FluxCD (GitRepository, OCIRepository, HelmRepository, Bucket, Kustomization, HelmRelease, Alert)
• Diagnosis pipeline — field-level drift, recent events per resource, stuck-drift-loop detection, parsed operation-failures, structured one-click remediation
• Lifecycle awareness — Terminating chip replaces stale Sync/Health badges; severity ramps with deletion age; mutating ops refuse on zombies
• Cross-linked from the rest of Radar — Managed by chip in resource drawers, GitOps routing from Topology + Timeline + Helm view, Consumed by panel on Flux source CRs
• MCP integration — manage_gitops exposes sync / suspend / resume / reconcile / rollback with lifecycle-aware refusal

Traffic

Visualize live network traffic between services using Hubble, Caretta, Istio, or Beyla.

Traffic View — See how services communicate in real-time

• Auto-detects Hubble (Cilium), Istio, Caretta, or Grafana Beyla as traffic data sources
• Beyla (standalone or via Grafana Alloy) provides eBPF L4 + HTTP visibility with no service mesh, read from Prometheus
• Beyla needs its 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
• Animated flow graph showing requests per second between services
• Filter by namespace, protocol, or status code
• Setup wizard to install a traffic source if none is detected

Workload Metrics

Open 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.

• Workload history includes previous replicas when metrics and ownership are retained
• Compare current Pods to find resource outliers
• Automatic discovery and identity checks, with missing or partial data labeled explicitly

Capacity (Karpenter)

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).

• Overview — fleet KPIs with claim lifecycle detail, a cluster scheduling-capacity bar (requests vs allocatable, in-flight beyond the edge, pending demand as an honest not-to-scale count), prioritized operational signals, and the NodePool inventory
• NodePool detail — the capacity ledger (configured limit, provisioned, headroom, allocatable, scheduled requests, unallocated, actual usage), claim lifecycle, fleet composition, and workload attribution
• Demand — pending pods grouped by scheduling signature, each group evaluated against every NodePool's declared constraints with per-predicate evidence; filterable by state, pool, and workload
• Activity — provisioning / disruption / interruption episodes classified from Karpenter's exact event vocabulary, with per-evidence confidence
• Every quantity carries per-value certainty (= ≥ ≤ ?) — unavailable is never rendered as zero, partial is never rendered as exact
• Issues, Pending-pod drawers, and the Home posture card deep-link into the right diagnosis

Cost Insights

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 Setting