Account Auto-Provisioning

Auto-provisioning is how Operaide creates a user account on first contact, without an admin pre-inviting the user. Every enabled login path that can generate a new account consults the same per-organization emailDomainRegex setting to decide which organization the new account joins.

This page covers the rule, the four paths that trigger it, how to configure the regex, and common pitfalls. Individual login setups (SSO, External Password Login, Iframe Login, Self-Signup) reference this page for the shared mechanics.

The rule

On any first sign-in, Operaide looks for an organization whose emailDomainRegex matches the user's email address. The new account is attached to the first matching organization. If no organization matches, the sign-in fails silently and no account is created.

The regex is checked once, at account creation. Changing the regex afterwards does not move existing accounts.

The four paths that trigger auto-provisioning

Path	Trigger	emailDomainRegex consulted?
SSO	First successful sign-in at the OIDC provider	Yes
External Password Login	First successful 200 OK from the backend	Yes
Iframe Login	First successful 200 OK from the profile URL	Yes
Self-Signup via /register	User submits email and password on the registration page	Yes

All four paths share the exact same regex check. Tightening the regex tightens every path at once.

What does not trigger auto-provisioning

• Invitation links from MemberManager. The inviter picks the organization explicitly, so no regex is needed.
• Re-login for an existing account. The regex is consulted only at account creation.

Where emailDomainRegex lives

Two places, with different roles:

Setting	Scope	When it applies
ORGANIZATION_EMAIL_DOMAIN_REGEX env var	Deployment	Copied onto the first organization when the instance is first created. Consulted only once, at bootstrap.
emailDomainRegex field on each organization	Per-organization	Edited in the UI under Organization Settings, then Registration. This is the value checked at every first sign-in.

Fresh instances ship with the primary organization set to emailDomainRegex = .* so the very first sign-in succeeds and bootstraps an admin. Tighten the per-organization field afterwards.

Per-user organizations

By default, a sign-in whose email matches no organization fails (see When auto-provisioning fails silently). The CREATE_NEW_ORGANIZATION_FOR_EVERY_NEW_USER env var changes that outcome.

Value	Behavior on no match
false (default)	Sign-in fails. The user joins an organization only through a matching emailDomainRegex.
true	Operaide creates a fresh organization for the user and makes them its first member.

A matching organization always takes precedence. The new organization is created only when no organization matches. Use true for deployments where each user is their own tenant.

Deployment shapes

Shape	Settings	emailDomainRegex role
SSO-only	AUTH_OPENID_ENABLED=true, NO_REGISTRATION=true (production default)	Governs SSO auto-provisioning.
External-Password-only	AUTH_HTTP_BASIC_ENABLED=true, NO_REGISTRATION=true	Governs the backend-driven auto-provisioning.
Iframe-only	AUTH_BEARER_ENABLED=true, NO_REGISTRATION=true	Governs the iframe-driven auto-provisioning.
Public self-signup allowed	NO_REGISTRATION=false	Governs who on the internet can register. Must be tight.
Mixed	Any combination	The same regex applies to every enabled auto-provisioning path; tighten for the broadest one.

Tightening after bootstrap

Once an admin exists, set the per-organization regex to the domains your company actually uses. Example for a company with .com and .de domains:

^.*@company\.(com|de)$

Users whose email matches land in that organization. Users whose email does not match fail silently at sign-in. Adjust the regex, or add a second organization with its own regex, to cover additional domains.

When auto-provisioning fails silently

Symptom: the user completes the external sign-in (SSO redirect succeeds, password form accepts the credentials, or registration form submits), but no account appears and the UI does not show a specific error.

Cause: no organization has an emailDomainRegex that matches the signing-in email.

Fix: open Organization Settings, then Registration, and review the regex on every organization. On a fresh instance, setting the primary organization to .* unblocks the first sign-in; tighten it afterwards.

Common mistakes

• Tightening the regex before the first admin signs in. A regex that does not match the admin email locks everyone out on a fresh instance. Start with .*, let the first sign-in land, then tighten.
• Leaving NO_REGISTRATION=false on a public deployment with a permissive regex. Anyone on the public internet can self-register through /register. For SSO-only or External-Password-only deployments, set NO_REGISTRATION=true.
• Expecting the regex to move existing accounts. Changing the regex only affects accounts created after the change. Existing accounts keep their organization membership.
• Mixing login paths without tightening the regex. Enabling Self-Signup alongside SSO widens the attack surface: a permissive regex that was fine for SSO-only can now let anyone on the internet register. Re-evaluate the regex when enabling a new auto-provisioning path.