Project Permissions

Doppler has four built-in project roles: Viewer, Collaborator, Admin, and None. You can also create custom project roles. Each role you assign to a user, group, or service account applies to the environments you choose. A member can hold several roles on the same project.

The workplace permissions model dictates that users with an Owner or Admin role always have full access to every project and environment. Users with a workplace role of Collaborator must be granted access on a per-project and per-environment basis. Users with the None project role have no project permissions. To refer to the None role from the API or Terraform, use the slug no_access.

Collaborators can perform actions that affect the configs they have access to. For example, they can manage secrets, trusted IPs, and service tokens. Collaborators can't rename or delete configs, because renames can break services that fetch secrets through the API.

The project permissions model lets you restrict a user's access at the workplace level while still giving them Admin access to individual projects. This keeps the number of workplace Owner and Admin users low without getting in the way of project administration tasks such as adding and configuring integrations.

Environment-scoped roles

Each role a member holds on a project is scoped to a set of environments. To give a member different access in different environments, assign them more than one role. For example, a developer on the backend project might hold these roles:

This developer can change secrets in development and staging and can only read them in production. You don't need a separate group for each access level.

The following rules apply to role assignments:

• A member can hold each role only once per project. To change the environments a role covers, edit that role instead of adding it again.
• A member must hold at least one role on a project. To take away all of a member's access, remove the member from the project.
• Roles that include the Access All Configs permission, such as Admin, always cover every environment in the project, including environments added later. You can't limit them to specific environments.
• Other roles cover only the environments you select. When you add an environment to a project, edit the relevant role assignments to include it.

How roles combine

A member's permissions in an environment are the combination of every role that covers that environment. Doppler combines the following sources and grants the most permissive result:

• The roles assigned to the user directly.
• The roles assigned to each group the user belongs to.
• The project role inherited from the user's workplace role, if any.

Two roles can cover the same environment. In that case, the member gets the permissions of both roles in that environment.

Personal configs

Personal configs are available to every user whose roles let them work with secrets in an environment that has personal configs enabled. Environment-scoped roles let you grant this access in development without granting it in production. For example, give developers Collaborator on dev so each one gets their own dev_personal config, and Viewer or None on the remaining environments.

Removing a user's access to an environment deletes their personal config in that environment. The dashboard asks you to confirm before it saves a change like this. You can't undo the deletion.

Change requests

Because permissions are evaluated per environment, you can grant the Approve Change Requests permission only where it's needed. For example, assign a custom role that includes Approve Change Requests to your production environment only, while the same reviewers keep Collaborator in lower environments. For more information, see Change requests.

Manage access from a project

To view and manage who can access a project, open the project and click Members.

The Member Access table lists each member with one line per role. The Environments column shows the environments each role covers. It shows All for roles that cover every environment. If a member inherits access to every project from their workplace role, that inherited role also appears, with a tooltip that explains where it comes from. To narrow the list, use the Project Role filter or search by name.

Add members

1. In the Add Members area, search for users or groups by name, group name, or email.
2. Select the members you want to add, then click Add.
3. In the dialog that opens, select a Project role and the Environments that role applies to.
4. Optional: To assign another role, click the + button and select a role and environments for the new row. Each role can be used only once.
5. Click Save.

The roles you select apply to every member you're adding.

Edit a member's roles

1. In the Member Access table, click the menu next to the member and select Manage.
2. In the Member roles section of the drawer, do any of the following:
   • To change the environments a role covers, update its Environments selection.
   • To add a role, click + Role, then select the role and its environments.
   • To remove a role, click the trash icon next to it.
3. Click Save.

The drawer also lists the member's inherited workplace role and, under Group roles, any roles they get through groups. These rows are read-only. To change them, edit the workplace role or the group's project access. To move to another member without closing the drawer, use the Previous member and Next member arrows.

Remove a member

To remove a member and all of their roles from the project, click the menu next to the member and select Remove. Removing a member immediately revokes their access to the project in both the dashboard and the API.

Manage access from the Team page

You can also manage a user's, group's, or service account's access to every project from one place:

1. In the dashboard, go to Team, then select the user, group, or service account.
2. In the Project Access table, do one of the following:
   • To grant access to a new project, click +, or Add Project Access if the member has no project access yet. Select a Project, then select each role and its environments, and click Save.
   • To change the roles on a project, click the menu next to the project and select Manage. Edit the roles in the drawer, then click Save.
   • To remove access to a project, click the menu next to the project and select Remove.

On a user's page, the Group column shows rows that come from the user's group memberships. You can't edit those rows from the user's page. To change them, go to the group's page.

Manage access with the API

Use the project member role endpoints to manage one role at a time. Each endpoint identifies the member by type (workplace_user, group, invite, or service_account) and slug:

Pass the project slug in the project query parameter. To add a role, send role and environments in the request body. To change a role's environments, send environments. Removing a member's last role removes the member from the project.

Member responses from the Project Members endpoints include a roles array with every role the member holds. Each entry has the role identifier, an access_all_environments flag, and the list of environments. The member's top-level role, access_all_environments, and environments fields describe only one of their roles, so read roles instead.

Manage access with Terraform

The Doppler Terraform provider has one resource per role assignment:

• doppler_project_member_user_role_assignment
• doppler_project_member_group_role_assignment
• doppler_project_member_service_account_role_assignment

The following example gives the engineering group Collaborator access to development and staging and Viewer access to production:

data "doppler_group" "engineering" {
  slug = "engineering"
}

resource "doppler_project_member_group_role_assignment" "backend_engineering_collaborator" {
  project      = "backend"
  group_slug   = data.doppler_group.engineering.slug
  role         = "collaborator"
  environments = ["dev", "stg"]
}

resource "doppler_project_member_group_role_assignment" "backend_engineering_viewer" {
  project      = "backend"
  group_slug   = data.doppler_group.engineering.slug
  role         = "viewer"
  environments = ["prd"]
}

For roles that cover all environments, omit environments.