Roles and permissions

What each person can do is decided by a role or a folder share.

A capability is one action: deploy_apps, delete_apps, manage_domains, restore_backups. There are 45: view, which every member has, and 44 you grant one by one, so you never give more than needed.

A role belongs to your team. Every team starts with three, which you can rename, change and later reset to the default:

Editing a role updates everyone holding it at once. There is no separate "apply" step.

A folder share does not edit a role: it replaces the role inside one folder. See Folder shares.

Special capabilitiesCopy Anchor Link

• view is always on. Every member has it.
• instanceAdmin is not a team capability. It unlocks Servers, Users and the instance settings. Another instance admin grants it from the member's Advanced tab.
• canExposePorts and canMountHostVolumes are separate grants. The second one covers every way out of a container, not only a bind mount. See Host access.

Good to knowCopy Anchor Link

• Hidden buttons are not the security check. The server checks every action, and the API and the MCP server go through the same checks.
• A role edit applies immediately to everyone holding it.
• A team can never lose its admins. manage_members, manage_roles and manage_team must always have at least one holder.
• An id from another team gives no result, for security reasons.
• API tokens are limited by their creator. A token can never do more than the person who created it can do right now. Narrowing someone's role also narrows every token they created.

TroubleshootingCopy Anchor Link

• A capability is greyed out while editing a role: you do not have it yourself.
• Somebody still cannot do something: check for a folder share on that folder, which replaces the team role there, and check whether the team requires two-factor.
• They can do more than their role says: a folder share is granting it. Their member page shows the scope tree.

See Sign-in and access for more.

Next stepsCopy Anchor Link