Users, tokens, and access
People get accounts on Users. Automations get explicit service identities and raw credentials on Tokens. Roles belong to those principals, so issuing or revoking one credential never changes authority.
Invite a person
On Users, enter a login name and optionally an email address, then create the invitation. The link works once and expires after seven days. The person chooses a display name and password.
A password reset replaces pending invitations and signs out password and web sessions created with the old password. Disabling a user blocks sign-in and revokes all of that person's credentials immediately.
Create a service token
On Tokens:
- Enter a descriptive service identity such as
ci-release. - Optionally set an expiry in days.
- Create the token and copy it immediately; it is shown once.
- Store it in the CI secret store.
The name must not belong to a person. Reusing an existing service name creates another credential for the same service principal.
Assign roles
On Access, enter a principal name, choose a role, and optionally set a game, stream, and expiry. Server roles are server-wide. Maintainer roles can cover all games or one game. Tester and developer roles can also cover one stream.
Each exact principal, role, and scope has one row. Assigning it again refreshes that row instead of creating a duplicate. Only admins can assign or revoke roles.
The same page manages stream commit allowlists. * leaves a stream
unprotected. A comma-separated list protects it so only those principals can
commit, and only when they separately hold developer-or-higher access.
See Roles and authentication for the full model.
Revoke credentials or accounts
Choose revoke all next to a service identity on Tokens to invalidate all of its raw credentials. For people, use disable on Users so existing sessions are revoked and another login is blocked in one operation.