Roles and permissions

{{< details >}}

• Tier: Free, Premium, Ultimate
• Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated

{{< /details >}}

Roles define a user's permissions in a group or project.

Users with administrator access have all permissions and can perform any action.

Roles

{{< history >}}

• Planner role introduced in GitLab 17.7.
• Security Manager role introduced in GitLab 18.11.

{{< /history >}}

When you add a user to a group or project, you assign them a role. The role determines their permissions. Assign either a default role or a custom role.

A user can have different roles for each group and project. Users always retain the permissions for their highest role. For example, if a user has:

• The Maintainer role for a parent group
• The Developer role for a project in that group

The user inherits the permissions for their Maintainer role in the project.

To view assigned roles, go to the Members page for a group or project.

Default roles

The following default roles are available:

Role	Description
Minimal Access	View limited group information without access to projects. For more information, see Users with Minimal Access.
Guest	View and comment on issues and epics. Cannot push code or access repository. This role applies to private and internal projects only.
Planner	Create and manage issues, epics, milestones, and iterations. Focused on project planning and tracking with the ability to view and collaborate on code changes.
Reporter	View code, create issues, and generate reports. Cannot push code or manage protected branches.
Security Manager	View and manage security vulnerabilities, compliance configurations, and audit events. Focused on security operations without code push access.
Developer	Push code to non-protected branches, create merge requests, and run CI/CD pipelines. Cannot manage project settings.
Maintainer	Manage branches, merge requests, CI/CD settings, and project members. Cannot delete the project.
Owner	Full control over the project or group, including deletion and visibility settings.

By default, all users can create top-level groups and change their usernames. Users with administrator access can change this behavior.

<!-- Sort these permissions according the following rules in order: 1. By minimum role. 2. By the object being accessed (for example, issue, security dashboard, or pipeline) 3. By the action: view, create, change, edit, manage, run, delete, all others 4. Alphabetically. List only one action (for example, view, create, or delete) per line. It's okay to list multiple related objects per line (for example, "View pipelines and pipeline details"). -->

Group 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:

Groups

Group permissions for group features:

Action	Guest	Planner	Reporter	Security Manager	Developer	Maintainer	Owner
Browse group	✓	✓	✓	✓	✓	✓	✓
Search projects in group	✓	✓	✓	✓	✓	✓	✓
View group audit events <sup>1</sup>				✓	✓	✓	✓
Create project in group <sup>2</sup>					✓	✓	✓
Create subgroup <sup>3</sup>						✓	✓
Change custom settings for project integrations							✓
Edit epic comments (posted by any user)						✓	✓
Fork project into a group						✓	✓
View Billing <sup>4</sup>							✓
View group Usage quotas page <sup>4</sup>							✓
Migrate group							✓
Archive group							✓
Delete group							✓
Transfer group							✓
Manage subscriptions, storage, and compute minutes							✓
Manage group access tokens							✓
Change group visibility level							✓
Edit group settings							✓
Configure project templates							✓
Configure SAML SSO <sup>4</sup>							✓
Disable notification emails							✓
Import project						✓	✓

Footnotes:

1. Developers and Maintainers can view events based on their individual actions only. For more information, see the prerequisites.
2. 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".

1. Maintainers: Only if users with the Maintainer role can create subgroups.
2. Does not apply to subgroups.

Group analytics

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

Action	Guest	Planner	Reporter	Security Manager	Developer	Maintainer	Owner
View GitLab Duo and SDLC trends			✓	✓	✓	✓	✓
View insights	✓	✓	✓	✓	✓	✓	✓
View insights charts	✓	✓	✓	✓	✓	✓	✓
View issue analytics	✓	✓	✓	✓	✓	✓	✓
View contribution analytics	✓	✓	✓	✓	✓	✓	✓
View value stream analytics			✓	✓	✓	✓	✓
View productivity analytics			✓	✓	✓	✓	✓
View group DevOps adoption			✓	✓	✓	✓	✓
View metrics dashboard annotations			✓	✓	✓	✓	✓
Manage metrics dashboard annotations					✓	✓	✓

Group application security

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

Action	Guest	Planner	Reporter	Security Manager	Developer	Maintainer	Owner
View dependency list				✓	✓	✓	✓
View vulnerability report				✓	✓	✓	✓
View security dashboard				✓	✓	✓	✓
Create security policy project							✓
Assign security policy project							✓
Manage Secrets Manager							✓

