Comparison

Radar vs Headlamp

Headlamp is an actively maintained, SIG-governed foundation for Kubernetes resource management and custom plugins. Radar takes a newer, more opinionated approach: one integrated operational product for desktop, local, in-cluster, Cloud, and AI-assisted work.

Reviewed by Nadav Erell, Skyhook CEO and former Google engineer with a decade of experience across GKE and cloud infrastructure. Checked against Headlamp v0.44.0, its documentation, and the kubernetes-sigs/headlamp and headlamp-k8s/plugins repositories on August 4, 2026. We build Radar, so treat this as a sourced vendor comparison, not an independent review. Found a mistake? Email us and we'll fix it.

TL;DR

Same license. Both Apache 2.0. Headlamp wins on vendor-neutral governance (kubernetes-sigs, CNCF Sandbox); Radar OSS has a public no-relicense pledge.
Different integration model. Headlamp provides a plugin SDK for arbitrary additions. Radar ships typed integrations together so they contribute to one operational model.
Radar is smaller, faster, and scales better. Its packaged desktop app is about half the size of a Headlamp install, and the single native binary - same engine, same full UI - is about a quarter. More importantly, Radar does the heavy cluster-state work in Go; Headlamp puts more watch, state, rendering, and plugin work into the browser.
Different depth. Headlamp covers Kubernetes resource management well. Radar adds Issues, retained event and resource-change evidence, live traffic with mTLS, GitOps, Helm, audit, integrations, and MCP in core. Fleet views aggregate current operational data; topology and timeline remain per-cluster.
Pick Radar for integrated operational depth. Pick Headlamp if vendor-neutral kubernetes-sigs governance or hosting a custom plugin is the non-negotiable requirement.

Feature by feature

How do Radar and Headlamp compare?

Unmarked Radar checks ship in OSS (Apache 2.0) and Cloud. 'Cloud' tags are hosted-only.

