Permissions
Roles, permissions, and how access flows from workspace to project.
Was this helpful?
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.
There are five roles, ordered from least to most privileged:
Guest
External stakeholders who only need to see published deploys
Viewer
Internal users who need read-only access to drafts and settings
Editor
Builders who actively work on projects
Reviewer
People who comment and approve, but don't push changes
Admin
Workspace owners and team leads
Guests don't count towards your member limit, making them ideal for read-only stakeholders.
The full breakdown of what each role can do:
View published deploys
✓
✓
✓
✓
✓
View drafts
—
✓
✓
✓
✓
Comment on deploys
—
—
✓
✓
✓
Trigger builds
—
—
—
✓
✓
Edit project settings
—
—
—
✓
✓
Manage environment variables
—
—
—
✓
✓
Invite members
—
—
—
—
✓
Change roles
—
—
—
—
✓
Manage billing
—
—
—
—
✓
Delete projects
—
—
—
—
✓
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.
Workspace admins can change any member's role at any time:
Go to Workspace settings → Members
Find the member and click the role dropdown next to their name
Select the new role and confirm
The change takes effect immediately — the member doesn't need to re-authenticate.
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.
Was this helpful?
Was this helpful?