Permissions matrix

Documentation Index

Fetch the complete documentation index at: https://docs.rafftechnologies.com/llms.txt

Use this file to discover all available pages before exploring further.

_{Updated May 8, 2026} This page is the spec sheet for the 7 System roles that ship with every Raff account. The model itself is on Roles, scopes, and the Owner; read it first if you haven’t.

​

Account roles (3)

These apply to a member at the account level. Account roles control account-wide concerns: who’s invited, billing, audit log, account-wide API keys, the list of projects. They do not grant access to project resources. A member with only an account role cannot see VMs, VPCs, IPs, or any other project resource until they’re explicitly given a project role on that project.

​

Admin (15 permissions)

The “do almost anything at the account level except destroy things or touch billing” role. Use this role for ops people you want to run the account day-to-day but not pay invoices or remove the founders.

​

Billing (2 permissions)

A purpose-built role for finance / accounting people who only need to see and pay invoices. Everything else is denied. The Billing role explicitly cannot see members, projects, audit logs, or any account settings — keeps the finance person scoped exactly to invoices and payment methods.

​

Member (3 permissions)

The lightest account role. Read-only at the account level, useful as a base for someone who’ll mostly work inside specific projects. A typical pattern: invite a developer with Member at the account level (so they see who else is on the team and what projects exist), then grant them Project Member or Project Admin on the projects they actually work in.

​

Project roles (4)

These apply to a member on a specific project. Each grant pairs a member, a project, and one role — the same member can hold different roles on different projects. The exact counts shift slightly as new resources land (Object Storage, Kubernetes, etc.); the dashboard’s role-detail view is always authoritative. The categories below show the structure.

​

Project Admin (40 permissions)

Everything inside the project. The project-domain equivalent of “Owner without account access.” Use Project Admin when you want a member to fully run a project — VMs, networking, members, settings — without giving them anything at the account level.

​

Operator (~29 permissions — manage without delete)

Identical to Project Admin except destructive operations are removed: no vm.delete, no vpc.delete, no project.members.remove, etc. Operators can power, manage, and create — but not destroy. Useful for on-call rotations, deploy automation, and contractors who shouldn’t be able to wipe things out by accident.

​

Project Member (~11 permissions — basic access)

A normal “use the project” role:

• project.settings.view, project.members.view
• vm.view, vm.power (start/stop/reboot a VM)
• A handful of read permissions on other resource types

The default level for most engineers — they can see everything in the project and do day-to-day operational tasks (reboot a VM, view logs/metrics) but they can’t create, delete, or modify configurations.

​

Viewer (~9 permissions — read-only)

Pure read access. View VMs, view VPCs, view IPs, view members, view project settings — no power actions, no creates, no deletes, no console access. The right role for compliance / audit team members and read-only dashboards.

​

Cross-domain mix examples

A few common patterns built from the table above: The “External customer” pattern uses the Project-only scope you see on the Members list — no account role, project roles only. Useful for white-labeled hosting, multi-tenant isolation, or any case where the member shouldn’t see anything outside their project.

​

What you can’t change about System roles

System roles are read-only. The role-detail dialog shows the toggles but doesn’t accept changes. Specifically:

• You can’t add or remove a permission to/from a System role
• You can’t rename a System role
• You can’t delete a System role
• You can copy a System role’s permissions into a fresh Custom role and edit from there

​

Limits

​

See also