Roles & Access
Every page in Panelica shows a different thing to a different person. A reseller sees their customers; a customer sees only themselves; an administrator sees their slice of the tree; ROOT sees the server. This page explains the model once, so the rest of the documentation can simply say "scoped by role" and you already know what that means.
Four layers decide what any given account can see and do, and they stack: role, data scope, permissions, and license, with High Security Mode as an optional fifth gate for the most dangerous pages.
The four roles
- ROOT is the server owner. There is normally one. ROOT sees every account (except other ROOTs), browses the real filesystem, restarts services, and reaches server-only tools like the Virtual Desktop, Web Terminal and MySQL Tuner. ROOT also bypasses the permission layer entirely: no page or feature can be switched off for ROOT.
- ADMIN manages a branch of the tree: the users it created, plus the users created by its own resellers (two levels deep). An admin does not see ROOT's own resources or a sibling admin's users.
- RESELLER is the hosting-business role: it creates and manages its own customers (USERs) and their sites, within the quota its own plan grants.
- USER is the hosting customer. It sees exactly its own domains, mailboxes, databases and files, and nothing about the server or its neighbors.
created_by / parent_user_id chain in the database, and it is enforced server-side, not by hiding buttons. Every listing endpoint runs the data through a role filter (internally GetAllForUser(userID, role)): ROOT gets everything, ADMIN gets its two-level chain, RESELLER gets its direct customers, USER gets rows where user_id is its own. Hand-typing an ID you should not see returns nothing, because the filter is in the SQL, not the UI.Data scope, with an example
Consider one File Manager, opened by four people, and what each one's world looks like:
| Role | Opens at | Sees |
|---|---|---|
USER john |
/home/john |
only john's own home, jailed |
| RESELLER | /home |
only its own customers' home directories |
| ADMIN | /home |
the users in its created-by chain, plus a chown tab |
| ROOT | / |
the whole server (minus a few protected paths) |
The same pattern repeats everywhere: a USER on the Databases page sees only their own databases; a RESELLER on WordPress sees only their customers' sites; an ADMIN on Users sees only the accounts it created. You will see this described throughout the docs as "scoped by the RBAC chain", and this table is what it means.
Permissions: pages and features (and they are editable)
Roles are the default, not the last word. Panelica splits access into two permission kinds, both editable by ROOT from Page Permissions:
- Page permissions decide whether a role may open a page at all. Each page ships with default roles; for example email accounts, forwarders and autoresponders default to all four roles, while the mail queue, spam filters, routing, mailing lists and email settings default to ROOT and ADMIN only.
- Feature permissions decide individual actions inside a page: create a database versus delete one, issue an SSL certificate versus revoke it, install a Node version versus just use it. Buttons you lack are hidden, and the action is refused again server-side if you reach for it directly.
License feature locks
Above permissions sits the license. Whole subsystems (email, Node.js, Python, Docker, Git, the file manager, WordPress toolkit, spam filtering) are licensed features. When the license lacks one, the page does not vanish: it renders behind a premium-feature overlay (recent builds show an upgrade dialog), so operators can see what an upgrade would unlock. A licensed feature still obeys the role and permission layers underneath it.
High Security Mode: 2FA for the dangerous pages
The final, optional gate protects the handful of pages where a hijacked ROOT session would be catastrophic. When a ROOT operator enables High Security Mode under Security, a defined set of pages demands a fresh 2FA verification for the current session before it will open, and this applies to ROOT only:
- Web Terminal, Virtual Desktop, Package Manager and the Developer API page are blocked until the session is verified with a current 2FA code.
- The File Manager is restricted rather than blocked: without verification ROOT is confined to
/home(no/etc,/opt,/var,/root), and a valid code restores full filesystem access.
The point is defense against a stolen cookie: possession of a ROOT session alone no longer opens a root shell or reads /etc. With the mode off (the default) these pages behave normally for ROOT. Enabling the mode requires 2FA to be set up first, and disabling it asks for a 2FA code.