Give every team self-serve Kubernetes visibility. Without building a portal.
Map your identity provider to Kubernetes namespaces. Invite the whole org. RBAC inherits from the cluster. Your golden path just got a view.
Every developer wants visibility. Nobody wants to give them cluster access.
You're the platform team. Your job is to make Kubernetes safe and self-serve for 20, 50, 500 engineers — without handing everyone a kubeconfig and hoping nobody runs kubectl delete by accident.
So you build a portal. Or you try Backstage. Or you write a Grafana dashboard. Or all three. They take months. They're never quite right. The moment a cluster changes, the dashboard is wrong. The service catalog rots. The portal gets 12 tickets a week asking why it doesn't show the thing they need.
Radar is the visibility layer you were going to build anyway. Scoped by namespace. Authenticated through your IdP. Live-correlated with Git state. It doesn't replace your IDP — it plugs into it.
How platform teams use Radar across the developer lifecycle.
Day-one productive
New engineer joins. Their Okta group auto-provisions them into Radar with read access to the team's namespace. They see their services, their pods, their recent deploys — without learning kubectl first.
Self-serve debugging
A backend engineer's service is flaky. Instead of pinging you, they open Radar, check the topology, see the upstream dependency was restarted, and resolve it themselves. Your queue stays clean.
Shared situational awareness
When something breaks, the whole incident channel sees the same view. The platform team isn't the bottleneck translating kubectl output to product engineers.
Compliance without fire drills
SOC 2 auditor asks who had access to the payments namespace in Q2. You export from Radar in 30 seconds. No scrambling to reconstruct from logs.
Group-to-namespace mapping. Not a spreadsheet you update quarterly.
The old way: every developer gets a kubeconfig. You maintain a spreadsheet of who has what. When someone leaves, you hope your offboarding script caught it.
The Radar way: your identity provider is the source of truth. Create a group in Okta called payments-engineers, map it once to the payments-* namespaces. New hires get access on day one. Leavers lose it on day zero.
RBAC inherits from Kubernetes. If a developer can't list secrets with kubectl, they can't see them in Radar. You don't manage a second permissions system.
apiVersion: radarhq.io/v1
kind: WorkspaceAccess
metadata:
name: payments-team
spec:
identityProvider: okta
groups:
- okta-group: payments-engineers
scope:
clusters: ["prod-us", "prod-eu", "staging"]
namespaces: ["payments-*"]
role: developer # read-only + logs
- okta-group: payments-oncall
scope:
clusters: ["prod-us", "prod-eu"]
namespaces: ["payments-*"]
role: operator # + helm rollback
- okta-group: platform-leads
scope:
clusters: ["*"]
namespaces: ["*"]
role: admin # all read + audit
Six capabilities that move the needle on platform KPIs.
SAML SSO + group-to-namespace mapping
Map Okta, Google, or Azure AD groups directly to Kubernetes namespaces. No custom controllers. No brittle kubeconfig distribution scripts.
Multi-cluster fleet dashboards
See every cluster across every cloud. Compare staging vs prod. Catch drift before it causes an outage.
Read-only by default
Give developers visibility without write access. They see their services. They don't accidentally nuke the ingress.
Native ArgoCD & Flux integration
Developers see their deploy state next to the cluster state. GitOps tool of choice becomes part of the visibility layer, not a separate tab.
Helm release visibility
Every release, every revision, every values file — across every cluster. Roll back from the UI. Audit changes over time.
Shareable deep-links
Paste a link in #help-kubernetes. The developer sees exactly the resource, exactly the filtered timeline, exactly the question you're answering.
Radar plugs into the platform you're building.
Your golden path, visible
You spent months defining how services should be deployed. Radar shows the teams who followed it — and the ones who went sideways — without writing a custom dashboard.
Developer self-service, actually
The platform engineering promise is self-service. Radar is the part that developers actually self-serve — because they can answer their own questions without a ticket.
Works with whatever IDP you have
Backstage, Port, Cortex, or the README you call an IDP — Radar embeds cleanly. Deep-link from service catalogs to the live cluster view.
Because your job is measured too.
Developer time-to-first-deploy
Measured in days, not weeks. Developers see their cluster state the day they join.
% of support tickets resolved self-serve
Developers answer their own Kubernetes questions. Your team's backlog gets shorter.
Cross-cluster drift incidents
Drift between staging and prod gets caught in PR review, not in a 2am page.
Audit evidence collection time
SOC 2 evidence requests go from half-day fire drills to 30-second exports.
Stop being the bottleneck for every Kubernetes question.
Apache 2.0 OSS or hosted free for 3 clusters. Connect your identity provider. Invite the whole team. Watch the tickets stop coming.
Apache 2.0 OSS · Unlimited clusters self-hosted · Hosted free tier for up to 3 clusters