
Two separate permission systems — Account and Project
Raff splits permissions into two independent systems. They look similar in the UI but they cover completely different things, and granting one does not grant the other.
A member’s grants are tracked separately in each system:
- Account roles are assigned once per member at the account level — they apply across the whole account
- Project roles are assigned per project — the same member can have
Project Adminoncustomer1andVieweronstaging, or no project role at all
Admin account role and no project roles can invite members, manage billing, see the list of projects’ names — but they cannot list VMs, see VPCs, or open any project’s resources. Project access has to be granted explicitly, per project.
The Owner is the only exception: granted automatically at signup with full access in both systems on every project, current and future. Every other member you invite is scoped narrower than that.
The Members list shows where each member sits with badges:
Projects — the unit of access control
Every resource on Raff lives in a project. VMs, volumes, public IPs, VPCs, Object Storage buckets — all of them are scoped to one project at creation time. Projects are how access control gets fine-grained.
- Every new account starts with a
Defaultproject. It’s pre-created at signup and used for any resource you create without picking a project explicitly. The Default project cannot be deleted — it’s the always-available fallback. - You can create more projects.
+ Create Projectfrom the Projects tab. Use them to isolate customers, environments (prod/staging), teams, billing entities, anything where access should be partitioned. - Single project is fine. If you don’t need access partitioning, leave the Default project as your only project and forget about it. The account works the same way.
- Resources never leave their project. A VM created in
customer1stays incustomer1. Today there’s no “move to another project” action — recreate elsewhere if you need to relocate.
How users switch projects
The top bar of the dashboard has a project picker next to the account name. Members with access to multiple projects use this to scope the dashboard to one project at a time.
customer1 is selected creates the new VM / volume / IP inside customer1.
What you can do
API keys are managed in a separate left-sidebar item, API Keys, not on the Team & Projects page. They’re tied to your account and inherit the scope you give them at creation.
Most viewed
Invite a member
Add a teammate at account or project scope.
Create a project
Group resources into a new project.
Roles, scopes, and the Owner
The Account vs Project permission model.
Generate an API key
Create a key for programmatic access.
Browse
Quickstart & guides
Members, roles, API keys.
Concepts
Account vs project scope, roles, API key scope.
Details
Permission matrix and limits.
Troubleshooting
Common access issues.
Authentication
API key authentication reference.
Changelog
All API updates and changes.