docs Users & RBAC
Users & RBAC
Two layers of roles: a global role for the instance and a role per project.
How Access Works
Every user has a global role (Admin, Operator or Viewer) and, separately, a project role on each project they are a member of. The global role governs instance-wide actions; the project role governs everything inside a project. Project membership is required: a global Operator or Viewer who is not a member of a project cannot see it at all, and the project does not appear in their list.
Global Roles
Admin
Superuser. Is Admin on every project automatically (this cannot be lowered per project). The only role that can manage users, servers and SSH keys, delete projects, read the audit log, register the GitHub App, export or import the whole instance, and change instance settings.
Operator
Can create projects (and becomes Admin of the projects they create) and create or edit alert rules (deleting them is Admin-only). Required, together with a project role of Operator or Admin, to edit project settings and the status page, open a web terminal, define or run scheduled tasks, manage notification channels, and use game server consoles, files and mods.
Viewer
The default for new users. No instance-wide permissions. What they can do inside a project depends entirely on their project role — but actions that also require a global Operator role (project settings, terminal, tasks, notifications, game server console and files) stay off-limits even if they are project Operators.
Project Roles
Each level includes everything from the level above it in this table:
| Role | Can do in the project |
|---|---|
| Viewer | See the project, its applications, stacks, databases and game servers, with their deployments, logs, metrics, backups lists and task runs. Environment variable values, connection strings, task output and game server files are hidden. |
| Operator | Create, configure, deploy, roll back, start and stop apps, stacks, databases and game servers; edit environment variables and domains; manage backups (including restore); toggle maintenance mode; read secrets, task output and export the project configuration. |
| Admin | Delete applications, stacks, databases and game servers, and add, change or remove project members. |
When a user without access to a project requests one of its resources, the API answers "not found" rather than "forbidden", so ids from other projects reveal nothing.
Managing Users and Members
- The first account registered on a fresh instance becomes the global Admin; after that, public registration is closed
- Global Admins create users, change their global role, reset their passwords and delete them from the Users page (you cannot change your own role or delete yourself)
- Project Admins add existing users to a project with a role, change it, or remove them from the Members section of the project page
- Global Admins cannot be added as members — they already have Admin on every project
- Every user can change their own password and email from the Settings page
- Role changes take effect on the next request; the role is read from the database, never from the token
Example: to let a contractor deploy one app without seeing anything else, create them as a global Viewer and add them as Operator on that project only. They can deploy and configure that project's apps, but cannot open a terminal or run tasks — that needs a global Operator role as well.
Authentication
DeployKit uses JWT authentication with short-lived access tokens (15 minutes) and refresh tokens (7 days). Refresh tokens are stored in Redis and rotated — each use issues a new one and revokes the old. Passwords are hashed with bcrypt and must be at least 8 characters. Login and registration are limited to 10 attempts per minute per IP.