Radar vs Lens: hosted team visibility, or desktop IDE?
Lens is a mature Kubernetes desktop IDE with millions of users. Radar comes in two flavors — Apache 2.0 OSS you self-host, or Radar Cloud as a hosted SaaS for teams. Here's an honest line-by-line comparison — no trash talk, no false equivalence.
Helm chart in your cluster, browser UI out. Apache 2.0 for any use, commercial included. No account, no telemetry, no per-seat cost.
Same engine, hosted by us. Priced per cluster. SAML/SCIM, fleet view, year-long event retention, SOC 2.
Electron app, per-device install, Lens Pro priced per user. Reads kubeconfigs directly. Great for individual power users, one cluster at a time.
Lens is the best single-cluster desktop experience. Radar OSS is the best self-hosted single-team view. Radar Cloud is the best multi-cluster, team-shared, historically-aware hosted experience.
The question isn't which one wins — it's which job you're hiring the tool for. Most teams that use both end up using Lens on individual laptops for kubectl-replacement tasks, Radar OSS (or Cloud) for the team's shared operational view.
An honest framework for choosing.
Lens is the right call when
- You want a local-first desktop experienceIf you're an individual engineer who lives in an IDE and wants Kubernetes to feel like one, Lens is genuinely excellent. It runs on your machine, it's fast, and it never leaves your laptop.
- You need Kubernetes without any SaaSSome regulated environments or airgapped setups don't allow outbound connections to hosted services. Lens reads kubeconfigs on-device. Radar OSS works here too — it's Apache 2.0 and self-hostable.
- You rely on the Lens extensions ecosystemLens has a mature extensions marketplace with community-built integrations. If you've built your Kubernetes workflow around a specific Lens extension, that's a genuine lock-in.
Radar OSS is the right call when
- You want team-shared views without paying per seatRadar OSS runs in one cluster and serves a browser UI — everyone on the team gets the same view. Lens Pro charges $22-35/user/month the moment you use it at work.
- Commercial use allowed, under Apache 2.0Lens Personal is non-commercial only. Using Lens at work requires Lens Pro / Business / Enterprise. Radar OSS is Apache 2.0 — commercial, production, resale — all allowed.
- You're in an airgapped or regulated environmentRadar OSS has no outbound SaaS dependency. Self-host it on-prem, in an isolated VPC, or on an airgapped cluster. Nothing leaves your network.
- You want one engine for CLI and webRadar OSS ships a CLI and a browser UI against the same backend. Scripts, CI, and terminal diehards share truth with the team's dashboard. Lens is the Electron app or nothing.
Radar Cloud is the right call when
- You work on a team and want shared viewsRadar Cloud is team-first. Everyone sees the same topology, the same filtered timeline, the same annotated resource. No kubeconfig distribution, no “can you screenshot it for me?”
- You run more than one clusterLens shows one cluster at a time on one device. Radar Cloud unifies every cluster across every cloud in a single fleet view, with cross-cluster search and drift detection.
- You need historical data for post-mortems or auditsLens shows live state only. Radar Cloud persists events, Helm revisions, RBAC changes, and resource history — 30 days, 1 year, or forever depending on plan.
- You want your team to grow without per-seat pricingLens Pro is ~$22-35 per user per month. On a 50-engineer team that's $13k-21k/year just to let everyone look. Radar Cloud prices per cluster and invites everyone for free.
Radar OSS already beats Lens on the basics.
Skip the hosted comparison for a second. The open-source Radar engine — Apache 2.0, self-installable, nothing to pay for — lands ahead of Lens on most of the things engineers actually need day to day.
Truly free, Apache 2.0
Lens Personal is free for individual non-commercial use only. Using Lens at work requires a Pro or Enterprise license. Radar OSS is Apache 2.0, commercial use allowed, no license server, no auth wall.
Browser UI out of the box
No Electron install per laptop. Radar OSS runs as a binary or Helm chart and serves a web UI. Share a port-forwarded URL, share the cluster view. Works on anything with a browser.
One install, every cluster
Helm chart in, topology out. Lens requires every engineer to install the desktop app, import kubeconfigs, and wrangle contexts. Radar OSS reads the cluster from inside — scoped ServiceAccount, no kubeconfig shuffling.
Live topology graph
Real workload-to-workload connections with traffic direction, not just a resource tree. Lens ships a static resource list by default; topology is an optional extension you have to hunt for.
Event history that survives restarts
Radar OSS persists events well past Kubernetes' ~1-hour default. Lens shows whatever the API happens to remember right now. When a pod crashlooped an hour ago, Lens has nothing.
GitOps-aware by default
ArgoCD and Flux sync state sits next to the resources they produced — no extension required. Lens treats GitOps as a third-party add-on.
CLI and web, same engine
Radar ships a CLI for scripts, CI, and terminal diehards, plus the web UI — same backend, same queries. Lens is the Electron app or nothing.
No per-user creep
Lens Pro is ~$22-35/user/mo the moment you use it for work. Radar OSS is free for ten engineers or ten thousand. Grow the team, not the bill.
Lightweight footprint
A single pod with a couple hundred megs of memory per cluster. No Electron process on every laptop, no per-machine updater, no per-machine config drift.
If you're deciding “Lens or Radar,” start with Radar OSS. It's free, takes ten minutes to install, and does most of what you'd otherwise upgrade to Lens Pro for. If you outgrow single-cluster / single-team, that's when Radar Cloud makes sense.
Desktop vs hosted — what that actually means.
Each engineer maintains their own kubeconfig. State is ephemeral per session. Sharing a view means screensharing.
One workspace, one topology, one timeline — accessed by everyone via SSO. No kubeconfigs shared, no VPN, no inbound firewall rules.
The full comparison matrix.
Check is full support. Dash is partial (we explain the nuance in the row). X is not supported. Where a tier or plan tier matters, we call it out.
| Feature | Radar OSS (Apache 2.0) + Cloud (hosted) | Lens Desktop IDE, per-user |
|---|---|---|
| Deployment model | ||
Where it runs Lens is a desktop Electron app installed per-machine; Radar is a hosted SaaS accessed through a browser. | Hosted SaaS + in-cluster agent | Desktop (macOS/Win/Linux) |
Connection to cluster Lens reads local kubeconfigs directly; Radar connects via a lightweight in-cluster agent (outbound-only tunnel). | Agent, outbound WebSocket over TLS | Local kubeconfig |
Shared team workspace | Via paid Lens Desktop Kubernetes (LDK) / Business | |
Works without sharing kubeconfigs | ||
Web-accessible URLs you can paste in Slack | ||
| Multi-cluster & scale | ||
Unlimited clusters in one view | Add clusters manually per machine | |
Cross-cluster resource search | ||
Fleet topology (all clusters at once) | ||
Staging vs prod drift detection | ||
| Historical data & incidents | ||
Event timeline retention How far back you can look after an incident. Kubernetes' own retention is ~1 hour by default. | 30 days to 1 year | None (live-only) |
Post-mortem replay | ||
Shareable incident deep-links | ||
Audit log retention | 7 days to unlimited | |
GitOps correlation (ArgoCD/Flux) | Via extensions | |
| Auth & access control | ||
SAML / OIDC SSO | Lens Business / Enterprise only | |
SCIM provisioning | Enterprise tier only | |
Group-to-namespace RBAC | ||
Inherits Kubernetes RBAC | ||
Granular permissions per workspace | Per-device only | |
| Feature surface | ||
Topology graph (live) | Extension-dependent | |
Helm release manager | ||
Traffic visualization + mTLS | ||
Image filesystem viewer | ||
Cost insights (OpenCost) | ||
Cluster audit (31 checks) | ||
MCP / LLM agent integration Expose cluster state as a Model Context Protocol endpoint for Claude, Cursor, etc. | ||
Extensions marketplace | ||
kubectl embedded terminal | Via shareable Radar Shell | |
| Collaboration | ||
Slack / PagerDuty / MS Teams alerts | ||
Annotations on resources | ||
Webhooks | ||
Invite unlimited teammates Radar prices per cluster, so new teammates are free. Lens prices per user, so each teammate is another seat. | Paid per user | |
| Pricing model | ||
Pricing axis | Per cluster | Per user |
Free tier | 3 clusters, unlimited users, forever | Lens Personal (individual, non-commercial) |
Paid entry point | $99/cluster/mo (Team) | ~$22-35/user/mo (Pro) |
| Compliance | ||
SOC 2 Type 2 | ||
BYOC / on-prem deployment | Enterprise tier | Desktop is local by design |
EU data residency | Enterprise | N/A — data stays on your device |
Comparison based on Lens Desktop 2026 (Personal, Pro, Business, Enterprise tiers) and publicly documented features. Something wrong or out of date? email us and we'll fix it.
How each tool handles the jobs you actually do.
2am production incident
Open Lens. Pick the right cluster. Browse. Screenshot and paste in Slack. Lose context as pods restart.
Click the Radar link in the PagerDuty alert. Rewind the timeline. Paste URL into the incident channel — everyone sees the same state.
Compare staging to prod
Switch clusters in Lens, eyeball the differences, tab between windows. Remember which was which.
Open the drift-diff tool. See workloads that differ. Click into the diff. Done.
Auditor asks what changed last quarter
Lens shows live state only. Reconstruct from git log, reviews, and kubectl history across engineers.
Filter the audit log by namespace + date range. Export CSV. Attach to the audit package.
Onboard a new engineer
Generate a kubeconfig. Distribute securely. Walk them through Lens setup. Hope they don't break anything.
Their Okta group already grants them read access to their team's namespaces. First login, they're productive.
Explain a production bug to a PM
Screenshot. Paste. Explain. Get asked 3 more questions. Screenshot more.
Share a deep-link to the exact filtered view. They click. They see.
Post-mortem on last week's incident
The logs are gone. Events rolled off. Reconstruct from memory and Slack.
Rewind the timeline to 7 days ago. The ArgoCD sync, the OOMKill, the pod churn — all still there.
Some teams we talk to run both.
Lens on the laptop for kubectl-replacement power use. Radar for the team's shared view. The tools solve different jobs.
- 1
Install Radar OSS locally (Apache 2.0). It's the engine behind Radar.
brew install skyhook-io/tap/radar - 2
Sign up for a free Radar workspace. Apache 2.0 OSS or hosted free for 3 clusters.
app.radarhq.io/signup - 3
Connect a cluster to Radar with one Helm flag.
helm upgrade radar skyhook/radar --set cloud.token=$TOKEN - 4
Open Lens, connect the same cluster, compare the experience side by side.
(Your existing Lens setup works unchanged.)
Questions we get about Lens specifically.
Isn't Lens free?
Can I use Lens and Radar together?
Does Radar have a desktop app?
What about OpenLens?
How does the agent differ from Lens reading kubeconfigs?
Is Lens more mature?
Ready to see your whole fleet in one pane?
Apache 2.0 OSS or hosted free for 3 clusters. Connect in 60 seconds. Keep using Lens locally if you want — they play nicely together.
Apache 2.0 OSS · Unlimited clusters self-hosted · Hosted free tier for up to 3 clusters