Roles and permissions

When you add a user to a project or group, you assign them a role. The role determines which actions they can take in GitLab.

If you add a user to both a project’s group and the project itself, the higher role is used.

GitLab administrators have all permissions.

Roles

You can assign users a default role or a custom role.

The available default roles are:

• Guest (This role applies to private and internal projects only.)
• Planner
• Reporter
• Developer
• Maintainer
• Owner
• Minimal Access (available for the top-level group only)

A user assigned the Guest role has the least permissions, and the Owner has the most.

By default, all users can create top-level groups and change their usernames. A GitLab administrator can change this behavior for the GitLab instance.

Group members permissions

Any user can remove themselves from a group, unless they are the only Owner of the group.

The following table lists group permissions available for each role:

Analytics group permissions

Group permission for analytics features including value streams, product analytics, and insights:

Application security group permissions

Group permissions for Application Security features including dependency management, security analyzers, security policies, and vulnerability management.

CI/CD group permissions

Group permissions for CI/CD features including runners, variables, and protected environments:

Compliance group permissions

Group permissions for compliance features including compliance center, audit events, compliance frameworks, and licenses.

Footnotes

GitLab Duo group permissions

Group permissions for GitLab Duo:

Footnotes

Groups group permissions

Group permissions for group features:

Footnotes

Project planning group permissions

Footnotes

Group permissions for wikis:

Footnotes

Packages and registries group permissions

Group permissions for container registry:

Footnotes

Group permissions for package registry:

Repository group permissions

Group permissions for repository features including merge requests, push rules, and deploy tokens.

User management group permissions

Group permissions for user management:

Workspace group permissions

Groups permissions for workspaces:

Project members permissions

A user’s role determines what permissions they have on a project. The Owner role provides all permissions but is available only:

• For group and project Owners.
• For Administrators.

Personal namespace owners:

• Are displayed as having the Maintainer role on projects in the namespace, but have the same permissions as a user with the Owner role.
• For new projects in the namespace, are displayed as having the Owner role.

For more information about how to manage project members, see members of a project.

The following tables list the project permissions available for each role.

Analytics

Project permissions for analytics features including value streams, usage trends, product analytics, and insights.

Application security

Project permissions for application security features including dependency management, security analyzers, security policies, and vulnerability management.

Footnotes

CI/CD

GitLab CI/CD permissions for some roles can be modified by these settings:

• Project-based pipeline visibility: When set to public, gives access to certain CI/CD features to Guest project members.
• Pipeline visibility: When set to Everyone with Access, gives access to non-project members to view certain CI/CD features.

Project Owners can perform any listed action, and can delete pipelines:

Footnotes

This table shows granted privileges for jobs triggered by specific roles.

Project Owners can do any listed action, but no users can push source and LFS together. Guest users and members with the Reporter role cannot do any of these actions.

Footnotes

Compliance

Project permissions for compliance features including compliance center, audit events, compliance frameworks, and licenses.

Footnotes

GitLab Duo

Project permissions for GitLab Duo:

Footnotes

Machine learning model registry and experiment

Project permissions for model registry and model experiments.

Footnotes

Monitoring

Project permissions for monitoring including error tracking and incident management:

Project planning

Project permissions for issues:

Footnotes

Project permissions for tasks:

Footnotes

Project permissions for OKRs:

Project permissions for wikis:

Packages and registry

Project permissions for container registry:

Footnotes

Project permissions for package registry:

Footnotes

Projects

Project permissions for project features:

Footnotes

Project permissions for GitLab Pages:

Repository

Project permissions for repository features including source code, branches, push rules, and more:

Footnotes

Merge requests

Project permissions for merge requests:

Footnotes

User management

Project permissions for user management.

Footnotes

Subgroup permissions

When you add a member to a subgroup, they inherit the membership and permission level from the parent groups. This model allows access to nested groups if you have membership in one of its parents.

For more information, see subgroup memberships.

Users with Minimal Access

Users with the Minimal Access role do not:

• Automatically have access to projects and subgroups in that top-level group.
• Count as licensed seats on GitLab Self-Managed Ultimate subscriptions or any GitLab.com subscriptions, provided the user has no other role anywhere in the instance or in the GitLab.com namespace.

Owners must explicitly add these users to the specific subgroups and projects.

You can use the Minimal Access role with SAML SSO for GitLab.com groups to control access to groups and projects in the group hierarchy. You can set the default role to Minimal Access for members automatically added to the top-level group through SSO.

1. On the left sidebar, select Search or go to and find your group.
2. Select Settings > SAML SSO.
3. From the Default membership role dropdown list, select Minimal Access.
4. Select Save changes.

Minimal access users receive 404 errors

Because of an outstanding issue, when a user with the Minimal Access role:

• Signs in with standard web authentication, they receive a 404 error when accessing the parent group.
• Signs in with Group SSO, they receive a 404 error immediately because they are redirected to the parent group page.

To work around the issue, give these users the Guest role or higher to any project or subgroup in the parent group. Guest users consume a license seat in the Premium tier but do not in the Ultimate tier.

Related topics

• Protect your repository
• Custom roles
• Members
• Customize permissions on protected branches
• LDAP user permissions
• Value stream analytics permissions
• Project aliases
• Auditor users
• Confidential issues
• Container registry permissions
• Release permissions
• Read-only namespaces