Roles and Permissions

Devpilot uses a two-layer access model. Every member holds a workspace role that sets their default authority across the whole workspace, and they can also be given resource-level roles on specific servers, projects, apps, and artifacts when you want scoped collaboration. This guide walks you through both layers, what each role can actually do, the reusable permission bundles you can build on top, and the tools Devpilot gives you to review and troubleshoot access.

Workspace Roles

Every workspace member has exactly one workspace role. Devpilot ships with three, and these are the only workspace-level roles available:

Each member also has a status: Active, Pending, Suspended, or Inactive. Only Active members can actually exercise their role. Pending, Suspended, and Inactive members are blocked from every action until their status is restored.

Resource-Level Access Roles

On top of the workspace role, Owners and Admins can grant scoped access to individual resources. Each grant pairs a resource (a server, project, app, or artifact) with one of four resource-level roles:

Workspace Owners and Admins are automatically treated as Admin on every resource in the workspace, so they never need individual grants. Members start with no access to any resource and only get access when it is granted to them.

Resource Types

Resource-level access can be granted on five resource types:

• Workspace — workspace-wide settings.
• Server — compute instances connected to the workspace.
• Project — logical groupings of related apps.
• App — individual applications inside a project.
• Artifact — build artifacts, backup archives, and other generated assets.

What Each Role Can Do

Here's what the resource-level roles translate to in practice on each resource type. Remember: workspace Owners and Admins have Admin-equivalent rights on all of these automatically, and the None role blocks everything.

On a Workspace

Workspace Admins can view workspace settings and change them. Collaborators and Viewers can see the workspace but cannot edit its settings or delete it.

On a Server

Admins can do everything with a server — view it, add new servers, edit its configuration, update it, and remove it. Collaborators and Viewers can see the server and its status but cannot create, edit, or delete servers.

On a Project

Admins can create, edit, update, and delete projects. Collaborators can view a project and edit its contents as part of their day-to-day work, but cannot delete it or create new projects. Viewers can see the project but not change anything.

On an App

This is where the roles have the most detail, because apps are where most of the activity happens.

In short: Admins can do anything to an app. Collaborators can deploy and tune deployment configuration but cannot create or delete apps, edit hook scripts, or change environment variables. Viewers can watch what's happening but cannot touch anything.

On an Artifact

Admins can view artifacts, create new ones, edit them, and delete them. Collaborators can view artifacts and create new ones (for example, generating a backup), but cannot edit existing artifacts or delete them. Viewers can only see them.

How Workspace and Resource Roles Interact

When Devpilot decides whether someone can do something on a resource, it looks at both layers:

1. Owners and Admins at the workspace level automatically have Admin-equivalent access on every resource. They do not need individual grants.
2. Members need an explicit resource-level grant of Admin, Collaborator, or Viewer to work with a specific server, project, app, or artifact. Without a grant, they effectively have None on that resource.
3. Overrides let you set a specific role for one member on one resource, replacing the role they would otherwise inherit. Overrides are clearly marked so you can tell at a glance which grants have been customised.
4. Inheritance lets a member's access to a parent resource flow down to its children — for example, their role on a project can carry over to every app inside that project — so you don't have to grant each child resource one at a time.

Custom Permission Sets

Owners and Admins can build custom permission sets — named, reusable bundles of resource-level access that can be applied to a member in one step. They're handy for role patterns that don't map cleanly to the built-in roles, like a "deployment operator" or a "read-only auditor", and they keep provisioning consistent across lots of members.

Each set shows a count of what's in it and a preview, so you can see exactly what it does before applying it.

Assigning and Updating Permissions

Owners and Admins have several ways to shape a member's access:

• Assign permissions — push a full bundle of access (across servers, projects, and apps) to a member in one go, with any conflicts flagged for you.
• Bulk update — change many grants at once in a single operation.
• Review the access matrix — see every grant a member has, grouped by resource type.
• Preview before committing — submit a proposed set of changes and see the resulting access and any conflicts without actually applying anything.
• Set an override — force a specific role on a specific resource for one member, clearly flagged as an override.
• Enable inheritance — point a child resource's grant at its parent so the child inherits the parent's role.

Access Requests

A Member who needs access to a resource they can't currently reach can submit an access request, specifying the resource, the role they're asking for (Admin, Collaborator, or Viewer), and an optional reason. Owners and Admins see pending requests and can approve (optionally granting the requested role on the spot) or reject them. Requesters can also cancel their own requests while they're still pending. See access requests for the full workflow.

Validating and Testing Access

Devpilot gives Owners and Admins two tools to check access without guessing:

• Access validation — ask whether a specific person can perform a specific action on a specific resource. You get a yes-or-no answer plus a summary of the effective access Devpilot computed for that person on that resource.
• Permission testing — run several checks at once for a person on a resource type and see the results side by side, along with the reason Devpilot reached each decision. Useful when you're troubleshooting why someone can or cannot do something.

Both tools live in the Team area and are available to Owners and Admins.

Choosing the Right Role

• Owner — reserved for the workspace creator or primary administrator. Exactly one person holds this role.
• Admin — assign to trusted team leads or senior engineers who need to manage the team, integrations, and credentials alongside the Owner.
• Member — assign to everyone else. Use resource-level grants and custom permission sets to give each Member exactly the access they need, and nothing more.

Frequently Asked Questions

Can I create custom roles at the workspace level? No — Devpilot has three fixed workspace roles (Owner, Admin, Member). Customisation happens at the resource level and through custom permission sets, which you can tailor freely.

Can a user have different roles in different workspaces? Yes. Workspace roles are assigned per workspace. The same person can be an Admin in one workspace and a Member in another.

Can I restrict a Member to specific servers, projects, or apps? Yes — that's exactly what resource-level grants are for. Give the Member Viewer, Collaborator, or Admin only on the resources they should touch, and leave the rest untouched.

What happens when I change a member's role? The change takes effect immediately on their next action, and it is recorded in the access audit trail for compliance.

How are overrides different from regular grants? A regular grant gives access where there wasn't any. An override is clearly marked as a deliberate replacement of the role a member would otherwise inherit on that one resource.

Do updates to a permission set apply retroactively? No. Updating a set changes what the set contains, but it does not rewrite grants that were previously applied from it. Reapply the set to push the updated access to members.

Next steps