Group CI/CD

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

Action	Guest	Planner	Reporter	Security Manager	Developer	Maintainer	Owner
View instance runner	✓	✓	✓	✓	✓	✓	✓
View group runners						✓	✓
Manage group-level Kubernetes cluster						✓	✓
Manage group runners							✓
Manage group level CI/CD variables							✓
Manage group protected environments							✓

Group compliance

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

Action	Guest	Planner	Reporter	Security Manager	Developer	Maintainer	Owner
View audit events <sup>1</sup>				✓	✓	✓	✓
View licenses in dependency list				✓	✓	✓	✓
View compliance center				✓			✓
Manage compliance frameworks				✓			✓
Assign compliance frameworks to projects				✓			✓
Manage audit streams							✓

Footnotes:

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

Group GitLab Duo

Group permissions for GitLab Duo:

Action	Non-member	Guest	Planner	Reporter	Security Manager	Developer	Maintainer	Owner
Use GitLab Duo features <sup>1</sup>		✓	✓	✓	✓	✓	✓	✓
Configure GitLab Duo feature availability							✓	✓
Configure GitLab Duo Self Hosted								✓
Enable beta and experimental features								✓
Purchase GitLab Duo seats								✓

Footnotes:

1. 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.

Group packages and registries

Group permissions for the package and container registry:

Action	Guest	Planner	Reporter	Security Manager	Developer	Maintainer	Owner
Pull container registry images <sup>1</sup>	✓	✓	✓	✓	✓	✓	✓
Pull container images with the dependency proxy	✓	✓	✓	✓	✓	✓	✓
Delete container registry images					✓	✓	✓
Configure a virtual registry						✓	✓
Pull an artifact from a virtual registry	✓		✓	✓	✓	✓	✓

Footnotes:

1. Guests can only view events based on their individual actions.

Group permissions for package registry:

Action	Guest	Planner	Reporter	Security Manager	Developer	Maintainer	Owner
Pull packages			✓	✓	✓	✓	✓
Publish packages					✓	✓	✓
Delete packages						✓	✓
Manage package settings							✓
Manage dependency proxy cleanup policies							✓
Enable dependency proxy							✓
Disable dependency proxy							✓
Purge the group dependency proxy							✓
Enable package request forwarding							✓
Disable package request forwarding							✓

Group planning

Action	Guest	Planner	Reporter	Security Manager	Developer	Maintainer	Owner
View epic	✓	✓	✓	✓	✓	✓	✓
Search epics <sup>1</sup>	✓	✓	✓	✓	✓	✓	✓
Add issues to an epic <sup>2</sup>	✓	✓	✓	✓	✓	✓	✓
Add child epics <sup>3</sup>	✓	✓	✓	✓	✓	✓	✓
Add parent epic <sup>4</sup>	✓	✓	✓	✓	✓	✓	✓
Add internal notes		✓	✓	✓	✓	✓	✓
Create epics		✓	✓	✓	✓	✓	✓
Update epic details		✓	✓	✓	✓	✓	✓
Manage epic boards		✓	✓	✓	✓	✓	✓
Delete epics <sup>5</sup>	✓	✓	✓	✓	✓	✓	✓

Footnotes:

1. You must have permission to view the epic.
2. You must have permission to view the epic and edit the issue.
3. You must have permission to view the parent and child epics.
4. You must have permission to view the parent epic.
5. Users who don't have the Planner or Owner role can only delete the epics they authored.

Group permissions for wikis:

Action	Guest	Planner	Reporter	Security Manager	Developer	Maintainer	Owner
View group wiki <sup>1</sup>	✓	✓	✓	✓	✓	✓	✓
Search group wikis <sup>2</sup>	✓	✓	✓	✓	✓	✓	✓
Create group wiki pages		✓			✓	✓	✓
Edit group wiki pages		✓			✓	✓	✓
Delete group wiki pages		✓			✓	✓	✓

Footnotes:

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

Group repositories

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

Action	Guest	Planner	Reporter	Security Manager	Developer	Maintainer	Owner
Manage deploy tokens							✓
Manage merge request settings							✓
Manage push rules							✓

Group user management

Group permissions for user management:

Action	Guest	Planner	Reporter	Security Manager	Developer	Maintainer	Owner
View 2FA status of members							✓
Filter members by 2FA status							✓
Manage group members							✓
Manage group-level custom roles							✓
Share (invite) groups to groups							✓

