What We're Building in 2026: Radar OSS and Radar Cloud

Two shipping dates, one product line, and a clear split between what's free and what costs money.

In January 2026 we're releasing Radar as open source under Apache 2.0. In February 2026 we're releasing Radar Cloud, the multi-cluster platform. This post is the engineering view of what lands in each, what doesn't, and why we drew the line where we did.

Why two products instead of one

We've spent the better part of a year talking to teams running Kubernetes at the messy middle of the curve: past the first production cluster, not yet big enough to have a platform team. The consistent pattern: they have three to twelve clusters, no good way to see them together, and a debugging experience that still leans on kubectl plus tabs.

Radar (the OSS tool we built for ourselves) solves the single-cluster debugging problem. It's a Go binary with the React UI embedded via go:embed, runs against your kubeconfig, and shows you resources, topology, a timeline, Helm releases, GitOps state, and traffic - live, via SharedInformers on top of the Watch API. No in-cluster install. No cloud account. No data leaving your laptop.

That covers one engineer debugging one cluster. It does not cover:

• Multiple clusters visible in one place.
• History that survives restarts and outlives your current kubeconfig session.
• Alerts when something breaks at 3am and nobody's looking.
• RBAC beyond whatever your kubeconfig already grants.
• A shared URL to a specific resource at a specific time for your incident channel.

Those are team problems. They need an identity layer, an org-scoped audit log, and a hub that's awake when you're not. Trying to solve them inside the OSS binary would make Radar slow, opinionated, and hard to run on a laptop. So we split.

January 2026: Radar OSS

Radar OSS ships as a single Go binary. The React frontend is compiled in. On startup it reads your kubeconfig, opens your browser, and connects directly to the API server.

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

Also available via Homebrew, Scoop, and an in-cluster Helm chart for teams that want a shared instance.

What's in the v1 binary:

• Resources view - browse every resource type, YAML edit, logs, events, exec, port-forward, image filesystem browsing.
• Topology view - structured DAG of ownership, service routing, ingress paths, config dependencies.
• Timeline view - live stream of Kubernetes events and resource changes, in-memory by default, SQLite-backed if you pass --timeline-storage sqlite.
• Helm view - list, inspect, upgrade, rollback, uninstall; uses the Helm Go SDK directly, not shelling out.
• GitOps view - Argo CD Applications and Flux Kustomizations / HelmReleases / GitRepositories show up in topology with sync status, and you can trigger sync / reconcile from the UI.
• Traffic view - auto-detects Cilium / Hubble or Caretta and draws a live flow graph.
• Cluster audit - 36 best-practice checks across security, reliability, and efficiency, surfaced inline on the affected resources.
• MCP server - token-optimized, RBAC-aware cluster context for AI tools like Claude, Cursor, and Claude Code.

CRDs are auto-discovered via dynamic informers, so Argo Rollouts, Istio VirtualServices, and your own CRDs appear without plugin work.

Source goes public in January. Apache 2.0. We want PRs.

February 2026: Radar Cloud

Radar Cloud is a control plane plus Radar deployed in each cluster. In-cluster Radar is the same Go binary as OSS (~32MB RSS steady state). Instead of serving a local UI, it dials out to the control plane (api.radarhq.io:443 for our hosted service), holds an outbound WebSocket open, and lets the control plane reverse-proxy authenticated browser requests through to it on demand. Cluster state stays in the cluster.

The connection is outbound-only. No inbound ports. No NodePort, no LoadBalancer, no Ingress. For hosted Cloud, your cluster needs outbound access to our service. With a self-managed control plane, it needs to reach that control plane on your network.

helm repo add skyhook https://skyhook-io.github.io/helm-charts
helm repo update
 
helm install radar skyhook/radar -n radar --create-namespace \
  --set cloud.token=$RADAR_CLOUD_TOKEN

The enrollment token is issued from the Radar dashboard. Radar runs with a scoped Kubernetes ServiceAccount - read-only by default, read / write if you opt in for features like rollback from the UI. Logs, exec streams, and port-forwards all go through Radar on demand and are never stored at rest.

In GA on February release:

