Roles and permissions

Everyone you invite gets a role. The role decides what they can do; it is not a label.

The five built-in roles#

What each role can actually do#

Owner and Admin hold every permission. The other three are exact:

DevOps#

Servers (view, manage, delete) · Projects (view, create, deploy, delete, protect, restart) · Domains (view, create, delete) · SSL issue · Nginx reload · Firewall · Backups · Services install · Logs · Dashboard · Alerts (view, manage) · Audit view · Automation · Team (view, manage)

Developer#

Servers (view) · Projects (view, create, deploy) · Domains (view) · Logs · Dashboard · Alerts (view) · Audit view

Notably not: deleting servers or projects, firewall, backups, SSL, or managing the team.

Viewer#

Servers (view) · Projects (view) · Domains (view) · Logs · Team (view) · Dashboard · Alerts (view) · Audit view

Viewer can read the audit log. That is intentional — being able to see what happened is not a privileged action.

Picking one#

• Someone who deploys but should not be able to take a server down → Developer.
• Someone on call who needs to fix infrastructure → DevOps.
• A contractor, auditor, or stakeholder who should see but not touch → Viewer.
• Reserve Owner for the people who would be responsible for the bill and the business.

The useful question is not "how senior are they" but "what should they be able to do at 3am without asking anyone".

Scoping to specific servers#

A role says what someone can do; server scope says where. You can restrict a person to specific servers, so a Developer on the staging box cannot deploy to production even though their role permits deploying.

Set the scope when you invite them or afterwards from the team list.

You cannot grant a role above your own#

Someone with permission to manage the team cannot use it to promote themselves or anyone else beyond what they hold. A DevOps user cannot mint an Owner.

This applies to both adding a member and creating an invite, so it cannot be sidestepped by inviting a new account instead of promoting an existing one.

Custom roles#

Beyond the five built-ins, an organisation can define its own roles from the same permission list. Start from the closest built-in and remove what is not needed — building up from nothing tends to produce a role that cannot do its job until somebody adds server.manage to make the error go away.