Group workspaces

Groups permissions for workspaces:

Action	Guest	Planner	Reporter	Security Manager	Developer	Maintainer	Owner
View workspace cluster agents mapped to a group						✓	✓
Map or unmap workspace cluster agents to and from a group							✓

Project 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.

When you configure protected branch settings, selecting a role grants access to users with that role and all higher roles. For example, if you select Maintainers in the protected branch settings, users with both the Maintainer and Owner roles can perform the action.

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.

Projects

Project permissions for project features:

Action	Guest	Planner	Reporter	Security Manager	Developer	Maintainer	Owner
Download project <sup>1</sup>	✓	✓	✓	✓	✓	✓	✓
Leave comments	✓	✓	✓	✓	✓	✓	✓
Reposition comments on images (posted by any user) <sup>2</sup>	✓	✓	✓	✓	✓	✓	✓
View insights	✓	✓	✓	✓	✓	✓	✓
View requirements	✓	✓	✓	✓	✓	✓	✓
View time tracking reports <sup>1</sup>	✓	✓	✓	✓	✓	✓	✓
View snippets	✓	✓	✓	✓	✓	✓	✓
Search snippets and comments	✓	✓	✓	✓	✓	✓	✓
View project traffic statistics			✓	✓	✓	✓	✓
Create snippets			✓	✓	✓	✓	✓
View releases <sup>3</sup>		✓	✓	✓	✓	✓	✓
Manage releases <sup>4</sup>						✓	✓
Configure webhooks						✓	✓
Manage project access tokens <sup>5</sup>						✓	✓
Export project						✓	✓
Rename project						✓	✓
Edit project badges						✓	✓
Edit project settings						✓	✓
Change project features visibility level <sup>6</sup>						✓	✓
Change custom settings for project integrations						✓	✓
Edit comments posted by other users						✓	✓
Add deploy keys						✓	✓
Manage project operations						✓	✓
View Usage quotas page						✓	✓
Globally delete snippets						✓	✓
Globally edit snippets						✓	✓
Archive project							✓
Change project visibility level							✓
Delete project							✓
Disable notification emails							✓
Transfer project							✓

Footnotes:

<!-- Disable ordered list rule <https://github.com/DavidAnson/markdownlint/blob/main/doc/Rules.md#md029---ordered-list-item-prefix> --> <!-- markdownlint-disable MD029 -->

1. 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.

2. Applies only to comments on Design Management designs.

3. 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.

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

5. 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).

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

   <!-- markdownlint-enable MD029 -->

Project permissions for GitLab Pages:

Action	Guest	Planner	Reporter	Security Manager	Developer	Maintainer	Owner
View GitLab Pages protected by access control	✓	✓	✓	✓	✓	✓	✓
Manage GitLab Pages						✓	✓
Manage GitLab Pages domain and certificates						✓	✓
Remove GitLab Pages						✓	✓

Project analytics

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

Action	Guest	Planner	Reporter	Security Manager	Developer	Maintainer	Owner
View issue analytics	✓	✓	✓	✓	✓	✓	✓
View value stream analytics			✓	✓	✓	✓	✓
View CI/CD analytics			✓	✓	✓	✓	✓
View code review analytics			✓	✓	✓	✓	✓
View DORA metrics			✓	✓	✓	✓	✓
View merge request analytics			✓	✓	✓	✓	✓
View repository analytics			✓	✓	✓	✓	✓
View Value Streams Dashboard			✓	✓	✓	✓	✓
View GitLab Duo and SDLC trends			✓	✓	✓	✓	✓

Project application security

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

Action	Guest	Planner	Reporter	Security Manager	Developer	Maintainer	Owner
View dependency list				✓	✓	✓	✓
View licenses in dependency list				✓	✓	✓	✓
View security dashboard				✓	✓	✓	✓
View vulnerability report				✓	✓	✓	✓
Create vulnerability manually				✓		✓	✓
Create issue from vulnerability finding				✓	✓	✓	✓
Create on-demand DAST scans				✓	✓	✓	✓
Run on-demand DAST scans				✓	✓	✓	✓
Create individual security policies					✓	✓	✓
Change individual security policies					✓	✓	✓
Delete individual security policies					✓	✓	✓
Create CVE ID request						✓	✓
Change vulnerability status <sup>1</sup>				✓		✓	✓
Create security policy project							✓
Assign security policy project							✓
Manage security configurations <sup>2</sup>				✓		✓	✓
Manage Secrets Manager							✓

