Authentication

The platform authenticates users through its own auth service — a GoTrue deployment (mono-auth) that this chart runs alongside the applications, with its own database.

Turn it on

edisyl:
  # Which auth service the fleet talks to. This is the one-line switch: it
  # decides which set of credentials renders and mounts, so there is never a
  # state where a URL from one auth service sits beside keys signed by another.
  authSource: selfhosted
  auth:
    enabled: true

Both are needed. auth.enabled runs the service; authSource is what points the other applications at it.

Caution

edisyl.auth ships disabled and at a single replica. GoTrue migrates its own database on boot, and two fresh pods migrating concurrently has not been verified — which is the only thing a first install at two replicas would do. Raise the replica count as a deliberate decision, not as a default.

Its database

The auth service does not use the application database. It gets its own — a login role, a database it owns, and the connection secret both the deployment and its prep hook read. The chart provisions all three from the bundled CloudNativePG cluster when edisyl.authDbCreate says so.

This is why bringing your own PostgreSQL needs thought: the auth database is declarative against the bundled cluster. See database.source and edisyl.authDbCreate in the values reference.

The secrets it needs

Credentials are split by who mounts them, deliberately — a browser-facing server has no business holding a credential that can register an identity provider.

Secret	Holds	Mounted on
edisyl-auth	What the service signs with: GOTRUE_JWT_KEYS, GOTRUE_JWT_SECRET, GOTRUE_SAML_PRIVATE_KEY, and the Google OAuth client id and secret	The auth pod alone
edisyl-auth-client	AUTH_ANON_KEY — the consumer side, what the apps verify against	The application pods
edisyl-auth-service-key	AUTH_SERVICE_KEY, a service_role token	The web application only
edisyl-auth-admin	The API’s credential for the admin API	The API alone

No URL appears in any of them. Where the auth service lives is derived into the platform config from the hostname this chart publishes for it, so the address and the service cannot disagree.

The signing keys are yours to mint

GOTRUE_JWT_KEYS is the service’s key set, and the chart cannot generate it — Helm cannot produce an EC keypair. The API verifies every user token as ES256, against the key set the auth service publishes at /auth/v1/.well-known/jwks.json, with the issuer pinned to that same address.

A service configured with only a symmetric secret issues HS256 tokens with no issuer claim, and then every authenticated request fails with 401 Invalid or expired token — sign-in included. It reads as a credential problem; it is an algorithm one.

Secrets and signing keys has two ways to mint all of them, and explains why the key set needs both an EC entry and a verify-only HS256 one. They are yours alone — we never generate or hold signing material for a self-hosted deployment.

Signing in

Sign-in is through the web application, served at edisyl.<config.domain> unless you set an explicit edisyl.edisyl.ingress.host — for example, to put it on the apex instead.

The first account that matters is the one in bootstrap.adminEmails: the seed creates an owner row for that address, and it is what gates creating data sources and other owner-level objects.

If the address you sign in with does not match one in bootstrap.adminEmails, you get an owner row nobody can log in as, and your own account owns only its personal workspace. The seed job is idempotent — adding the address and re-running helm upgrade links the existing row rather than duplicating it.

Staff SSO

config.staffSsoProviderId pins the staff identity provider. The API reads it from the platform config rather than from the auth service’s own values.