Platform Settings
Platform → Settings (/platform/settings) is a maintenance surface for the instance's data integrity. It also doubles as the reference page below for instance-wide operational settings that apply across every realm in the deployment — those are set through deployment configuration, not through this page.
Where do per-realm settings live?
Anything realm-specific (self-registration, DCR policy, branding, inbox retention) is owned by the realm admin and lives under Realm Settings. Everything described below applies to all realms in the deployment.
What's on this page today
| Action | What it does |
|---|---|
| Consistency Check | Opens a report verifying principal projections, group memberships, auto-group predicates, and cross-references. Read-only. |
| Rebuild Projections | Destructive — replays the entire event store and rebuilds every read model. Confirms before running; read models may be briefly incomplete while it runs. Use if data looks inconsistent. |
Instance-wide configuration
The settings below are not editable from this page — they live in deployment configuration and apply the same way across every realm.
Where does configuration come from?
Three layers, in order of override precedence (deeper wins):
configuration.json— committed defaults shipped with the image.configuration.local.json— gitignored, per-deployment overrides.- Environment variables (binding is case-insensitive, e.g.
Email__Smtp__Host).
Anything that touches startup wiring (Marten connection strings, OpenIddict signing-key material, listener URLs) also stays in configuration files, same as the settings below.
2FA enforcement
Three enforcement levels, configured as AuthenticationMinimumLevel in deployment config (not currently editable from the admin UI):
| Level | Behaviour |
|---|---|
0 — Off | 2FA is purely opt-in. Users may enable it on their own. |
1 — Optional | Users without 2FA see a non-blocking nudge to enrol. They can postpone within the grace window. |
2 — Required | Sign-in with only a password is rejected entirely. 2FA must already be set up. |
Per-user 2FA exempt flag in the user editor is admin-editable and lets you exempt specific users from the instance-wide policy — used sparingly (e.g. for service-account principals).
Grace period
When AuthenticationMinimumLevel >= 1, the grace period is the window during which a user can sign in without 2FA in order to enrol. After it elapses, sign-in fails until 2FA is set up.
Configured as TwoFactorGracePeriodDays in deployment config — not currently editable from the admin UI. The shipping default is 14 days.
Sign-in session lifetime
Browser/SSO lifetimes are realm-owned and editable under Administration → Realm Settings → Sessions. The defaults are a 30-day sliding idle window and a 180-day absolute limit. The same page controls whether persistent “remember me” cookies are allowed.
Native/OAuth client sessions have a separate realm default and can be overridden per Application and per OAuth client. See Authentication cookies and sessions.
SMTP
For transactional email: magic-link logins, password resets, email-OTP codes, email-verification, and bootstrap-admin invites. Configured under the Email section (host / port / TLS / auth / FromAddress / default FromName). The transport stays deployment-only. The sender address and display name are defaults: realm and Application email branding can override both, plus a validated reply-to address, for the built-in transactional messages — deliverability of a custom sender address is the configuring admin's responsibility.
If SMTP is misconfigured, magic links can't be sent. Users with a working password still sign in, but recovery flows degrade — verify your SMTP settings against a real mailbox after deploying, before relying on them.
Profile-change approval flow
Every profile edit (email, name, phone) goes through a change request that an admin must approve before it takes effect — this is currently mandatory, not something you can switch off. See Change Requests for how the approval and email-verification steps work.
Auth-log retention
Each realm configures its own Security-log retention under Realm settings → Logs. The default is 7 days, the allowed range is 1–365 days, and the realm-owned security-audit-prune job hard-deletes only expired entries in that realm DB. See Security and platform logs.
Tips
Stagger 2FA rollouts
Switching directly from Off → Required is jarring. Step through Optional first for a few weeks: users see the nudge, most enrol voluntarily, then the Required transition only forces the late adopters.
Verify SMTP after deploying
A bad SMTP config that "looks right" can silently swallow magic links, leaving users stuck. Trigger a magic-link or password-reset email in a test realm right after deploying, before relying on it.