Footnotes:

1. The admin_vulnerability permission was removed from the Developer role in GitLab 17.0.
2. Security Managers can only manage security configurations through the UI (Secure > Security configuration).

Project 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 certain CI/CD "view" features to non-project members.

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

Action	Non-member	Guest	Planner	Reporter	Security Manager	Developer	Maintainer
View instance runner	✓	✓	✓	✓	✓	✓	✓
View existing artifacts <sup>1</sup>	✓	✓	✓	✓	✓	✓	✓
View list of jobs <sup>2</sup>	✓	✓	✓	✓	✓	✓	✓
View artifacts <sup>3</sup>	✓	✓	✓	✓	✓	✓	✓
Download artifacts <sup>3</sup>	✓	✓	✓	✓	✓	✓	✓
View environments <sup>1</sup>	✓	✓	✓	✓	✓	✓	✓
View job logs and job details page <sup>2</sup>	✓	✓	✓	✓	✓	✓	✓
View pipelines and pipeline details pages <sup>2</sup>	✓	✓	✓	✓	✓	✓	✓
View pipelines tab in MR <sup>1</sup>	✓	✓	✓	✓	✓	✓	✓
View vulnerabilities in a pipeline <sup>4</sup>		✓	✓	✓	✓	✓	✓
Run deployment job for a protected environment <sup>5</sup>				✓		✓	✓
View agents for Kubernetes						✓	✓
View project Secure Files						✓	✓
Download project Secure Files						✓	✓
View a job with debug logging						✓	✓
Create environments						✓	✓
Delete environments						✓	✓
Stop environments						✓	✓
Run, rerun, or retry CI/CD pipeline or job <sup>14</sup>					✓	✓	✓
Run, rerun, or retry CI/CD pipeline or job for a protected branch <sup>6</sup>						✓	✓
Delete job logs or job artifacts <sup>7</sup>						✓	✓
Enable review apps						✓	✓
Cancel jobs <sup>8</sup>						✓	✓
Read Terraform state						✓	✓
Run interactive web terminals						✓	✓
Use pipeline editor						✓	✓
View project runners <sup>9</sup>					✓		✓
Manage project runners <sup>9</sup>							✓
Delete project runners <sup>10</sup>							✓
Manage agents for Kubernetes							✓
Manage CI/CD settings							✓
Manage job triggers							✓
Manage project CI/CD variables							✓
Manage project protected environments							✓
Manage project Secure Files							✓
Manage Terraform state							✓
Add project runners to project <sup>11</sup>							✓
Clear runner caches manually							✓
Enable instance runners in project							✓
Create pipeline schedules <sup>12</sup>						✓	✓
Edit own pipeline schedules <sup>12</sup>						✓	✓
Delete own pipeline schedules						✓	✓
Run pipeline schedules manually <sup>13</sup>						✓	✓
Take ownership of pipeline schedules							✓
Delete others' pipeline schedules							✓

Footnotes:

<!-- Disable ordered list rule <https://github.com/DavidAnson/markdownlint/blob/main/doc/Rules.md#md029---ordered-list-item-prefix> --> <!-- markdownlint-disable MD029 -->

1. Non-members and guests: Only if the project is public.
2. Non-members: Only if the project is public and Project-based pipeline visibility is enabled.

Guests: Only if Project-based pipeline visibility is enabled. 3. 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: 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. 4. Guests: Only if Project-based pipeline visibility is enabled. 5. 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. 6. Developers and maintainers: Only if the user is allowed to merge or push to the protected branch. 7. Developers: Only if the job was triggered by the user and runs for a non-protected branch. 8. Cancellation permissions can be restricted in the pipeline settings. 9. Maintainers: Must have the Maintainer role for a project associated with the runner. 10. Maintainers: Must have the Maintainer role for the owner project (first project associated with runner). 11. Maintainers: Must have the Maintainer role for the project being added and for a project already associated with the runner. 12. 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. 13. When running manually, the pipeline executes with the triggering user's permissions instead of the schedule owner's permissions. 14. Security Managers can only run DAST on-demand scan pipelines.

<!-- markdownlint-enable MD029 -->

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.

