Core concepts

Permissions

Roles, permissions, and how access flows from workspace to project.

Every member of a workspace has a role. The role determines what actions they can perform across the workspace and its projects.

Roles overview

There are five roles, ordered from least to most privileged:

RoleBest for
GuestExternal stakeholders who only need to see published deploys
ViewerInternal users who need read-only access to drafts and settings
EditorBuilders who actively work on projects
ReviewerPeople who comment and approve, but don't push changes
AdminWorkspace owners and team leads

Guests don't count towards your member limit, making them ideal for read-only stakeholders.

Permission matrix

The full breakdown of what each role can do:

ActionGuestViewerReviewerEditorAdmin
View published deploys
View drafts
Comment on deploys
Trigger builds
Edit project settings
Manage environment variables
Invite members
Change roles
Manage billing
Delete projects

How permissions flow

Roles are assigned at the workspace level and apply to every project in that workspace. There's no per-project override.

If you need finer-grained access — for example, contractors who should only see one project — create a separate workspace for that work and invite them there.

Per-project roles are a frequently requested feature and are on our roadmap. For now, the workspace boundary is the boundary of access.

Changing someone's role

Workspace admins can change any member's role at any time:

  1. Go to Workspace settings → Members
  2. Find the member and click the role dropdown next to their name
  3. Select the new role and confirm

The change takes effect immediately — the member doesn't need to re-authenticate.

Removing a member

Removing a member revokes their access immediately. Any content they created stays in the workspace.

If you're using SSO, removing a member from your identity provider does not automatically remove them from the workspace unless SCIM provisioning is enabled.