Radar and Headlamp feature comparison
Feature	Radar OSS (Apache 2.0) + Cloud	Headlamp kubernetes-sigs · CNCF Sandbox
Project & licensing
License	Apache 2.0	Apache 2.0
Governance Headlamp is a kubernetes-sigs sub-project, accepted to CNCF at Sandbox - the earliest maturity tier - in May 2023. Vendor-neutral governance means the project outlives any one company; it does not mean anyone is accountable for your outcome, and there is no support commitment behind it. Radar is built and maintained by Skyhook (commercial OSS) under a public no-relicense pledge. CNCF project listing	Skyhook (commercial OSS)	Strong: kubernetes-sigs · CNCF Sandbox tier
Pricing	OSS free, Cloud per cluster	Strong: Free
Architecture
Extension model Headlamp can host arbitrary UI plugins, but enabled plugins are separately versioned JavaScript bundles fetched and executed at startup in the same browser or Electron renderer. Shared libraries keep many bundles small; each plugin still adds client-side code, requests, rendering work, and compatibility surface. Radar compiles supported integrations into one tested release and one shared operational model. Headlamp plugin model Headlamp plugin execution	Typed integrations · one release	JavaScript plugins · main UI renderer
Desktop runtime Headlamp has a Go backend, but its desktop app packages the React UI with Electron, Chromium, and Node. Radar uses its compiled Go engine with the operating system webview instead of shipping a separate browser runtime. Headlamp architecture Radar install docs	Strong: Go engine + system webview	Go backend + Electron desktop
Current macOS footprint Approximate installed size on Apple Silicon. Radar delivers the same engine and full UI as either a single native binary that opens in your browser or a packaged desktop app. Checked August 4, 2026 against Radar v1.8.7 and Headlamp v0.44.0. Radar v1.8.7 Headlamp v0.44.0	Strong: ~100 MB native binary · ~200 MB desktop	~400 MB desktop
Delivery modes Both can run as desktop apps or in-cluster web UIs. Radar also runs locally as a CLI or kubectl plugin that opens the same browser interface. Radar install docs Headlamp architecture	Desktop · local browser · in-cluster · Cloud	Desktop · in-cluster web app
Large-cluster data path Radar's Go engine keeps shared informer caches, parallelizes independent work, and sends deltas to the browser over SSE, while Headlamp does more in the browser - watch processing, client-side state, filtering, sorting, graph rendering, and plugin execution share the JavaScript renderer. Radar topology architecture	Strong: Server-side informers · SSE deltas	Partial: Browser watches, state, rendering + plugins
Hosted SaaS option	Strong: Cloud	No
Multi-cluster
Clusters in one view Radar Cloud aggregates Issues, search, checks, applications, GitOps, and package drift across connected clusters. Topology and timeline remain per-cluster. Headlamp can connect to multiple clusters and compare selected resources. Radar fleet scope Headlamp architecture	Strong: Cloud scoped fleet views	Partial: Dropdown + side-by-side compare
Cross-cluster resource search	Strong: Cloud	Partial: Per cluster
Package and application version skew Radar Cloud compares installed package versions and application versions across selected clusters. It does not provide an arbitrary field-by-field diff of whole environments. Radar fleet views	Strong: Cloud	No
History & incidents
Retained event and resource-change history Cluster events and resource changes the product itself retains for look-back - not live API state, not your monitoring stack's storage, and not a log of user actions in the product. Radar timeline	Strong: Memory · SQLite · Cloud up to 1 year	None (live state only)
Resource-change diffs	Strong: Timeline + manifest history	No
Audit log retention A record of who did what in the product, distinct from the cluster event timeline. Radar Cloud retention is 7 days on Free, 30 days on Team, and 365 days on Enterprise. Radar audit log	Strong: Cloud · 7 / 30 / 365 days	No
GitOps correlation (Argo CD + Flux) Generic CRD access is useful; typed sync status, drift, ownership, activity, and actions wired into the rest of the product is a deeper integration. Radar GitOps Headlamp plugins	Strong: Argo CD + Flux, in core	Partial: Separate Argo CD + Flux plugins
Auth
Organization SSO Both support OIDC, and neither in-cluster Radar OSS nor Headlamp configures it for you. Radar Cloud adds centrally managed SSO including SAML. Headlamp documents OIDC, basic auth, identity-aware proxy, and TLS - no SAML. Headlamp OIDC	Strong: In-cluster OIDC · Cloud SAML/OIDC	Partial: OIDC only · self-configured
SCIM provisioning	Partial: Enterprise	No
Inherits Kubernetes RBAC	Yes	Yes
Feature surface
Resource browsing + RBAC viewer	Yes	Yes
Logs, exec, terminal	Yes	Yes
Live workload-to-workload traffic + mTLS Radar traffic	Yes	No
Topology graph Radar topology	Strong: Live workload graph	Partial: Resource map
Image filesystem viewer	Yes	No
Cost insights (OpenCost) Both require OpenCost installed in the cluster. Radar auto-detects it and renders cost against workloads. Headlamp's flow is install + configure the OpenCost plugin separately.	Strong: Auto-detected	Partial: OpenCost plugin
Cluster security audit (Trivy / Kyverno) Configuration, reliability, and security findings surfaced on the affected resources - and whether that ships with the product or arrives as a separately installed, separately licensed scanner. Headlamp covers this through two separate plugin installs: an official Kyverno plugin (v0.1.0) with a policy dashboard, violations view, and compliance scoring, plus a third-party Trivy plugin from kubebeam. Neither is in the product by default, and there is no unified findings view across the two. Radar cluster audit Headlamp Kyverno plugin Trivy plugin (kubebeam)	Yes	Partial: Official Kyverno + third-party Trivy plugins
MCP for external AI agents What an external agent actually gets from the endpoint: a wrapper over the raw Kubernetes API, or operational context already correlated for agent use. Benchmarked against raw kubectl on 54 live-cluster faults, Radar's MCP server was more accurate and reached a correct diagnosis about four times sooner. Radar is an MCP server for external agents and exposes that correlated model directly. Headlamp's AI Assistant is an in-app plugin that can consume MCP servers rather than expose one. Radar MCP MCP vs kubectl benchmark	Strong: Correlated read + write tools · 4x sooner to a correct diagnosis than kubectl	Partial: AI Assistant client plugin
Karpenter / KEDA / cert-manager / Kyverno / OpenCost / Trivy All are cluster operators you install yourself. The question is what the UI does once they're there. Radar detects each and renders integrated views. Headlamp ships per-tool plugins from headlamp-k8s/plugins that you install separately.	Strong: Auto-detected, no plugin install	Partial: Plugin per integration
Collaboration
Slack and webhook alerts	Strong: Cloud	No
Resource annotations visible to teammates	Strong: Cloud	No
Webhooks	Strong: Cloud	No
Free for unlimited teammates	Yes	Strong: Yes - it's the whole tool
Compliance
SOC 2 Type 2 (hosted)	Strong: Cloud	Strong: N/A - self-host
Self-host / on-prem	Strong: OSS · Cloud Enterprise	Strong: Helm chart

Project & licensing

License

Radar: Apache 2.0
Headlamp: Apache 2.0

Governance

Headlamp is a kubernetes-sigs sub-project, accepted to CNCF at Sandbox - the earliest maturity tier - in May 2023. Vendor-neutral governance means the project outlives any one company; it does not mean anyone is accountable for your outcome, and there is no support commitment behind it. Radar is built and maintained by Skyhook (commercial OSS) under a public no-relicense pledge.

CNCF project listing

Radar: Skyhook (commercial OSS)
Headlamp: Strong: kubernetes-sigs · CNCF Sandbox tier

