Roles & permissions
Thirty-eight permissions, each with a View and a Manage half, grouped into Server, Application and Integrations.
A role is a named set of permissions. Users hold roles; roles hold permissions; permissions are what the panel actually checks. Nothing in OSS Panel grants a permission to a person directly.
The catalog
There are 38 permissions, and the list is fixed — it ships with the build rather than being something you author. The role editor groups them exactly as the sidebar is grouped:
| Group | Count | What it covers |
|---|---|---|
| Server | 17 | The screens that act on the machine: Dashboard, Applications, Databases, System Users, Firewall, Cron Jobs, Fail2ban, System Logs, Services, PHP, Node.js, Docker, Settings, Disk Cleaner, Backups, Activity Log, Server Sync. |
| Application | 18 | The sidebar inside one application: Dashboard, Domains & SSL, Deployments, Environment, Container, Compose File, Workers, Files, Logs, Backups, PHP Settings, Password Protection, 8G Firewall, AI Bot Blocker, Fail2ban, Staging Area, Site Clone, Magic Login. |
| Integrations | 3 | Git, Storage, Docker Registries. |
Two pairs share a label and mean very different things, so read the group before the word:
- Server Fail2ban bans addresses across the whole box; application Fail2ban is one site's jail.
- Server Firewall opens and closes ports (ufw); application 8G Firewall inspects requests. Turning on the second does not close anything.
Magic Login is the one permission that is not a sidebar entry — it is the button that drops you into a WordPress site as its administrator, and it has its own permission precisely so that "can look at this application" never silently becomes "can log in to it as admin".
View and Manage
Every permission has two independent halves, and the editor states the rule at the top: "View lets them look. Manage lets them change things too. Both off and they can't see it at all."
- Neither — the screen is not in their sidebar, and the URL answers with the permission-denied card.
- View only — they can open it and read it. Every button that writes is gone.
- View + Manage — the full screen.
Manage without View is not a meaningful combination; grant View alongside it.
Create a role
Press New role. The form is two cards: the name and description, then the whole catalog.
Name it after the job, not the person. The description is optional but it is the only thing shown next to the role in the list and in the user dialog, so a sentence about who this is for earns its place.
Tick what the role may reach. The counter at the top of the card — "22 of 38 enabled" — is the quickest check that you granted what you meant to.
Each group header has a Set all pair that ticks or clears the whole group in one go, and the All permissions row at the top does the same for everything. Both render as a dash when the group is partly on.
Check the application half separately. Server Applications controls the list of sites and the create button; the 18 Application permissions control what you see once you are inside one. A role with server Applications and nothing in the Application group can create a site it then cannot open.
Press Create role. It appears in the list with its permission count.
Edit a role
The … menu on a role row holds Edit and Delete.
Editing is the same form, pre-ticked. Changes apply the moment you save — to everybody holding the role, including anyone signed in right now. A permission removed while somebody is looking at that screen takes effect on their next request.
The Administrator role is protected
Administrator carries the System badge and all 38 permissions, and it cannot be renamed, re-permissioned or deleted. Both menu items are disabled on its row:
The API refuses the same two operations independently, so there is no way round it with a hand-made request. This is what guarantees that an install always has one role that works.
Deleting a role
The dialog describes the ordinary case: users who hold other roles too simply lose this one, and their accounts remain. But the panel refuses outright if the role is anybody's only role, and names them:
That guard exists because the alternative is silent: the assignment rows would cascade away, and the user would keep their login while losing every permission, with nothing on screen explaining why. Give them another role first, then delete.
Sync permissions
The toolbar's Sync permissions button reloads the catalog from the application and re-grants the full set to Administrator.
You need it rarely — an update that adds a permission normally seeds it — but it is safe to run at any time, and it does not touch the choices you made on your own roles. If a new feature's screen is missing from the role editor after an update, this is the button.
Limits worth knowing
- Roles are server-wide. There is no way to scope a role to one application or one database.
- The catalog is the build's, not yours. You cannot add a permission, only combine the 38 that exist.
- Permissions combine, never subtract. Two roles grant the union. There is no "deny" that overrides a grant.
- Some permissions are hidden on some servers. Docker Registries is dropped from the catalog on a server that hosts no containers, so on a PHP-stack box that screen reports a permission problem even for an administrator — see Docker Registries.