• Fleet views across every connected cluster: problems, cross-cluster search, audit-check rollups, package drift.
• Live timeline served live through the reverse proxy from the in-cluster Radar pod.
• SSO: Google and GitHub sign-in on every plan; corporate SAML / OIDC (Okta, Google Workspace, Entra ID, OneLogin, generic SAML / OIDC) on Enterprise.
• Kubernetes-native RBAC via impersonation: three default roles (owner, member, viewer) bound to standard K8s ClusterRoles, plus per-user RoleBindings via cloud:user:<id> groups.
• Audit log on paid plans, with tier-based retention: 30 days on Team, 365 days on Enterprise.
• Notifications for hub events (cluster connect / disconnect, billing, member invites) over Slack, webhook, and an in-app inbox.
• Shareable deep links per resource and view.
• REST API for automation.
• MCP server per cluster for AI tools (Claude, Cursor, Claude Code, etc.).
• SOC 2 Type 2 attestation.
• Data residency in US (us-east-1) or EU (eu-west-1).

SCIM 2.0 directory sync ships on Enterprise for teams that need directory-driven user and group lifecycle from their IdP. The control plane is Go microservices on PostgreSQL; it doesn't store cluster state - all cluster data is served live from the in-cluster Radar pod.

The product boundary

No cluster feature is held back from OSS just because Cloud exists.

What's not in v1

Being specific about gaps is more useful than listing features.

• No cross-cluster topology yet. Fleet views give you the aggregate dashboard for problems, search, checks, and packages. A true cross-cluster topology graph (tracing a service mesh request from cluster A to cluster B) is on the roadmap, not a launch feature.
• No cross-cluster timeline yet. Per-cluster timeline works through the reverse proxy. A unified timeline that joins events across clusters is on the roadmap.
• No long-term Cloud-backed event archive at launch. At v1 events lived only in the cluster, with optional SQLite persistence. (Shipped since: the control plane now pulls each cluster's timeline over its existing tunnel and retains it centrally - see Kubernetes Events Expire in an Hour. A SIEM is still the right answer for multi-year archives.)
• No Windows node support. Radar ships as a Linux container only. We don't have Windows nodes in our test matrix, and we'd rather not claim support we haven't exercised.
• No event-rule alerting on arbitrary K8s events. Cloud notifications cover hub-side events only (connection, billing, invites). If you want pager-style alerting on K8s event streams, that's Prometheus / Alertmanager territory; we're not going to be that system.
• Self-managed Cloud control plane below Enterprise. More on this below.

The Self-Managed question

We've been asked this enough that it deserves a paragraph.

Radar Cloud is a multi-tenant hosted service by default. With Radar Cloud Self-Managed, you install and operate the control plane on your own infrastructure. It is available on Enterprise and Custom. Air-gapped deployments require Custom. Free and Team are SaaS-only.

This matters for two groups: teams in air-gapped environments (defense, some finance, some regulated health workloads) and teams whose security policy prohibits outbound telemetry to a shared multi-tenant SaaS. If you need to keep data inside your own infrastructure, running the Cloud control plane yourself is the path; if you don't need the Cloud backend at all, Radar OSS is the right answer, and it will stay the right answer. We are not going to cripple OSS to push you toward Cloud.

When to use which

Use Radar OSS when you're a single engineer debugging your own cluster, when you're working in an air-gapped environment, when you need a fast local tool for incident response without logging in to anything, or when you want to see what a cluster is doing in under ten seconds flat. It's a better kubectl for most day-to-day visibility work.

Use Radar Cloud when you're a team. When you want a teammate's URL to land them on the same cluster you're looking at. When "who changed that ConfigMap" needs an audit log answer. When your engineers log in with Okta and you don't want to hand out kubeconfigs as the unit of access control. When a cluster going dark while nobody's watching needs to ping someone.

The rest of 2026

Q2: Cross-cluster topology, cross-cluster timeline, deeper provider-specific renderers, MCP tool expansion.

Q3: Cloud-backed timeline retention, deeper GitOps workflows (drift detection history, rollback orchestration across clusters), expanded Windows support if the demand signal is there.

Q4: The self-managed Cloud control plane for tiers below Enterprise, if customer signal warrants it.

If you want to follow along, the OSS source goes public in January and the Radar Cloud waitlist is open at radarhq.io. We'll post install-day walkthroughs for both.