> ## Documentation Index
> Fetch the complete documentation index at: https://radarhq.io/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Radar Cloud overview

> How Radar Cloud is built - the hosted control plane, the in-cluster Radar pod, the tunnel, and what stays in your cluster vs. what goes to the cloud.

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-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](/docs/oss-vs-cloud). |
| 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](/docs/features/diagnose#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](/docs/cloud/self-hosted), 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](/docs/cloud/cluster-token).

## 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](/docs/cloud/rbac) for how the Radar groups map to K8s ClusterRoles.

## Where to next

* [Connecting a cluster](/docs/cloud/connect-cluster) - the install command and what each Helm value does.
* [Organizations & roles](/docs/cloud/organizations) - the permission model.
* [SSO](/docs/cloud/sso) - SAML / OIDC self-serve.
* [Billing & plans](/docs/cloud/billing) - free tier, Team, Enterprise, Custom.
* [Audit log](/docs/cloud/audit-log) - what's recorded and how to export.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.