Roles and permissions

Developers and Maintainers can view events based on their individual actions only. For more information, see the prerequisites. ↩︎

Developers, Maintainers, and Owners: Only if the project creation role is set for the instance or for the group.
Developers: Developers can push commits to the default branch of a new project only if the default branch protection is set to “Partially protected” or “Not protected”. ↩︎

Maintainers: Only if users with the Maintainer role can create subgroups. ↩︎

Does not apply to subgroups. ↩︎ ↩︎ ↩︎

Users can view events based on their individual actions only. For more details, see the prerequisites. ↩︎

If the user has GitLab Duo Pro or Enterprise, the user must be assigned a seat to gain access to that GitLab Duo add-on. If the user has GitLab Duo Core, there are no other requirements. ↩︎

Guests can only view events based on their individual actions. ↩︎

You must have permission to view the epic. ↩︎

You must have permission to view the epic and edit the issue. ↩︎

You must have permission to view the parent and child epics. ↩︎

You must have permission to view the parent epic. ↩︎

Users who don’t have the Planner or Owner role can only delete the epics they authored. ↩︎

Guests: In addition, if your group is public or internal, all users who can see the group can also see group wiki pages. ↩︎

Guests: In addition, if your group is public or internal, all users who can see the group can also search group wiki pages. ↩︎

On GitLab.com, only a top-level group Owner can enable Secrets Manager for subgroups and projects. On GitLab Self-Managed, an administrator must enable it for the instance. ↩︎

Owners can grant these actions to other roles, specific users, or custom roles. See Manage secrets permissions. ↩︎ ↩︎

No role can read a secret’s value. CI/CD jobs read values through job authentication. Other workloads read values through the Secrets Manager API, and only if they have been granted the read value permission for that secret. ↩︎

On GitLab Self-Managed, users with the Guest role are able to perform this action only on public and internal projects (not on private projects). External users must be given explicit access (at least the Reporter role) even if the project is internal. Users with the Guest role on GitLab.com are only able to perform this action on public projects because internal visibility is not available. ↩︎ ↩︎

Applies only to comments on Design Management designs. ↩︎

Guest users can access GitLab Releases for downloading assets but are not allowed to download the source code nor see repository information like commits and release evidence. ↩︎

If the tag is protected, this depends on the access given to Developers and Maintainers. ↩︎

For GitLab Self-Managed, project access tokens are available in all tiers. For GitLab.com, project access tokens are supported in the Premium and Ultimate tier (excluding trial licenses). ↩︎

A Maintainer or Owner can’t change project features visibility level if project visibility is set to private.

The admin_vulnerability permission was removed from the Developer role in GitLab 17.0. ↩︎

Security Managers can configure these settings in Settings > General > GitLab Duo. ↩︎ ↩︎ ↩︎

Security Managers can only manage other security configurations through the UI (Secure > Security configuration). ↩︎

Non-members: Only if the project is public.
Guests and Planners: Only if the project is public or Project-based pipeline visibility is enabled. ↩︎

Non-members: Only if the project is public and Project-based pipeline visibility is enabled.
Guests and Planners: Only if Project-based pipeline visibility is enabled. ↩︎ ↩︎ ↩︎

Non-members: Only if the project is public, Project-based pipeline visibility is enabled, and artifacts:public: false is not set on the job.
Guests and Planners: Only if Project-based pipeline visibility is enabled and artifacts:public: false is not set on the job.
Reporters: Only if artifacts:public: false is not set on the job.
The artifacts:public setting only affects GitLab UI and API access. CI/CD job tokens can still access artifacts with the runner API. ↩︎ ↩︎

Non-members, Guests, and Planners: Only if the project is public. ↩︎

Non-members and Guests: Only if the project is public.
Planners: Only if the project is public or Project-based pipeline visibility is enabled. ↩︎

Reporters: Only if the user is part of a group with access to the protected environment.
Developers and maintainers: Only if the user is allowed to deploy to the protected environment. ↩︎

Security Managers can only run DAST on-demand scan pipelines. ↩︎

Developers and maintainers: Only if the user is allowed to merge or push to the protected branch. ↩︎

Developers: Only if the job was triggered by the user and runs for a non-protected branch. ↩︎

Cancellation permissions can be restricted in the pipeline settings. ↩︎

Developers and Maintainers: Only if the job was triggered by the user.
Administrators: Any job. If Admin Mode is enabled for the instance, administrators must turn on Admin Mode for their session. ↩︎

Maintainers: Must have the Maintainer role for a project associated with the runner. ↩︎ ↩︎

Maintainers: Must have the Maintainer role for the owner project (first project associated with runner). ↩︎

Maintainers: Must have the Maintainer role for the project being added and for a project already associated with the runner. ↩︎

Developers: Only for branches where the user has merge permissions. For protected branches, must have merge permissions for the target branch. For protected tags, the user must be allowed to create protected tags. These permission requirements apply when creating or editing schedules, and are checked dynamically as branch protection rules may change over time. ↩︎ ↩︎

When running manually, the pipeline executes with the triggering user’s permissions instead of the schedule owner’s permissions. ↩︎

Developers and Maintainers: Only if the triggering user is not an external user. ↩︎ ↩︎

Only if the triggering user is a member of the project. See also Usage of private Docker images with if-not-present pull policy. ↩︎ ↩︎

You cannot push container images to other projects. ↩︎