Pricing

Radar: OSS free, Cloud per cluster
Headlamp: Strong: Free

Architecture

Extension model

Headlamp can host arbitrary UI plugins, but enabled plugins are separately versioned JavaScript bundles fetched and executed at startup in the same browser or Electron renderer. Shared libraries keep many bundles small; each plugin still adds client-side code, requests, rendering work, and compatibility surface. Radar compiles supported integrations into one tested release and one shared operational model.

Headlamp plugin model Headlamp plugin execution

Radar: Typed integrations · one release
Headlamp: JavaScript plugins · main UI renderer

Desktop runtime

Headlamp has a Go backend, but its desktop app packages the React UI with Electron, Chromium, and Node. Radar uses its compiled Go engine with the operating system webview instead of shipping a separate browser runtime.

Headlamp architecture Radar install docs

Radar: Strong: Go engine + system webview
Headlamp: Go backend + Electron desktop

Current macOS footprint

Approximate installed size on Apple Silicon. Radar delivers the same engine and full UI as either a single native binary that opens in your browser or a packaged desktop app. Checked August 4, 2026 against Radar v1.8.7 and Headlamp v0.44.0.

Radar v1.8.7 Headlamp v0.44.0

Radar: Strong: ~100 MB native binary · ~200 MB desktop
Headlamp: ~400 MB desktop

Delivery modes

Both can run as desktop apps or in-cluster web UIs. Radar also runs locally as a CLI or kubectl plugin that opens the same browser interface.

Radar install docs Headlamp architecture

Radar: Desktop · local browser · in-cluster · Cloud
Headlamp: Desktop · in-cluster web app

Large-cluster data path

Radar's Go engine keeps shared informer caches, parallelizes independent work, and sends deltas to the browser over SSE, while Headlamp does more in the browser - watch processing, client-side state, filtering, sorting, graph rendering, and plugin execution share the JavaScript renderer.

Radar topology architecture

Radar: Strong: Server-side informers · SSE deltas
Headlamp: Partial: Browser watches, state, rendering + plugins

Hosted SaaS option

Radar: Strong: Cloud
Headlamp: No

Multi-cluster

Clusters in one view

Radar Cloud aggregates Issues, search, checks, applications, GitOps, and package drift across connected clusters. Topology and timeline remain per-cluster. Headlamp can connect to multiple clusters and compare selected resources.

Radar fleet scope Headlamp architecture

Radar: Strong: Cloud scoped fleet views
Headlamp: Partial: Dropdown + side-by-side compare

Cross-cluster resource search

Radar: Strong: Cloud
Headlamp: Partial: Per cluster

Package and application version skew

Radar Cloud compares installed package versions and application versions across selected clusters. It does not provide an arbitrary field-by-field diff of whole environments.

Radar fleet views

Radar: Strong: Cloud
Headlamp: No

History & incidents

Retained event and resource-change history

Cluster events and resource changes the product itself retains for look-back - not live API state, not your monitoring stack's storage, and not a log of user actions in the product.

Radar timeline

Radar: Strong: Memory · SQLite · Cloud up to 1 year
Headlamp: None (live state only)

Resource-change diffs

Radar: Strong: Timeline + manifest history
Headlamp: No

Audit log retention

A record of who did what in the product, distinct from the cluster event timeline. Radar Cloud retention is 7 days on Free, 30 days on Team, and 365 days on Enterprise.

Radar audit log

Radar: Strong: Cloud · 7 / 30 / 365 days
Headlamp: No

GitOps correlation (Argo CD + Flux)

Generic CRD access is useful; typed sync status, drift, ownership, activity, and actions wired into the rest of the product is a deeper integration.

Radar GitOps Headlamp plugins

Radar: Strong: Argo CD + Flux, in core
Headlamp: Partial: Separate Argo CD + Flux plugins

Auth

Organization SSO

Both support OIDC, and neither in-cluster Radar OSS nor Headlamp configures it for you. Radar Cloud adds centrally managed SSO including SAML. Headlamp documents OIDC, basic auth, identity-aware proxy, and TLS - no SAML.

Headlamp OIDC

Radar: Strong: In-cluster OIDC · Cloud SAML/OIDC
Headlamp: Partial: OIDC only · self-configured

SCIM provisioning

Radar: Partial: Enterprise
Headlamp: No

Inherits Kubernetes RBAC

Radar: Yes
Headlamp: Yes

Feature surface

Resource browsing + RBAC viewer

Radar: Yes
Headlamp: Yes

Logs, exec, terminal

Radar: Yes
Headlamp: Yes

Live workload-to-workload traffic + mTLS

Radar traffic

Radar: Yes
Headlamp: No

Topology graph

Radar topology

Radar: Strong: Live workload graph
Headlamp: Partial: Resource map

Image filesystem viewer

