← Documentation

Helm Chart Reference

What the realmsso-server chart deploys by default, and the handful of values you need to set before installing.

What the chart deploys

helm/realmsso-server renders a Deployment, Service, ConfigMap, and — when enabled — an Ingress and a HorizontalPodAutoscaler for the API. Postgres and Redis are external by default: point postgresql.externalUrl and redis.externalUrl at instances you manage, or turn on the optional Bitnami subcharts (postgresql.enabled / redis.enabled). The chart can also optionally deploy Keycloak itself from the official image (keycloak.deploy.enabled, off by default) for evaluation or self-hosters without an existing Keycloak — bring-your-own via keycloak.url is the default path.

Values you need to set before installing

KeyWhy it matters
config.dashboardBaseUrlPublic origin of the dashboard frontend. Magic-link emails point here — get it wrong and sign-in mail goes nowhere useful. Required when ingress is enabled; the chart refuses to render without it.
config.adminPortalBaseUrl / config.corsOriginsShip with placeholder hostnames on a domain nobody serves — override with your own before install.
ingress.hosts / ingress.tlsShips with a placeholder API hostname — replace with your own.
keycloak.urlYour Keycloak's admin API. Leave empty only if you also enable keycloak.deploy.
smtp.fromShips with a placeholder address — set to one on a domain you control or mail fails SPF/DKIM.

A SCIM base URL is not one of them. SCIM is served at /api/scim/v2 on whatever origin your ingress serves, and no chart value changes that — see the SCIM API reference.

Secrets

By default the chart templates a Secret from five required values — there is no usable default, so a render without them fails immediately rather than deploying with an empty secret:

openssl rand -hex 64   # jwtSecretKey
openssl rand -hex 64   # magicLinkSecretKey
openssl rand -hex 32   # encryptionKey
# plus: postgresql.externalUrl and keycloakAdminClientSecret

Set existingSecret to a Secret name you manage yourself (external-secrets, kubectl create secret) to skip this templating — that Secret must supply the same keys, and skipping templating also skips these render-time guards, so a missing key surfaces as a CrashLoopBackOff instead of a Helm error.

Liveness and readiness currently check the same thing

Both probes point at GET /health today, which only confirms the process is up — neither one currently fails a pod out of rotation when Postgres or Redis is down. The server separately exposes GET /readyz, which does check those dependencies; pointing readinessProbe at it is a safe override. See Monitoring & Observability.

Autoscaling, backup, and monitoring

autoscaling is off by default (enabled: false, floor minReplicas: 1, ceiling maxReplicas: 10). The Deployment runs replicaCount: 1 until you set autoscaling.enabled: true — see Scaling Guide. The chart also declares backup.* and monitoring.* value blocks, but neither is fully wired up yet: there's no CronJob consuming the backup values, and no /metrics endpoint for the Prometheus scrape annotations to hit. See Backup & Recovery and Monitoring & Observability for what each actually does today.

Per-account hostnames do not isolate anything yet

The chart's optional per-account hostname feature assigns each account a subdomain, and the server stores it. Nothing at the edge binds that host to the account's realm. ADR 0013 (Accepted 2026-09-02) decides the mechanism — a static host-to-realm map generated from the stored columns and applied as ordinary edge configuration — and no such map exists on server main. Until it is built, Keycloak answers for any realm on any tenant host, so enabling the feature buys a nicer URL and no additional boundary. Plan the rollout on that basis.

This page covers what most installs need. For the full field-by-field reference — including resource limits, security context, and the optional per-account hostname feature — read helm/realmsso-server/values.yaml in the server repo; every value is commented in place.