Self-host overview
Run the same Radicas codebase on your own infrastructure — deployment profiles, swappable edges, and what changes relative to the SaaS.
Radicas ships one codebase that runs in three ways: as the multi-tenant SaaS we operate, self-hosted on your infrastructure, or BYOC in your own cloud account. Self-host is not a fork — it is the same application with different edges selected at deploy time.
Deployment profiles
Three profiles select how the platform is wired:
- saas — multi-tenant, operated by Radicas at app.radicas.io.
- self-host — your Kubernetes cluster, your storage, your data.
- byoc — your cloud account, deployed with the same artifact.
The application itself depends only on abstract contracts — an OIDC issuer, a Postgres DSN, an S3-compatible endpoint, key-management settings, and a tenancy mode — never on a specific cloud service. A profile is configuration, not code.
What swaps
| Concern | SaaS | Self-host |
|---|---|---|
| Identity (OIDC) | Kinde | Zitadel |
| Control-plane Postgres | Neon | CloudNativePG (CNPG) |
| Object storage | Hetzner Object Storage | MinIO, or any S3-compatible store you run |
| Billing | Stripe module on | Off — the billing module is absent at deploy time |
Switching the identity provider changes only the issuer configuration; the application verifies standard OIDC JWTs either way.
What stays the same
Everything that matters: the same data plane (ClickHouse hot plus object-storage bronze), the same two schemas (FOCUS gold and OTel gen_ai — see the three layers), the same ingest gateway and tenant stamping, delivered as a single artifact — a Helm chart plus versioned container images. Self-host runs in single-tenant mode, which keeps the tenant column in the schema with one tenant in it, so the code never diverges from the SaaS.
Status
Self-host packaging lands with Phase 5 of the platform roadmap. The install, configuration, and upgrade pages are structured drafts that track it — they contain the settled decisions and will be completed as Phase 5 ships.