Action	Developer	Maintainer
Clone source and LFS from current project	✓	✓
Clone source and LFS from public projects	✓	✓
Clone source and LFS from internal projects <sup>1</sup>	✓	✓
Clone source and LFS from private projects <sup>2</sup>	✓	✓
Pull container images from current project	✓	✓
Pull container images from public projects	✓	✓
Pull container images from internal projects <sup>1</sup>	✓	✓
Pull container images from private projects <sup>2</sup>	✓	✓
Push container images to current project <sup>3</sup>	✓	✓

Footnotes:

1. Developers and Maintainers: Only if the triggering user is not an external user.
2. Only if the triggering user is a member of the project. See also Usage of private Docker images with if-not-present pull policy.
3. You cannot push container images to other projects.

Project compliance

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

Action	Guest	Planner	Reporter	Security Manager	Developer	Maintainer	Owner
View allowed and denied licenses in MR <sup>1</sup>	✓	✓	✓	✓	✓	✓	✓
View audit events <sup>2</sup>				✓	✓	✓	✓
View licenses in dependency list				✓	✓	✓	✓
Manage audit streams							✓

Footnotes:

1. 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.
2. Users can only view events based on their individual actions. For more details, see the prerequisites.

Project GitLab Duo

Project permissions for GitLab Duo:

Action	Non-member	Guest	Planner	Reporter	Security Manager	Developer	Maintainer	Owner
Use GitLab Duo features <sup>1</sup>		✓	✓	✓	✓	✓	✓	✓
Configure GitLab Duo feature availability							✓	✓

Footnotes:

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

Project merge requests

Project permissions for merge requests:

Action	Guest	Planner	Reporter	Security Manager	Developer	Maintainer	Owner
View a merge request <sup>1</sup>	✓	✓	✓	✓	✓	✓	✓
Search merge requests and comments <sup>1</sup><sup>2</sup>	✓	✓	✓	✓	✓	✓	✓
Approve merge requests <sup>3</sup>		✓	✓	✓	✓	✓	✓
Add internal note		✓	✓	✓	✓	✓	✓
Comment and add suggestions		✓	✓	✓	✓	✓	✓
Create snippets			✓	✓	✓	✓	✓
Create merge request <sup>4</sup>					✓	✓	✓
Update merge request details <sup>5</sup>					✓	✓	✓
Manage merge request settings						✓	✓
Manage merge request approval rules						✓	✓
Delete merge request							✓

Footnotes:

1. 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.
2. Users with the Planner role can not use advanced search for merge requests and comments on merge requests. For more information, see epic &17674.
3. Approval from Planner and Reporter roles is available only if enabled for the project.
4. 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.
5. 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.

Project model registry and experiments

Project permissions for model registry and model experiments.

Action	Guest	Planner	Reporter	Security Manager	Developer	Maintainer	Owner
View models and versions <sup>1</sup>	✓	✓	✓	✓	✓	✓	✓
View model experiments <sup>2</sup>	✓	✓	✓	✓	✓	✓	✓
Create models, versions, and artifacts <sup>3</sup>					✓	✓	✓
Edit models, versions, and artifacts					✓	✓	✓
Delete models, versions, and artifacts					✓	✓	✓
Create experiments and candidates					✓	✓	✓
Edit experiments and candidates					✓	✓	✓
Delete experiments and candidates					✓	✓	✓

Footnotes:

1. 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.
2. 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.
3. You can also upload and download artifacts with the package registry API, which uses a different set of permissions.

Project monitoring

Project permissions for monitoring including error tracking and incident management:

Action	Guest	Planner	Reporter	Security Manager	Developer	Maintainer	Owner
View an incident	✓	✓	✓	✓	✓	✓	✓
Assign an incident management alert	✓	✓	✓	✓	✓	✓	✓
Participate in on-call rotation for Incident Management	✓	✓	✓	✓	✓	✓	✓
View alerts			✓	✓	✓	✓	✓
View error tracking list			✓	✓	✓	✓	✓
View escalation policies			✓	✓	✓	✓	✓
View on-call schedules			✓	✓	✓	✓	✓
Create incident			✓	✓	✓	✓	✓
Change alert status			✓	✓	✓	✓	✓
Change incident severity			✓	✓	✓	✓	✓
Change incident escalation status					✓	✓	✓
Change incident escalation policy					✓	✓	✓
Manage error tracking						✓	✓
Manage escalation policies						✓	✓
Manage on-call schedules						✓	✓

