Roles & permissions
qRaptor uses role-based access control (RBAC) at two levels: your workspace and each project within it. Both use the same four roles — Owner, Admin, Developer, and Viewer — but they grant access to different things.
These roles govern people who build in qRaptor Studio. End users of a deployed vibe-coded app are managed separately — see Auth Settings.
Workspace-level roles
| Role | What they can do |
|---|---|
| Owner | Full control over the workspace — billing, members, roles, settings, and every project. |
| Admin | Manage members, roles, and workspace settings. Cannot manage billing or delete the workspace. |
| Developer | Create and edit resources and run agents across the projects they belong to. No workspace administration. |
| Viewer | Read-only access. |
Project-level roles
Within a project, each member holds one of these roles. The hierarchy is Owner > Admin > Developer > Viewer.
| Role | What they can do |
|---|---|
| Owner | Full project control, including deleting the project and transferring ownership. |
| Admin | Manage the team, settings, agents, deployments, and data. Cannot delete the project, transfer ownership, or change project roles. |
| Developer | Create/edit and run agents, and work with data and tables. Cannot delete or deploy agents, manage the team, or change settings. |
| Viewer | Read-only access to agents, deployments, and data. |
Project permission matrix
| Action | Owner | Admin | Developer | Viewer |
|---|---|---|---|---|
| Delete project / transfer ownership | ✓ | ✗ | ✗ | ✗ |
| Manage project roles | ✓ | ✗ | ✗ | ✗ |
| Manage team & invite members | ✓ | ✓ | ✗ | ✗ |
| Edit project settings | ✓ | ✓ | ✗ | ✗ |
| Create/edit agents | ✓ | ✓ | ✓ | ✗ |
| Run agents | ✓ | ✓ | ✓ | ✗ |
| Delete agents | ✓ | ✓ | ✗ | ✗ |
| Deploy agents | ✓ | ✓ | ✗ | ✗ |
| Manage data & create tables/queries | ✓ | ✓ | ✓ | ✗ |
| Delete tables/queries | ✓ | ✓ | ✗ | ✗ |
| Export data | ✓ | ✓ | ✓ | ✗ |
| View audit logs | ✓ | ✓ | ✗ | ✗ |
| View agents, deployments & data | ✓ | ✓ | ✓ | ✓ |
Assigning roles
To assign a project role:
- Navigate to Teams in the project sidebar.
- Click Invite Member.
- Enter the user’s email and select a role.
- Click Send Invite.
The user receives an email invitation and appears in the team list once they accept.
Role inheritance
- Workspace Owners automatically have Owner access to every project.
- Workspace Admins get implicit Viewer access to every project. Explicit project membership can raise this to a higher role — it is never lowered.
- Workspace Developers and Viewers only have access to projects they are explicitly added to.
Project ownership can only be held by the project creator or transferred by the current Owner — you cannot promote a member to Owner through the invite flow, and a project always keeps at least one Owner.
API key permissions
Deployments are also accessed programmatically with API keys, which carry their own scope rather than a user role. See API access for how to create and scope deployment keys.