> ## 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, the K8s API client, your manifests, your logs, your traffic data. Those never leave the cluster.

## 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.
* **WorkOS auth.** Email magic-link, Google, passkeys, plus customer-side SAML / OIDC via the WorkOS Admin Portal.
* **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 plan, and Enterprise.

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 those on K8s calls
```

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, events | Cluster  | Live K8s state is authoritative; copying it to SaaS 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.                                    |
| Audit log + PATs                                                             | Cross-cluster audit trail and AI tokens.              |
| User preferences (theme, pinned kinds, notify-on-\* toggles)                 | Follows you across clusters.                          |

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: cloud:<role>,cloud:org:<id>,cloud:user:<id>`. The in-cluster Radar runs `--auth-mode=proxy` under cloud-mode and impersonates those headers on K8s calls. See [Cloud RBAC](/docs/cloud/rbac) for how the cloud 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.
* [Audit log](/docs/cloud/audit-log) - what's recorded and how to export.