TEAM & ACCESS

Roles and permissions

The two permission catalogs, the built-in roles, and how to build a custom role that fits your org.

DockBoard has two permission systems, deliberately separate. Project permissions decide what you may do inside a project. Platform permissions decide what you may do to the install. Someone can be a full administrator of their own project and hold nothing at all at the platform level.

Project permissions

A permission is a resource:action string. view reads; manage — or a finer verb — mutates. The finer verbs exist so a role can grant “can deploy but not delete”:

Resource	Actions
`apps`	`view` `create` `deploy` `restart` `delete` `env` `exec` `logs`
`databases`	`view` `create` `manage` `delete`
`instances`	`view` `create` `manage` `ssh` `delete`
`domains`	`view` `manage` `delete`
`backups`	`view` `create` `restore` `delete`
`files`, `sftp`, `email`, `protection`, `quotas`	`view` `manage` (`quotas` grants `view` widely, `manage` narrowly)
`monitoring`, `deployments`	`view`
`marketplace`	`install`

Three of these are worth pointing at directly, because they are bigger than they look:

apps:env: Reads and writes environment variables — production secrets. Deliberately absent from the read-only role: seeing an application does not mean seeing its credentials.
apps:exec: Opens a shell in the container. That shell can read the whole environment, so this permission implies everything apps:env grants, whether you granted it or not.
instances:ssh: A root shell on a Linux instance. Split out from manage so a role can grant restart-and-resize without a shell on the machine.

The four built-in roles

Role	Holds
VIEWER	Every `:view` permission, nothing else. Reads everything, mutates nothing, and never sees secrets.
DEVELOPER	The whole build-and-ship surface: applications, domains, databases, files, SFTP, backups, marketplace installs, per-app protection. Sees the project’s quota but cannot change it. No member or role administration.
ADMIN	Every fine-grained permission, plus member and role administration and project settings.
OWNER	ADMIN, plus the two things only an owner may do: delete the project and transfer it.

Custom roles

A custom role is any subset of the grid above, saved under a name of your own. Start from a built-in preset and adjust. The shapes people actually build:

A deployer — apps:view, apps:deploy, deployments:view. Ships code, cannot read secrets or delete anything.
A database operator — the databases and backups verbs, nothing on applications.
A support account — every :view except apps:env, so someone can diagnose without holding your credentials.

Four capabilities are never delegable to a custom role: deleting the project, transferring it, managing members, and editing roles. A permission grid that could grant “edit roles” could grant itself anything else in one step, which would make the whole grid decorative.

A custom role carries a base rank. It can raise a member’s fine-grained grants, but never their administrative rank above that base — so a custom role built on DEVELOPER cannot become an administrator by accumulating permissions.

Platform permissions

A second, independent catalog gating the Admin console: users, projects, servers, config, updates, audit, docker, monitoring, quotas, license — each with view and manage, plus users:assist for password resets and reactivations without full user authority.

Four shipped presets cover the usual shapes:

Full: Everything, stated explicitly.
Support: See and assist users; read-only on projects and the audit trail.
Infra: Servers, Docker, monitoring. No authority over users or configuration.
Read-only: Sees everything, changes nothing.

Resolution, in order: a SUPERADMIN always holds everything. An administrator with a per-user grid holds exactly that grid. An administrator with an assigned admin role holds that role’s grid. An administrator with neither holds everything — so existing installs keep working, and scoping an administrator down is an explicit act rather than a silent side effect of an upgrade.

license:manage is its own resource rather than part of config. Removing the key downgrades the whole install to the free tier — every Pro feature off, for every user, at once — and that is not something a support desk or an infra operator has any reason to touch.

An API key is bounded by both systems at once: it can never exceed its owner’s permissions, and its own scopes narrow it further. Two ceilings, and the lower one always wins.