Server settings

Rate limits

Per-scope request limits — login, password resets, messages, uploads, writes, search.

Admin onlyApplies instantly

Each scope is a pair — how many requests, per what interval — enforced server-side and applied without restarts. Seven pairs are editable on the tab:

Scope Settings Guards against
Login attempts rateLoginLimit / …IntervalSeconds credential stuffing
Session refresh rateSessionRefreshLimit / …IntervalSeconds refresh-token grinding
Registrations rateRegisterLimit / …IntervalSeconds mass account creation
API writes (generic) rateApiWriteLimit / …IntervalSeconds scripted abuse
Message sends rateMessageSendLimit / …IntervalSeconds spam floods
Attachment uploads rateAttachmentUploadLimit / …IntervalSeconds storage abuse
Search queries rateSearchLimit / …IntervalSeconds expensive-query hammering

Three more scopes are enforced exactly the same way but have no field on the tab — they live in the settings registry only, so changing them off the defaults means writing to the settings store directly:

Scope Settings Default
Password resets ratePasswordResetLimit / …IntervalSeconds 3 per hour
Two-factor codes rateTwoFactorLimit / …IntervalSeconds 5 per 15 min
Content reports rateReportLimit / …IntervalSeconds 10 per hour

Session refresh deserves a word: it is keyed by IP and every browser tab spends one on reload once its access token nears expiry, so the whole office behind a single NAT address draws on the same budget. The default (60 per minute) is sized for that. Setting it too low signs people out mid-session rather than blocking an attack.

Limits apply per user (per IP for unauthenticated scopes like login). When a limit trips, the API returns 429 with a retry hint; the client surfaces it to the user. On a community endpoint a 429 also feeds the auto-timeout counter.

Tip

Limits are shared across all app processes (they live in the cache pool), so what you set is what an abuser gets — no per-worker multiplication.