Users and sign-in (operator)
For whoever runs the box. Most people only need to know where to sign in.
The switch that changes the model
Section titled “The switch that changes the model”A Lowkey box can run in two sign-in models.
With multi-user off, the box uses one shared sign-in. The login page asks for the box password, and requests run as the operator account.
With multi-user on, the box has a roster of people. Each person signs in as
their own user, and Lowkey can attach requests to that signed-in user. The
setting behind this is the daemon config feature flag features.multiUser. If
that flag is off, Settings -> Users shows a notice instead of the roster.
Where you manage people
Section titled “Where you manage people”Open Settings -> Users. This page is the access list for the box: anyone not listed there cannot sign in, even if they can complete an identity-provider login.
From there you can add a person in either of the supported account styles:
- Google / SSO: enter the person’s email, optional display name, optional handle, and role. The Settings form labels this path Google today; the daemon identity model also knows Microsoft and generic OIDC. They sign in through the configured provider, and the identity links itself on first login.
- Local: create a username and initial password. The username is also the
person’s
@handle. Local usernames must start with a letter and can use lowercase letters, digits,_,., and-. Initial passwords must be at least eight characters.
For local accounts, the form includes Require a password change on first sign-in. Local email is display only; it is not verified by a provider.
How people sign in
Section titled “How people sign in”The login page chooses the right form from the box’s current mode.
If multi-user is off, it shows the shared password form. If multi-user is on and
auth.mode is local, it asks for username and password. If multi-user is on
and auth.mode is oidc, it shows sign-in buttons that send the browser to the
configured identity-provider flow, including Google.
In SSO mode, Lowkey trusts the verified identity headers from the front-door auth layer, then matches that email or identity against the roster. That means adding someone in Settings -> Users is still the access decision. Signing in with the right Google or SSO account is not enough if the person is not listed.
Staying in control
Section titled “Staying in control”Treat the user roster like a keyring for the box. Once a listed account passes its local password or identity-provider check, Lowkey accepts it as that person for the box. Add people you trust with the box, not strangers who need hard separation from each other.
You cannot remove the operator user from the roster. The Settings page also prevents removing yourself, so there is always a way back in from the active session.
If you expose the box beyond localhost, keep the auth gate in mind too:
authGate.mode can be off, log, or enforce. In enforce mode, regular web
and API traffic must have a valid app session or API key; login and health
routes stay open enough for sign-in and readiness checks.
What to read next
Section titled “What to read next”- Standing up the box ->
/operator/provisioning/ - Connecting providers ->
/operator/providers/ - Sharing a project with people ->
../multi-user.md