Roles & Permissions

Roles are named bundles of permissions; users get powers through roles, not one-off grants. Manage them under Admin → Roles.

Prerequisites

• The role.create permission (or full administrator access).
• A clear idea of the job the role serves — see Design principles below.

Create a role

The role editor is one screen with three sections — Role details, Where this role applies, and What members can do — plus an Effective access summary that updates as you change them.

1. Open Admin → Roles and select Create role.
2. Role details — set a Name (for example Support L1) and an optional Description.
3. Where this role applies — pick one access boundary: Panel administration (panel-wide permissions only, no node or server access), Entire panel (every server on every node, including ones added later), Selected nodes (every server hosted on those nodes), or Specific servers. Search and tick the nodes or servers you mean.
4. What members can do — leave the Wildcard — All Permissions switch off and tick individual permissions, or start from a preset (Administrator, Moderator, Support, User) and adjust it; Clear empties the selection. The search box filters by name. Permissions are split into Resource permissions — granted only inside the boundary you chose — and Panel-wide permissions, which are always global. Permissions that installed plugins expose for roles appear in a Plugins group.
5. Select Create role (or Save changes when editing). The role is listed immediately; assign it to a user under Admin → Users.

Node access — which nodes members can reach at all, independent of the boundary above — is assigned after the role exists: edit the role and use the Node access block.

Edit role reopens the same editor. A role that still has assigned users cannot be deleted; remove or reassign those users first.

The Wildcard — All Permissions switch grants every current and future permission panel-wide and clears the boundary. Roles that hold it show a Full Admin badge in the list and Full Administrator Access in the detail view; do not hand that out casually.

Design principles

1. Least privilege. Start from nothing and add what the job needs. It is easy to grant more later; it is hard to un-see leaked data.
2. Job-shaped roles. Support L1 (view servers, restart, read logs), Billing (view users, no server control), Node operator (nodes only). Avoid one giant Staff role.
3. Separate read from write. Most incidents come from write access that was only ever needed for reading.
4. Review quarterly. Roles accrete permissions; audit who has what and trim.

API keys follow the same model

Admin-created API keys carry scoped permissions from the same catalog — a monitoring key gets read-only metrics, not server control. The exact strings are listed in Authorization & Permissions, served by GET /api/roles/permissions-catalog.

Dangerous combinations

• User management + server file access can become full account takeover paths.
• Backup restore + subuser creation can exfiltrate other users’ data.
• When a role needs a risky permission, time-box it: grant, do the task, revoke.

Related

• Creating and assigning users: users.
• Scoped API keys using the same permission catalog: API authentication.
• Built-in security controls and lockouts: security.