Radar OSS or Radar Cloud? An Honest Take on When to Use Each
The most common question in our GitHub issues: do I need Radar, or is OSS enough? Here's the honest answer, with the five questions that actually decide it.

The most common question in our GitHub issues is some variant of "do I need the Radar version?"
Here's the honest answer: most people don't.

Radar OSS launched in January. Radar Cloud launched a month later. Since then, we've watched people agonize over the choice in ways that don't match how we actually think about it internally. This post is our attempt to stop that agonizing.
What They Share
Radar OSS and Radar Cloud are the same tool for most of what you do day to day. Same UI conventions, same keyboard shortcuts, same views: Resources, Topology, Timeline, Helm, Traffic. Same SharedInformer foundation under the hood. The React frontend is literally the same codebase, with fleet-scoped views layered on top for Radar Cloud.
If you've used one, you already know the other. There is no relearning tax.
The thing that changes between them isn't the tool, it's the shape of your work. Are you one person poking at one cluster, or are you a team keeping an eye on many? That's the whole question.
The Five Questions That Decide It
Forget feature matrices for a minute. These five questions predict the right answer better than anything else:
- Are you working alone, or with a team? If two or more engineers need to look at the same cluster state during the same incident, something hosted starts to earn its keep.
- Do you care about losing state when you close your laptop? OSS timeline is in-memory by default (SQLite optional). Close the terminal and the history is gone. If you want a 30-day history to go look at, that's Radar.
- Do you need to be paged when something breaks, or are you already watching? OSS is a tool you open. Radar can tap you on the shoulder.
- Do you need more than one person to have scoped access? If "Alice sees prod, Bob sees staging" matters, you want per-cluster and per-namespace RBAC, not a pile of kubeconfigs.
- Are you running one cluster, or six? Fleet view only starts paying for itself once "which cluster is that pod in?" becomes a real question you ask weekly.
The more your answers trend toward team and multi-cluster, the more Radar earns its place. If you're answering "alone, one cluster, I just want to look" to all five - stay on OSS. That's what it's for.
When Radar OSS Is the Right Answer
OSS isn't a stepping stone. For a large slice of users, it's the final answer.
- Solo engineers debugging a single cluster from their laptop. You don't need a fleet view of one thing.
- Air-gapped or regulated environments where outbound traffic to a hosted vendor isn't allowed. OSS runs entirely on your machine with your kubeconfig. No data leaves.
- "I want to poke around for an hour" moments. You inherited a cluster and want to understand it before touching anything.
kubectl radarand you're in. No account, no token, no onboarding wizard. - Contributors and developers who want to read the source, fork it, or build on top of it. Apache 2.0, single Go binary, React UI embedded via
go:embed. - Teams deploying Radar in-cluster as a read-only internal dashboard via the Helm chart. If you're fine with shared view and kubeconfig-style access control, that works.
Where OSS is a bad fit: a 12-person team trying to coordinate during a production incident at 2am. Everyone running their own local Radar against their own kubeconfig is not incident response, it's a conference call. That's the point where you want one URL everyone shares.
When Radar Earns Its Price
Radar starts making sense when your answers to the five questions flip.
- Teams of 3+ engineers who all need shared context. One URL, one timeline everyone sees, one place incidents are tracked.
- Fleets of 5+ clusters. Fleet view exists because alt-tabbing between five browser tabs of Radar OSS is not a workflow.
- On-call rotations. Radar routes alerts to Slack, PagerDuty, Opsgenie, MS Teams, or a webhook. Smart event correlation groups related events into incidents so you're not paged 40 times for one bad deploy.
- Compliance-driven audit needs. If you need a record of who clicked what, when, against which cluster, audit logs ship on Free (7-day retention), Team (30 days), and Enterprise (1 year). SOC 2 Type II across the board.
- You're tired of kubeconfig-based access control. Scoped RBAC per-cluster and per-namespace; Google Workspace, GitHub, and full SAML/OIDC SSO (Okta, Entra ID, any spec-compliant provider) on Team; SCIM 2.0 provisioning on Enterprise.
Where Radar is a bad fit: an engineer who will use Radar twice a week to check one cluster. There's no reason to pay for that. Use OSS.
The Hybrid Pattern
A lot of teams end up using both, and we think that's correct.
Local laptop debugging? OSS. You're on a train, you've got kubeconfig, you want to check why a pod is CrashLooping. kubectl radar is faster than opening a browser tab and loading a web app.
Shared fleet oversight, alerts, audit trails, on-call? Radar.
Both have the same mental model. You don't flip between "oh, this is the Radar way of doing it" and "this is the Radar way of doing it." It's one tool with two deployment shapes. Keep both. The OSS binary is free forever, and the Radar Free tier covers one cluster for a small team.
What Radar Doesn't Try to Do
This is the part I want to be very clear about, because it's where trust in OSS tooling tends to break down.
Radar is not a replacement for Radar OSS. OSS stays Apache 2.0. OSS stays single-binary. OSS stays fully featured for single-cluster work. Resources, Topology, Timeline, Helm, Traffic - all of it stays in OSS. We are not gating features in OSS to push people toward Radar.
Radar adds things OSS can't meaningfully do on its own: multi-cluster aggregation, persistent 30-day (or 1-year) retention in a real database, alerting out to Slack and PagerDuty, SSO and SCIM, audit logs, compliance certifications. Those are genuinely different surface areas, not artificially withheld capabilities.
We'll never rug-pull OSS. Specifically:
- We won't move existing OSS features into a Radar-only tier.
- We won't add mandatory telemetry or cloud check-ins to the OSS binary.
- We won't require an account to run
kubectl radar. - If we ever need to fundamentally change the license, it'll be a visible, discussed fork, not a quiet bait-and-switch shipped in a minor version bump.
We watched Lens do the mandatory-login dance in 2024. We're not doing that. It's why we open-sourced Radar in the first place.
A Word About Pricing
The Free tier of Radar exists precisely so a solo engineer at a small team can try the hosted version without pulling out a credit card. 1 cluster, up to 10 nodes, 24-hour timeline retention, unlimited teammates in your workspace. If that's enough for you, stay there forever. We're fine with it.
Team is $99 per cluster per month with 30-day retention, unlimited nodes, unlimited teammates, Google/GitHub + SAML/OIDC SSO, Slack/PagerDuty/MS Teams alerts, basic RBAC, and shareable deep-links. That's the tier most teams in the 3-50 engineer range land on. Enterprise is custom-priced and adds SCIM 2.0 provisioning, advanced namespace-scoped RBAC, BYOC/on-prem deployment, 1-year audit retention, a 99.9% SLA, dedicated CSM, and US or EU data residency. Annual contracts get 20% off the Team list price.
We're not going to push you to a plan you don't need. The Free tier is a real product, not a 14-day trial dressed up.
The Side-By-Side
| Capability | Radar OSS | Hub Free | Hub Team | Hub Enterprise |
|---|---|---|---|---|
| Clusters | Unlimited (local) | 3 (up to 10 nodes each) | Unlimited ($99/cluster/mo) | Unlimited (custom) |
| Timeline retention | In-memory (or SQLite) | 24 hours | 30 days | 1 year+ |
| Audit logs | - | 7 days | 30 days | 1 year |
| Auth | kubeconfig | Google/GitHub | Google/GitHub + SAML/OIDC SSO | + SCIM 2.0 provisioning |
| Alerts (Slack, PagerDuty, Teams) | - | - | Slack, PagerDuty, MS Teams | + webhooks |
| Scoped RBAC | - | - | Basic | Advanced (group to namespace) + custom roles |
| SLA | - | - | 99.5% | 99.9% |
| BYOC / on-prem | - | - | - | Yes |
| Fleet topology scope | Single cluster | 3 clusters | All connected | All connected |
| Data residency | Your laptop | US | US | US, EU, or BYOC |
| Price | Free (Apache 2.0) | Free | $99 / cluster / month | Contact us |
A Short Decision Flow
If you want the three-second version:
- One cluster, one person, ephemeral use? Radar OSS. Done.
- One cluster, small team, want a shared URL and 24 hours of live history? Radar Free.
- 2-50 clusters, team of 3+, want alerts and proper access control? Radar Team.
- Need SCIM provisioning, advanced audit retention, BYOC/on-prem, or a 99.9% SLA? Radar Enterprise.
- Air-gapped, or allergic to hosted vendors? Radar OSS, deployed in-cluster via Helm.
- Already on OSS and it works? Stay there. Seriously.
The honest summary: if you're happy with Radar OSS, you don't need anything else from us. If you hit one of the walls above - multi-cluster, team coordination, retention, alerting, compliance - Radar is the tool you should reach for, not because it's more powerful, but because it's shaped for that job.
Both tools are on our website, both GitHub and radarhq.io. Pick the one that fits. We'd rather you use the right one than the expensive one.
Keep reading
What We're Building in 2026: Radar OSS and Radar Cloud
Two shipping dates, one product line. Radar open source ships January 2026, Radar follows in February. Here's the scope, the split, and what won't make it into v1.
Introducing Radar: Multi-Cluster Kubernetes Visibility for Teams
Radar Cloud is the hosted multi-cluster extension of Radar OSS. Fleet view, 30-day timeline, SSO, scoped RBAC, alerts. Credentials never leave your cluster.
Multi-Cluster Topology: Cross-Cluster Service Maps That Don't Hairball
Cross-cluster service topology is hard because Kubernetes itself has no multi-cluster graph. Here's how Radar builds one without turning it into a hairball.