Radar: Yes
Headlamp: No

Cost insights (OpenCost)

Both require OpenCost installed in the cluster. Radar auto-detects it and renders cost against workloads. Headlamp's flow is install + configure the OpenCost plugin separately.

Radar: Strong: Auto-detected
Headlamp: Partial: OpenCost plugin

Cluster security audit (Trivy / Kyverno)

Configuration, reliability, and security findings surfaced on the affected resources - and whether that ships with the product or arrives as a separately installed, separately licensed scanner. Headlamp covers this through two separate plugin installs: an official Kyverno plugin (v0.1.0) with a policy dashboard, violations view, and compliance scoring, plus a third-party Trivy plugin from kubebeam. Neither is in the product by default, and there is no unified findings view across the two.

Radar cluster audit Headlamp Kyverno plugin Trivy plugin (kubebeam)

Radar: Yes
Headlamp: Partial: Official Kyverno + third-party Trivy plugins

MCP for external AI agents

What an external agent actually gets from the endpoint: a wrapper over the raw Kubernetes API, or operational context already correlated for agent use. Benchmarked against raw kubectl on 54 live-cluster faults, Radar's MCP server was more accurate and reached a correct diagnosis about four times sooner. Radar is an MCP server for external agents and exposes that correlated model directly. Headlamp's AI Assistant is an in-app plugin that can consume MCP servers rather than expose one.

Radar MCP MCP vs kubectl benchmark

Radar: Strong: Correlated read + write tools · 4x sooner to a correct diagnosis than kubectl
Headlamp: Partial: AI Assistant client plugin

Karpenter / KEDA / cert-manager / Kyverno / OpenCost / Trivy

All are cluster operators you install yourself. The question is what the UI does once they're there. Radar detects each and renders integrated views. Headlamp ships per-tool plugins from headlamp-k8s/plugins that you install separately.

Radar: Strong: Auto-detected, no plugin install
Headlamp: Partial: Plugin per integration

Collaboration

Slack and webhook alerts

Radar: Strong: Cloud
Headlamp: No

Resource annotations visible to teammates

Radar: Strong: Cloud
Headlamp: No

Webhooks

Radar: Strong: Cloud
Headlamp: No

Free for unlimited teammates

Radar: Yes
Headlamp: Strong: Yes - it's the whole tool

Compliance

SOC 2 Type 2 (hosted)

Radar: Strong: Cloud
Headlamp: Strong: N/A - self-host

Self-host / on-prem

Radar: Strong: OSS · Cloud Enterprise
Headlamp: Strong: Helm chart

Same Apache 2.0 license. Why not just write a Headlamp plugin?

A plugin is useful when you need an arbitrary custom surface. Radar makes a different product tradeoff for supported ecosystems: typed integrations ship together and feed the same Issues, topology, timeline, resource drawers, actions, and MCP tools. That shared context is the advantage, not the absence of a plugin API by itself.

Does Radar have a desktop app like Headlamp?

Yes. Radar ships a native, lightweight desktop app for macOS, Linux, and Windows using the operating system webview around its compiled Go core. The same engine also runs as a CLI or kubectl plugin that opens a local browser UI, or in-cluster for shared access.

How do Radar and Headlamp perform on large clusters?

Radar is faster and scales better. Its Go engine maintains shared Kubernetes informer caches, parallelizes independent work, and streams deltas to the UI, so the browser mostly renders. Headlamp puts more watch processing, client-side state, filtering, sorting, graph rendering, and plugin execution in the browser's JavaScript renderer. That difference grows with cluster size.

Headlamp has Argo CD and Flux plugins. What does Radar add?

Headlamp offers separate plugins for Argo CD and Flux. Radar supports both out of the box and connects their sync state, ownership, changes, and actions to the resources they manage, the timeline, topology, Issues, and MCP.

Headlamp has an AI Assistant. Is that the same as Radar's MCP support?

Different shapes. Headlamp's AI Assistant is an in-app chat panel that can also act as an MCP client. Radar exposes the cluster as an MCP endpoint - your existing Claude / Cursor / Copilot queries it directly with no in-app chat UI.

Is Headlamp actively maintained?

Yes. Headlamp is actively maintained under kubernetes-sigs governance. Its pre-1.0 versioning is not by itself a maintenance warning; use the current repository and release history when evaluating cadence.

More comparisons

Radar vs Lens

vs the Electron desktop IDE

Kubernetes Dashboard alternative

Headlamp is where SIG UI pointed Dashboard users

Lens alternatives

All six options, Headlamp among them

Try Radar in the shape that fits.

Start on your laptop with no cluster footprint, or deploy the same interface for your team.

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

Other install methods (Krew, Scoop, .rpm, direct download) →

or try Radar Cloud free →Star on GitHub →

Apache 2.0 · No account for local use · Run Radar OSS forever