Project packages and registries

Project permissions for container registry:

Action	Guest	Planner	Reporter	Security Manager	Developer	Maintainer	Owner
Pull container registry images <sup>1</sup>	✓	✓	✓	✓	✓	✓	✓
Push container registry images					✓	✓	✓
Delete container registry images					✓	✓	✓
Manage cleanup policies						✓	✓
Create tag protection rules						✓	✓
Create immutable tag protection rules							✓

Footnotes:

1. 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.

Project permissions for package registry:

Action	Guest	Planner	Reporter	Security Manager	Developer	Maintainer	Owner
Pull packages <sup>1</sup>	✓	✓	✓	✓	✓	✓	✓
Publish packages					✓	✓	✓
Delete packages						✓	✓
Delete files associated with a package						✓	✓

Footnotes:

1. 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.

Project planning

Project permissions for issues:

Action	Guest	Planner	Reporter	Security Manager	Developer	Maintainer	Owner
View issues	✓	✓	✓	✓	✓	✓	✓
Search issues and comments	✓	✓	✓	✓	✓	✓	✓
Create issues	✓	✓	✓	✓	✓	✓	✓
View confidential issues		✓	✓	✓	✓	✓	✓
Search confidential issues and comments <sup>6</sup>		✓	✓	✓	✓	✓	✓
Edit issues, including metadata, item locking, and resolving threads <sup>1</sup>		✓	✓	✓	✓	✓	✓
Add internal notes		✓	✓	✓	✓	✓	✓
Close and reopen issues <sup>2</sup>		✓	✓	✓	✓	✓	✓
Manage design management files		✓	✓	✓	✓	✓	✓
Manage issue boards		✓	✓	✓	✓	✓	✓
Manage milestones		✓	✓	✓	✓	✓	✓
Search milestones <sup>6</sup>		✓	✓	✓	✓	✓	✓
Archive or reopen requirements <sup>3</sup>		✓	✓	✓	✓	✓	✓
Create or edit requirements <sup>4</sup>		✓	✓	✓	✓	✓	✓
Import or export requirements		✓	✓	✓	✓	✓	✓
Archive test cases		✓	✓	✓	✓	✓	✓
Create test cases		✓	✓	✓	✓	✓	✓
Move test cases		✓	✓	✓	✓	✓	✓
Reopen test cases		✓	✓	✓	✓	✓	✓
Import issues from a CSV file		✓			✓	✓	✓
Export issues to a CSV file	✓	✓	✓	✓	✓	✓	✓
Delete issues <sup>5</sup>		✓	✓	✓	✓	✓	✓
Manage Feature flags					✓	✓	✓

Footnotes:

1. 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.
2. Guest users can close and reopen issues that they authored or are assigned to.
3. Guest users can archive and reopen issues that they authored or are assigned to.
4. Guest users can modify the title and description that they authored or are assigned to.
5. Users who don't have the Planner or Owner role can only delete the issues they authored.
6. Users with the Planner role can not use advanced search for milestones or comments on confidential issues. For more information, see epic 17674.

Project permissions for tasks:

Action	Guest	Planner	Reporter	Security Manager	Developer	Maintainer	Owner
View tasks	✓	✓	✓	✓	✓	✓	✓
Search tasks	✓	✓	✓	✓	✓	✓	✓
Create tasks	✓	✓	✓	✓	✓	✓	✓
Edit tasks, including metadata, item locking, and resolving threads <sup>1</sup>		✓	✓	✓	✓	✓	✓
Add a linked item	✓	✓	✓	✓	✓	✓	✓
Convert to another item type		✓	✓	✓	✓	✓	✓
Remove from issue	✓	✓	✓	✓	✓	✓	✓
Add internal note		✓	✓	✓	✓	✓	✓
Delete tasks <sup>2</sup>	✓	✓	✓	✓	✓	✓	✓

Footnotes:

1. Guest users can modify the title and description that they authored or are assigned to.
2. Users who don't have the Planner or Owner role can only delete the tasks they authored.

Project permissions for OKRs:

