Roles and permissions are used to configure role-based access control (RBAC) for your projects.
A permission is a key that grants access to some piece of functionality. A role is a unique set of permissions.
You can assign the following two types of roles to users:
- Organization roles: Manages access to the organization.
- Project roles: Manages access to the project and its resources.
A combination of organization and project roles defines a user's access.
Organization roles control access to your Redocly organization and are provided by your identity provider through claims or attributes, similar to how teams are configured.
| Permission | Owner | Member | Billing | Viewer |
|---|---|---|---|---|
| Can create projects | ||||
| Can manage projects | ||||
| Can view organization settings | ||||
| Can manage organization settings | ||||
| Can manage subscription details (billing) | ||||
| Can view and manage people | ||||
| Can manage teams | ||||
| Can manage SSO and login | ||||
| Can manage API keys | ||||
| Can access compliance reports | ||||
| Can manage self-hosted Git providers |
Redocly recognizes these special role names from your identity provider:
redocly.owners(owner): has permission to everything, including the ability to invite people, change access controls, and review feedback; has admin access to all organization projects by defaultredocly.members(member): can access project workspaceredocly.billing(billing): can manage billing of the organizationredocly.viewers(viewer): has read-only permission to published projects
Organization roles are assigned differently depending on your authentication method:
With SSO/Identity Provider:
- Roles are automatically assigned based on claims or attributes from your identity provider.
- Configure your identity provider to send the appropriate role claims (like
redocly.ownersorredocly.members) for each user. - Roles assigned through SSO override any roles manually set in Redocly.
With Redocly's login system:
- Organization owners can manually assign roles from the People page.
- Roles are set and managed directly within Redocly's interface.
committer: Automatically assigned to users who commit content to the project through an integrated Git connection or remote content source. You cannot assign the committer role; it can only be automatically assigned. Users with the committer role cannot access Reunite.
Users who commit content to your project either through an integrated Git connection or remote content source are automatically assigned a committer role and are displayed on your People page. A single user can be displayed as two different users if they have an alternative email address for logging into the different systems.
Link duplicate users with the committer role to their Reunite user account to merge these entries.
The member organization role is sufficient for most users, giving them access only to the Projects page in the organization workspace. From the Projects page, members can select projects. Their access to individual projects is determined by their project roles.
For specific project functionality access, project roles can be assigned to teams of users.
Project roles are assigned to teams for each specific project in the redocly.yaml configuration file.
Users with the Owner organization role have full access to all projects. Access granted to organization Members is based on project-level roles. Members without an explicit project role have the admin role by default.
The following is a list of available project roles:
none: grants no access permissionsread: grants read-only access to files or pages; Pro and Enterprise onlytriage: grants read access to files or pages; also grants the ability to see logs and other information; for contributors who need to proactively manage issues, discussions, and pull requests but do not need write access; Enterprise onlywrite: grants read and write access to files or pages; also the ability to comment on reviews; for contributors who actively push updates to your project; Enterprise onlymaintain: grants most access permissions except settings, user management, and permissions; for contributors who need to manage the repository but do not need access to sensitive data or destructive actions; Enterprise onlyadmin: grants all access permissions; for people who need full access to the project, including sensitive data and destructive actions like managing security or deleting a repository
When users become members of a team, they are granted access based on the roles assigned to the team.
| Permission | admin | maintain | write | triage | read | none |
|---|---|---|---|---|---|---|
| Can access the editor | ||||||
| Can create and delete files | ||||||
| Can create and delete branches | ||||||
| Can take the project live | ||||||
| Can commit changes | ||||||
| Can view pull requests | ||||||
| Can create pull requests | ||||||
| Can assign reviewers to pull requests | ||||||
| Can comment on pull requests | ||||||
| Can close and reopen pull requests | ||||||
| Can request changes in pull requests | ||||||
| Can approve pull requests | ||||||
| Can merge pull requests without requirements | ||||||
| Can view deployments | ||||||
| Can trigger a deployment | ||||||
| Can promote a past deployment to production | ||||||
| Can add remote content | ||||||
| Can view the Remote content page | ||||||
| Can delete remote content integrations | ||||||
| Can view the Respect Monitoring page | ||||||
| Can access and manage Feedback | ||||||
| Can access Analytics | ||||||
| Can view and manage project settings | ||||||
| Can delete projects | ||||||
| Can set a custom domain | ||||||
| Can manage environment variables | ||||||
| Can manage Git hosting | ||||||
| Can manage branches and deployments strategy |
- RBAC concepts - Understand the different components involved in Redocly's role-based access control system and how they work together
- Teams and users management - Configure teams and manage user assignments, including adding users to multiple teams for flexible access control
- RBAC configuration guide - Step-by-step instructions for implementing RBAC with examples for projects, pages, and navigation
- RBAC configuration reference - Complete configuration details and options for role-based access control implementation
- Link duplicate users - Resolve duplicate user entries by linking committer accounts to their Reunite user accounts