Users and Roles

Four roles, all except Admin scoped to the server connections you assign them:

Role	Can do
Admin	Everything, including settings and user management
Viewer	Read-only, on assigned servers
Bot Operator	Viewer, plus full control of Bot Flows and Music Bots on assigned servers
Music Operator	Viewer, plus Music Bots only

Assign which servers a non-admin may see per user, in Settings → Users → Server Access. Without at least one assigned server they will see nothing after logging in.

Safety rails, enforced on the server and not merely hidden in the UI: an admin cannot remove their own admin role, disable or delete their own account, and the last remaining active admin cannot be demoted, disabled or deleted by anyone.

Sign-in options: local accounts, two-factor authentication (TOTP with one-time recovery codes, optional for every role, with a 15-day trusted-device option), and Single Sign-On through any standard OpenID Connect provider — Authentik, Keycloak, Authelia, Zitadel and others — configured under Settings → SSO. A first-time SSO login is always created as a Viewer; promote manually.

What each role sees

The navigation only offers what a role may use, and the backend enforces the same limits itself: a page that is hidden from a role is refused to it on the API as well - reads included, not only changes - so a Viewer or an operator cannot get at it by calling the address directly.

Viewer — the Dashboard, Channels, Clients and Icons pages, all read-only, and their own Settings → Account and WebGui tabs.
Music Operator — the same, plus Music Bots (Music Bots), including the library, playlists and radio stations.
Bot Operator — the same, plus Bot Flows (Bot Flows).
Admin — everything else: Virtual Servers, Statistics, the Client Database, groups, Permissions, bans, tokens, the Connection Journal, the Change Log, Files, Complaints, Offline Messages, Server Logs, the Query Console, Instance, Advanced Settings and the music request history, and all of Settings.

Changes made through the interface, by any role, land in the Change Log - including attempts the role check refused, which show there as denied (what is left out). While it is switched on, a change to users, roles or server access is refused if its entry cannot be written.

A server connection added without an API key offers only the music bots and what runs over the voice connection, whatever the role — see Getting Started.

Managing users

Settings → Users (admins only) lists every account with its role, whether it is enabled, and when it last signed in. Accounts that come from single sign-on carry an SSO badge.

Add User asks for a username, a display name, a password and a role (Viewer by default).
The role is a menu in the row, Enabled a switch: a disabled account cannot sign in. On your own row both are locked.
The row's buttons: Edit (username and display name), Server access (only for non-admins — an admin sees every server), Sessions, Reset password (at least 6 characters; it replaces the password at once) and Delete, which asks first and is permanent.
Sessions lists one entry per device or browser the account is signed in on. Revoke forces that device to sign in again; Revoke All does it for all of them. Revoking your own current session signs you out too.

Your own account

Settings → Account, for every role:

Change Password: the current password, then the new one twice (at least 6 characters).
Two-Factor Authentication: a one-time code from an authenticator app (Google Authenticator, Authy and similar) on top of the password.
1. Enable 2FA shows a QR code to scan — or a key to type in by hand — and asks for the 6-digit code the app then shows.
2. After that you get ten recovery codes, shown once. Each can be used one time instead of the 6-digit code, if the authenticator app is lost. Save them somewhere safe before you close the dialog.
3. At sign-in the code is asked for after the password. Ticking Remember this device for 15 days skips the code on that browser until then.
4. Disable 2FA asks for your current password and removes the recovery codes and the remembered devices too.

The interface language is also personal: see Themes and Appearance.

Setting up Single Sign-On

Under Settings → SSO, point the app at any standard OpenID Connect provider:

Issuer URL — the provider's base URL. Its discovery document must be reachable at {issuer}/.well-known/openid-configuration; everything else is read from there, so you don't configure individual endpoints.
Client ID and Client Secret — from an OIDC client you register at the provider. Leave the secret blank when editing later to keep the stored one.
Button label — the text on the sign-in button (e.g. "Sign in with Keycloak").
Redirect URI — register the value the page shows, {your-origin}/api/auth/oidc/callback, at your provider. It must match exactly, including scheme and port. The page shows the address of the tab you are looking at, but the backend builds the address it really sends from its FRONTEND_URL setting, so that setting has to be your public origin too (Configuration, Deployment).

Then enable it. A first-time SSO login always lands as a Viewer with no server access — promote them and assign servers manually afterwards. This is deliberate: it means simply having an account at your identity provider never grants access to a server on its own. Local username/password sign-in stays available next to it.

v0.6, last edited 27.10.2026