Radar Cloud overview

Radar Cloud is a hosted control plane that sits in front of your in-cluster Radars. The Radar binary still runs in each of your clusters - the same OSS engine, configured to dial out over a long-lived WebSocket. Skyhook hosts the team layer (app.radarhq.io UI, api.radarhq.io control plane), and your data plane stays where the cluster is. What we host: auth, orgs, billing, audit, the cluster registry, and the WebSocket multiplexer that fans your browser’s requests out to the right in-cluster Radar. What we don’t host: the cluster-side binary itself and its Kubernetes credentials. Radar Cloud doesn’t copy your manifests, logs or metrics: when you open one in the UI, it streams through the control plane to your browser and isn’t stored. What Radar Cloud does keep, including your event timeline and the logs and manifests a hosted AI investigation read, is listed under What lives in the Cloud.

What you get on top of OSS

Multi-cluster from one URL. Each cluster runs its own in-cluster Radar. Cloud federates them - they appear in a switcher, and fleet views aggregate across them.
Team workflow. Organizations, role-based access (owner / member / viewer), email + SSO invitations, audit log.
Hosted auth. Email magic-link, Google, passkeys, plus customer-side SAML / OIDC self-serve setup.
Personal access tokens for AI / CI clients, scoped per user, with rotation.
In-app inbox + webhook deliveries for cluster / org / billing events.
Stripe billing with a real Free tier, per-cluster Team and Enterprise plans, and Custom contracts.

The cluster engine itself is identical - same topology, timeline, audit, MCP, integrations.

Architecture

Browser (app.radarhq.io)
  │  session cookie (WorkOS sealed JWT)
  ▼
Radar Cloud control plane (api.radarhq.io) - Go service
  ├─ owns: users, orgs, clusters, members, billing, audit, PATs, prefs
  ├─ stores: Postgres (durable state)
  │
  ├─ per cluster: long-lived WebSocket (yamux)
  │     wss:443 (TLS, outbound from your cluster)
  └─→ Customer Kubernetes cluster
        └─ Radar pod (the OSS binary, in cloud-mode)
           ├─ does NOT store browser session secrets
           ├─ does NOT phone home except on the WS
           ├─ Control plane injects X-Forwarded-User / X-Forwarded-Groups on every request
           └─ Radar (--auth-mode=proxy) impersonates live calls and filters cached reads

When you open a cluster in the UI, the browser hits api.radarhq.io/c/{cluster_id}/... over HTTPS. The control plane validates your session, opens a fresh stream over the cluster’s existing WebSocket, and reverse-proxies the request to the Radar pod inside the cluster. SSE, pod-exec WebSockets, and MCP all flow through the same yamux multiplex.

What stays in your cluster

Data	Lives in	Why
Kubernetes resources, logs, metrics	Cluster	Read live when you open them and streamed through the control plane to your browser, not stored. Live K8s state is authoritative; copying it would just stale-cache it.
Topology, audit findings, traffic	Cluster	Computed at request time from live K8s state.
Helm releases, GitOps state	Cluster	Read straight from the cluster’s own secrets / CRDs.

What lives in the Cloud

Data	Why
User identity, org membership, roles	Tenancy boundary - the control plane enforces access.
Cluster registry (id, name, env, labels, install-token hash, last-connected)	So the org has a shared list of clusters.
Billing + subscription state	Stripe lives here.
Event timeline: Kubernetes events and resource changes (kind, namespace, name, and what changed)	So history survives pod restarts and spans clusters. Kept for your plan’s retention period.
Alert rules, alert history and notifications	So alerts fire and route when nobody has Radar open.
AI investigation transcripts, including the logs and manifests an investigation read	So investigations can be resumed and shared. They run on a model managed by Radar Cloud; see investigations in Radar Cloud.
Audit log + PATs	Cross-cluster audit trail and AI tokens.
User preferences (theme, pinned kinds, notify-on-* toggles)	Follows you across clusters.

With Radar Cloud Self-Managed, all of the above lives in your own infrastructure instead, apart from any AI model or identity provider you connect. The cluster bearer token is one-time-reveal: the control plane stores only a SHA-256 hash. If you lose the token, rotate it.

Auth boundary

The cluster’s bearer token (Bearer rhc_...) is validated by the control plane on the WebSocket handshake. Once the tunnel is open, in-cluster requests are implicitly trusted - the tunnel is the boundary. There’s no per-request token exchange. For requests through the tunnel, the control plane strips inbound X-Forwarded-* (anti-spoof) and injects X-Forwarded-User: <user_id> + X-Forwarded-Groups: radar:<role>,radar:org:<id>,radar:user:<id>. The in-cluster Radar runs --auth-mode=proxy under cloud-mode and uses that identity for impersonated live calls and authorization checks on cached reads. See Cloud RBAC for how the Radar groups map to K8s ClusterRoles.

Where to next

Connecting a cluster - the install command and what each Helm value does.
Organizations & roles - the permission model.
SSO - SAML / OIDC self-serve.
Billing & plans - free tier, Team, Enterprise, Custom.
Audit log - what’s recorded and how to export.

Get started

Views

In-cluster capabilities

Integrations

Local & in-cluster setup

Cloud

Reference

Radar Cloud overview

What you get on top of OSS

Architecture

What stays in your cluster

What lives in the Cloud

Auth boundary

Where to next

​What you get on top of OSS

​Architecture

​What stays in your cluster

​What lives in the Cloud

​Auth boundary

​Where to next

What you get on top of OSS

Architecture

What stays in your cluster

What lives in the Cloud

Auth boundary

Where to next