How Kubarr works
Kubarr is a control plane for self-hosted applications running on your Kubernetes cluster. The dashboard is one part of a set of components with distinct jobs.
From browser to cluster
| Component | Job |
|---|---|
| Gateway | OpenResty routes dashboard, API and app requests; it checks authorization before proxying an installed app. |
| Frontend | A React interface for catalog, status, settings and app operations. |
| API | A Rust/Axum service for authentication, application state and control-plane requests. |
| Worker | Processes queued app operations using Helm and Kubernetes, separately from browser requests. |
| Database & storage | PostgreSQL stores Kubarr state. The platform can provide shared NFS media storage; chart-specific storage needs vary. |
Applications are chart-backed
The charts repository groups supported apps into media servers, media managers, indexers, download clients and other categories. Examples include Jellyfin, Plex, Sonarr, Radarr, Jackett and qBittorrent. Apps generally run in separate namespaces with chart-defined services, volumes and network policies. Deployment behavior depends on the chart and your cluster configuration.
Storage and access are deliberate choices
Shared media and individual application configuration do not always have the same storage needs. Some chart configurations use a shared NFS claim, while certain databases require local/block storage. Check the chart's README and storage notes before enabling an app. Plan backup and network access for your own cluster; namespace separation alone is not a substitute for verifying network policy enforcement.
For the detailed request flow, see the application architecture guide. To set up the platform, continue to getting started.