Roles and Permissions

A role is a named set of permissions that decides what a member can do in your organisation. Every member has one role, and you can either use the built-in roles or define your own.

Built-in roles

Four system roles ship with every organisation and cover the common cases:

• Owner — full control of the organisation, including billing and ownership. Exactly one owner per organisation.
• Administrator — manage everything except organisation-level ownership.
• Member — read and update resources; no create or delete at the organisation level.
• Viewer — read-only access across the organisation.

System roles cannot be edited or deleted. To build on one, clone it into a custom role.

Custom roles

When the built-in roles are too broad, create a custom role with exactly the access a team needs — for example a "Deployer" who can manage containers but never touch billing or credentials.

Open User Management → Roles and create a role. You give it a name and then tick the permissions it should have. Permissions are organised as a simple grid:

• Resource — the kind of thing the permission applies to: containers, cron jobs, workers, Memcached, registries, secrets and the other vault items, configuration files, projects, members, and billing.
• Action — one of Create, Read, Update, or Delete.
• Scope — whether the permission applies across the whole organisation or within a project.

Tick the combinations you want, save, and the role is ready to assign. You can edit a custom role's permissions at any time, and the change applies immediately to everyone who holds it.

Assigning a role

Assign a role from the Users page — see Team Management. Owners and Administrators can change any member's role. The Owner role is never assigned directly; to hand it over, use Transferring Ownership.

Per-project roles

A member's organisation role is their baseline everywhere. Sometimes you want someone to have a different level of access in one specific project — more or less than their usual role. Assign them a project role from that project's members list, and it replaces their organisation role for that project only. Everywhere else, their organisation role still applies.

This lets you, for example, make someone a Viewer across the organisation but give them full control of a single project they own.

Sharing one resource

Roles grant access broadly. To give a member access to a single resource — one container, one registry — without changing their role, share it directly. See Sharing Individual Resources.

Managing roles as code

Custom roles can also be defined with the Terraform provider or the Reis CLI, so your access model lives in version control alongside the rest of your infrastructure.