Skip to main content
Requires Enterprise plan. Contact sales for access.
Groups let you manage access to projects and runners at scale. Instead of granting permissions individually, assign members to groups and share resources with those groups.
Groups settings page showing list of groups with member counts

Groups overview

How access works

When you create a project or runner, only you and organization admins can access it. To share with your team, either:
  • Share with specific groups (recommended)
  • Grant access to everyone in the organization
For team members to use a project, they need access to both the project and at least one runner the project uses.
The Share dialog warns you when this might be an issue.
Warning message about access dependencies when sharing resources

Access dependency warning

Managing groups

Create a group

  1. Go to Settings → Members → Groups
  2. Click New Group
  3. Enter a name and optional description
  4. Optionally add members during creation
  5. Click Create
New group creation dialog with name, description, and member selection fields

Create a new group

Add members

  1. Click on the group
  2. Click Add People
  3. Select members and click Add
Add People dialog showing member search and selection interface

Add members to a group

Remove members

  1. Open the group
  2. Select members using checkboxes
  3. Click Remove
Members immediately lose access to resources shared exclusively with that group.
Group details page showing member list with selection checkboxes

Group details

Delete a group

  1. Open the group
  2. Click Delete
  3. Confirm
Deletion is permanent. Members lose access to resources shared only with this group.

Roles and Permissions

When you assign a role to a group on a resource, all members of that group receive the permissions associated with that role.

Project Roles

The following table outlines the specific permissions for each role on projects:
PermissionUserEditorAdmin
Read Access
Read project (view details, settings, configuration)
Read secrets (names only, not values)
Read environment classes (see which runners the project uses)
Read prebuilds (view prebuild configurations and history)
Write Access
Update project (modify settings and configuration)
Delete project
Create/update/delete secrets (full access including values)
Create/update/delete environment classes (configure runners)
Create/update/delete prebuilds
Admin Access
Grant access (share project with groups)
Editors can delete projects. Grant Editor access only to trusted team members who need full management capabilities.

Runner Roles

The following table outlines the specific permissions for each role on runners:
PermissionUserAdmin
Read Access
Read runner (view details, status, configuration)
Read environment classes (view available machine types)
Read SCM integrations (view source control integrations)
Read/use LLM integrations (view and use AI/LLM features)
Usage
Create environments on this runner
Create agent executions (use AI agent features)
Create host authentication tokens
Write Access
Update runner (modify configuration and settings)
Delete runner
Create/update/delete environment classes
Create/update/delete SCM integrations
Create/update/delete LLM integrations
Admin Access
Grant access (share runner with groups)
Create runner tokens (for runner registration)
Access runner logs

Automation Roles

Automations can be shared with groups using the Executor role. See Sharing Automations for details.
PermissionExecutor
Read Access
View automation (name, description, steps)
View own executions
View other users’ executions
Usage
Run automation on accessible projects/repositories
Write Access
Edit automation
Delete automation
Admin Access
Share automation with groups
Organization admins have full access to all automations, including the ability to create, edit, delete, share, and view all executions.

Permission Inheritance

  • Multiple groups: When a user belongs to multiple groups with access to the same resource, they receive the union of all permissions. The highest permission level applies.
  • Organization admins: All org admins automatically have Admin permissions on all projects, runners, and automations, regardless of group memberships.

Best Practices

Organize Groups by Function

Create groups that reflect how your team works:
  • By team: “Frontend Team,” “Backend Team,” “DevOps”
  • By role: “Developers,” “Designers,” “Product Managers”
  • By project: “Mobile App Team,” “API Team”

Use Descriptive Names and Descriptions

Help others understand what each group is for:
  • ✅ “Backend Engineers - API and Database Development”
  • ❌ “Group 1”

Start with Restrictive Access

Begin by sharing resources with specific groups. You can always expand access later:
  1. Create groups for your teams
  2. Share resources with relevant groups
  3. Adjust permissions based on feedback
  4. Expand to organization-wide access if needed

Review Access Regularly

Periodically review who has access to your resources:
  • Check group memberships when people change roles
  • Remove access for team members who no longer need it
  • Update permission levels as responsibilities change

Consider Runner Dependencies

Before restricting runner access:
  1. Identify which projects use the runner
  2. Ensure all project users also have runner access
  3. Communicate changes to affected teams

Use the Right Permission Level

Grant the minimum permissions needed:
  • Most team members need User access
  • Team leads or maintainers need Editor access
  • Only a few people need Admin access
Review the detailed permissions in the “Roles and Permissions” section to understand what each role can do.

FAQ

Yes, team members can belong to multiple groups. They’ll receive the combined permissions from all their groups. If someone has User access through one group and Admin access through another, they effectively have Admin access.
All members lose access to resources that were shared exclusively with that group. Resources shared with other groups or with everyone in the organization remain accessible. The group deletion is permanent and cannot be undone.
This usually means you have access to the project but not to any of the runners it uses. Contact your organization admin to request runner access.
Verify that the resource is shared with the group, the person has runner access if needed, they’ve refreshed their browser, and check for any error messages.
They might be in another group with access, included in “Everyone in Organization” access, or they’re an organization administrator.
Creating and managing groups requires organization admin permissions. Contact your organization admin if you need to manage groups.
Verify the project uses that runner, team members have project access, they’re in the shared group, and no policies are blocking access.
Yes, open the Share dialog for any resource to see which groups have access and their permission levels. You can then view those groups to see their members.
Projects configured to use that runner will no longer be able to create environments using that runner’s environment classes. If the project has other environment classes from different runners, those will still work. If it was the only runner, the project becomes unusable until you configure it with a new runner.