Action	Guest	Planner	Reporter	Security Manager	Developer	Maintainer	Owner
View OKRs	✓	✓	✓	✓	✓	✓	✓
Search OKRs	✓	✓	✓	✓	✓	✓	✓
Create OKRs	✓	✓	✓	✓	✓	✓	✓
Edit OKRs, including metadata, item locking, and resolving threads	✓	✓	✓	✓	✓	✓	✓
Add a child OKR	✓	✓	✓	✓	✓	✓	✓
Add a linked item	✓	✓	✓	✓	✓	✓	✓
Convert to another item type	✓	✓	✓	✓	✓	✓	✓
Edit OKRs		✓	✓	✓	✓	✓	✓
Change confidentiality in OKR		✓	✓	✓	✓	✓	✓
Add internal note		✓	✓	✓	✓	✓	✓

Project permissions for wikis:

Action	Guest	Planner	Reporter	Security Manager	Developer	Maintainer	Owner
View wiki	✓	✓	✓	✓	✓	✓	✓
Search wikis	✓	✓	✓	✓	✓	✓	✓
Create wiki pages		✓			✓	✓	✓
Edit wiki pages		✓			✓	✓	✓
Delete wiki pages		✓			✓	✓	✓

Project repositories

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

Action	Guest	Planner	Reporter	Security Manager	Developer	Maintainer	Owner
View project code <sup>1</sup>	✓	✓	✓	✓	✓	✓	✓
Search project code <sup>1</sup> <sup>2</sup>	✓	✓	✓	✓	✓	✓	✓
Search commits and comments <sup>1</sup> <sup>2</sup>	✓	✓	✓	✓	✓	✓	✓
Pull project code <sup>3</sup>	✓	✓	✓	✓	✓	✓	✓
View commit status			✓	✓	✓	✓	✓
Create commit status <sup>4</sup>					✓	✓	✓
Update commit status <sup>4</sup>					✓	✓	✓
Create Git tags					✓	✓	✓
Delete Git tags					✓	✓	✓
Create new branches					✓	✓	✓
Push to non-protected branches					✓	✓	✓
Force push to non-protected branches					✓	✓	✓
Delete non-protected branches					✓	✓	✓
Manage protected branches						✓	✓
Push to protected branches <sup>4</sup>						✓	✓
Delete protected branches						✓	✓
Manage protected tags						✓	✓
Manage push rules						✓	✓
Remove fork relationship							✓
Force push to protected branches <sup>5</sup>

Footnotes:

<!-- Disable ordered list rule <https://github.com/DavidAnson/markdownlint/blob/main/doc/Rules.md#md029---ordered-list-item-prefix> --> <!-- markdownlint-disable MD029 -->

1. 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. In GitLab 15.9 and later, 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.
2. Users with the Planner role can not use exact code search or advanced search for code, commits, and comments on commits in private projects. For more information, see epic &17674.
3. If the branch is protected, this depends on the access given to Developers and Maintainers.
4. 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. In GitLab 15.9 and later, 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.
5. Not allowed for Guest, Reporter, Developer, Maintainer, or Owner. See protected branches.

<!-- markdownlint-enable MD029 -->

Project user management

Project permissions for user management.

Action	Guest	Planner	Reporter	Security Manager	Developer	Maintainer	Owner
View 2FA status of members						✓	✓
Manage project members <sup>1</sup>						✓	✓
Share (invite) projects with groups <sup>2</sup>							✓

Footnotes:

1. Maintainers cannot create, demote, or remove Owners, and they cannot promote users to the Owner role. They also cannot approve Owner role access requests.
2. When Share Group Lock is enabled the project can't be shared with other groups. It does not affect group with group sharing.

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

{{< details >}}

• Tier: Premium, Ultimate
• Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated

{{< /details >}}

{{< history >}}

• Support for inviting users with Minimal Access role introduced in GitLab 15.9.
• Minimal Access users changed to non-billable in GitLab 18.9.
• Enforce two-factor authentication requirements for users with Minimal Access role in GitLab 18.11.

{{< /history >}}

Users with the Minimal Access role do not:

• Automatically have access to projects and subgroups in that top-level group. Owners must explicitly add these users to the specific subgroups and projects.
• Count as licensed seats, provided the user has no other role anywhere on the instance or in the GitLab.com namespace.

If a user with the Minimal Access role is granted a billable role in any project or subgroup, they consume a license seat based on their highest role.

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. In the top bar, 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, Planner, Reporter, Security Manager, Developer, Maintainer, or Owner role 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