# Hub deployment

Install, configure, secure, and operate a self-hosted Railgrid hub.

Source: https://railgrid.ai/docs/self-hosting/hub/


Run the Railgrid hub on your own infrastructure. Choose an installation path, configure access, and establish storage and recovery procedures before onboarding workspaces.

## What a hub deployment contains

| Component | Role | Where it is documented |
|---|---|---|
| Hub | Console, API, provider registry, kubeconfig minting. Serves HTTPS on `:9443`. | [Install the hub](helm/) |
| kcp | The control plane every workspace and provider API lives in. Embedded in the hub pod, or external shards you operate. | [External kcp](external-kcp/) |
| Dex (or another OIDC issuer) | Signs users in. kcp and the hub both verify its tokens. | [OIDC](oidc/) |
| Ingress | Carries the console, the issuer, kcp, and published apps under public hostnames with TLS. | [Ingress](ingress/), [Gateway API](gateway-api/), [Cloudflare Tunnel](cloudflare-tunnel/) |
| Providers | Capabilities users enable in workspaces. Each is its own chart in its own namespace. | [Provider hosting](https://railgrid.ai/docs/self-hosting/providers/) |

## Hostnames you will need

Plan these before installing anything; several of them are baked into certificates, kubeconfigs, and OIDC client registrations.

| Hostname | Served by | Needed when |
|---|---|---|
| `console.example.com` | Hub | Always. This is `hub.hubExternalURL`. |
| `auth.example.com` | Dex | Using OIDC. This is `idp.issuerURL` and Dex's `config.issuer`. |
| `kcp.example.com` | kcp front proxy | Using external kcp and giving users or edges direct kcp access. |
| `kcp-root.example.com`, one per shard | Each kcp shard | Using external kcp: shards advertise these as their virtual-workspace URLs. |
| `*.apps.example.com` | Infrastructure provider routes | Publishing applications and App Studio previews. |

Keep each public hostname exactly one label below a zone whose wildcard certificate you hold. A hostname two labels down (`console.dev.example.com`) is not covered by a `*.example.com` certificate.

## Where to start

Start with [Install the hub](helm/). For a production deployment, read [authentication](authentication/), [external kcp](external-kcp/), and [operations](operations/) before onboarding users.


## In this section

- [Install the hub](https://railgrid.ai/docs/self-hosting/hub/helm/): Choose embedded or external kcp, configure a production hub, and verify the console.
- [Static Tokens](https://railgrid.ai/docs/self-hosting/hub/static-token/): Pre-shared bearer tokens — the simplest way to secure a personal hub.
- [External kcp with the kcp-operator](https://railgrid.ai/docs/self-hosting/hub/external-kcp/): Run kcp shards, etcd, and the front proxy outside the hub pod and connect the hub to them.
- [OIDC (Dex)](https://railgrid.ai/docs/self-hosting/hub/oidc/): Sign in to the hub with GitHub, Google, LDAP, or any OIDC provider via Dex.
- [Cloudflare Tunnel](https://railgrid.ai/docs/self-hosting/hub/cloudflare-tunnel/): Expose a hub through an outbound tunnel with DNS and TLS configuration.
- [Ingress](https://railgrid.ai/docs/self-hosting/hub/ingress/): Make your hub reachable from the internet with Gateway API, Cloudflare Tunnel, port forwarding, or a mesh VPN.
- [Gateway API on GKE](https://railgrid.ai/docs/self-hosting/hub/gateway-api/): Serve the console, Dex, kcp, and published apps from one GKE Gateway with managed certificates and DNS-only records.
- [Monitor, recover, and upgrade](https://railgrid.ai/docs/self-hosting/hub/operations/): Plan around the state each component owns, keep trust material valid, and upgrade in the right order.
- [Authentication](https://railgrid.ai/docs/self-hosting/hub/authentication/): Authentication, organizations and workspaces, service accounts, platform admins.