Overview
Sign-in options for self-hosted Proliferate.
On launch, the desktop app asks your server which sign-in methods it offers
(it calls GET /auth/desktop/methods) and shows the matching sign-in screen.
A fresh install needs no OAuth app and no identity provider: email and
password sign-in is on by default, and the first account is the one you
create when you claim the server at https://<site>/setup.
The methods, in the order most installs adopt them:
Email & password
The default. Zero configuration: claim the server, invite your team, everyone signs in with email and password.
GitHub sign-in
Optional. One GitHub OAuth app and two env vars add a GitHub button to the desktop sign-in screen.
Google sign-in
For Google Workspace teams, delivered through the OIDC SSO connection with Google as the identity provider.
OIDC SSO
Connect any OIDC identity provider. Accounts are created automatically on first sign-in, governed by the JIT policy.
Which method admits whom
Methods can be enabled side by side, and they differ in who gets an account:
| Method | Configuration | Who can sign in |
|---|---|---|
| Email & password | None; on by default (turn it off with PASSWORD_AUTH_ENABLED=false) | The owner who claimed the server, plus invited teammates who registered through their invite link |
| GitHub sign-in | GITHUB_OAUTH_CLIENT_ID / GITHUB_OAUTH_CLIENT_SECRET | Any GitHub account that completes OAuth; an existing account with the same email is linked instead |
| Google / OIDC SSO | SSO_* env vars | Governed by the SSO JIT policy and allowed domains |
Three things hold across every method:
- Self-hosted servers run in single-org mode (
SINGLE_ORG_MODEdefaults totruewheneverPROLIFERATE_TELEMETRY_MODEis nothosted_product), so every account lands in the one instance organization. - The
ADMIN_EMAILSadmin floor is asserted at every sign-in, whichever method the user came in through. See Email & password for the full semantics, including lockout recovery. - Removal is durable: a member an admin removed stays removed, and signing in
again, through any method including SSO, gets a clear 403 instead of
quietly restoring access. The one exception is emails listed in
ADMIN_EMAILS, which are reinstated as admin at their next sign-in; that is the lockout recovery path, so offboarding a listed email means removing it fromADMIN_EMAILStoo.