On GitLab Self-Managed, users with the Guest role are able to perform this action only on public and internal projects (not on private projects). External users must have the Reporter, Developer, Maintainer, or Owner role, even if the project is internal. Users with the Guest role on GitLab.com are able to perform this action only on public projects because internal visibility is not available. ↩︎

Users can only view events based on their individual actions. For more details, see the prerequisites. ↩︎

Code Suggestions requires a user being assigned a seat to gain access to a GitLab Duo add-on. ↩︎

On GitLab Self-Managed, users with the Guest role are able to perform this action only on public and internal projects (not on private projects). External users must be given explicit access (at least the Planner role) even if the project is internal. Users with the Guest role on GitLab.com are only able to perform this action on public projects because internal visibility is not available. Users with the Guest or Planner role can’t perform this action if merge requests are set to Only Project Members. ↩︎ ↩︎

Approval from Planner and Reporter roles is available only if enabled for the project. Users with the Planner role can’t approve if merge requests are set to Only Project Members. ↩︎

Users with the Planner role can’t perform this action if merge requests are set to Only Project Members. ↩︎ ↩︎

In projects that accept contributions from external members, users can create, edit, and close their own merge requests. For private projects, this excludes the Guest role as those users cannot clone private projects. For internal projects, includes users with read-only access to the project, as they can clone internal projects. ↩︎

In projects that accept contributions from external members, users can create, edit, and close their own merge requests. They cannot edit some fields, like assignees, reviewers, labels, and milestones. ↩︎

Non-members can only view models and versions in public projects with the Everyone with access visibility level. Non-members can’t view internal projects, even if they’re logged in. ↩︎

Non-members can only view model experiments in public projects with the Everyone with access visibility level. Non-members can’t view internal projects, even if they’re logged in. ↩︎

You can also upload and download artifacts with the package registry API, which uses a different set of permissions. ↩︎

Viewing the container registry and pulling images is controlled by container registry visibility permissions. The Guest role does not have viewing or pulling permissions in private projects. ↩︎

On GitLab Self-Managed, users with the Guest role are able to perform this action only on public and internal projects (not on private projects). External users must be given explicit access (at least the Reporter role) even if the project is internal. Users with the Guest role on GitLab.com are only able to perform this action on public projects because internal visibility is not available. ↩︎

Metadata includes labels, assignees, milestones, epics, weight, confidentiality, time tracking, and more. Guest users can only set metadata when creating an issue. They cannot change the metadata on existing issues. Guest users can modify the title and description of issues that they authored or are assigned to. ↩︎

Users can resolve threads they started and threads on issues they authored. ↩︎

Guest users can close and reopen issues that they authored or are assigned to. ↩︎

Guest users can archive and reopen issues that they authored or are assigned to. ↩︎

Guest users can modify the title and description that they authored or are assigned to. ↩︎

Users who don’t have the Planner or Owner role can only delete the issues they authored. ↩︎

Guest users can modify the title and description that they authored or are assigned to. ↩︎

Users can resolve threads they started and threads on tasks they authored. ↩︎

Users who don’t have the Planner or Owner role can only delete the tasks they authored. ↩︎

Users can resolve threads they started and threads on OKRs they authored. ↩︎

On GitLab Self-Managed, users with the Guest role are able to perform this action only on public and internal projects (not on private projects). External users must be given explicit access (at least the Planner role) even if the project is internal. Users with the Guest role on GitLab.com are only able to perform this action on public projects because internal visibility is not available. Users with the Guest role and an Ultimate license can view private repository content if an administrator (on GitLab Self-Managed or GitLab Dedicated) or group owner (on GitLab.com) gives those users permission. The administrator or group owner can create a custom role through the API or UI and assign that role to the users. In GitLab 18.7 and later, users with the Planner role can view private repository content. ↩︎ ↩︎ ↩︎

If the branch is protected, this depends on the access given to Developers and Maintainers. ↩︎

On GitLab Self-Managed, users with the Guest role are able to perform this action only on public and internal projects (not on private projects). External users must be given explicit access (at least the Reporter role) even if the project is internal. Users with the Guest role on GitLab.com are only able to perform this action on public projects because internal visibility is not available. Users with the Guest role and an Ultimate license can view private repository content if an administrator (on GitLab Self-Managed or GitLab Dedicated) or group owner (on GitLab.com) gives those users permission. The administrator or group owner can create a custom role through the API or UI and assign that role to the users. ↩︎ ↩︎ ↩︎

Not allowed for Guest, Reporter, Developer, Maintainer, or Owner. See protected branches. ↩︎

Users with the Owner role can grant these actions to other roles, specific users, or custom roles. See Manage secrets permissions. ↩︎ ↩︎ ↩︎ ↩︎

Users with the Maintainer role have this permission by default for secrets managers enabled in GitLab 19.4 and later. Users with the Owner role can remove or change the default permissions for the Maintainer role. ↩︎ ↩︎

Users with the Developer role have this permission by default for secrets managers enabled in GitLab 19.5 and later. Users with the Owner role can remove or change the default permissions for the Developer role. ↩︎ ↩︎

No role can read a secret’s value. CI/CD jobs read values through job authentication. Other workloads read values through the Secrets Manager API, and only if they have been granted the read value permission for that secret. ↩︎

Maintainers cannot create, demote, or remove Owners, and they cannot promote users to the Owner role. They also cannot approve Owner role access requests. ↩︎

When Share Group Lock is enabled the project can’t be shared with other groups. It does not affect group with group sharing. ↩︎