version v7.2.
For up-to-date documentation, see the
latest version.
Members & Roles
2 minute read
GitLab uses a role-based access model to control what members can see and do within a group or project. Each member is assigned a role that defines their permissions.
Roles Overview
GitLab defines five base roles, from the most restricted to the most privileged:
| Role | Typical permissions |
|---|---|
| Guest | View issues and epics, create issues (project members only) |
| Reporter | Everything Guest can do, plus manage issues, labels, and milestones |
| Developer | Everything Reporter can do, plus push code, create MRs, manage branches |
| Maintainer | Everything Developer can do, plus manage project settings and members |
| Owner | Full control, including group/project deletion (group level) |
GitLab Ultimate also supports custom roles : roles built on top of a base role with additional granular permissions (e.g., a Guest who can also read code). Custom roles are configured at the instance level by a GitLab administrator.
For the full permission matrix, see the GitLab Permissions Documentation .
Group vs. Project Membership
Roles can be assigned at the group or project level:
- Group-level: The role applies to all projects within the group (inherited)
- Project-level: A specific role can be granted for a single project, independently of the group-level role
When a member has roles at both levels, the highest role always takes precedence. The group-level role acts as a floor: it can be raised at the project level, but never lowered.