Question / Feature Request - Non admin permissions for deployment environment variables

Question

We are using BitBucket Cloud and bitbucket pipelines to do most of the heavy lifting of our CI/CD. We need to set various env vars which need to be read at build time, i.e. during the pipeline run.

We are doing this via -> repo settings -> pipelines -> deployments. This works largely fine for our purposes.

In our dev team, anyone should be able to deploy, but they currently can't if their deployment includes adding/updating/removing an env var unless they are a repo admin.

It would be really helpful if there was a way to let non-admins access this page and update env vars, right now we need to grant admin perms to a wider group than necessary, this is a concern as admin perms also let someone delete the entire repo.

Daniel_Davies · Answer

Thank you for your reply, that API approach could be an option for us, but it's certainly a lot more work and a UI solution would be preferred. I've commented on that old issue but I'm not holding out too much hope like you say.

Gabriela - LeanZero · Answer

There's a path that avoids handing out repo admin, though it isn't that settings page.

Repository access tokens carry an "Edit variables" permission on its own. It maps to the pipeline:variable scope, documented as access to "create pipelines environmental variables in repositories and deployments". Deployments included, which is the part you need. Creating, updating and deleting deployment variables each need only that scope:

POST   /2.0/repositories/{workspace}/{repo_slug}/deployments_config/environments/{environment_uuid}/variables
PUT    .../variables/{variable_uuid}
DELETE .../variables/{variable_uuid}

Listing them needs plain pipeline, and that GET is where the environment_uuid comes from. Auth is a bearer header against api.bitbucket.org.

The token belongs to the repository instead of a person, and an admin mints it once. A deploy step can then set its own vars while the team keeps write, and none of the admin baggage rides along: no repo delete, no branch permissions, no ownership transfer.

This doesn't open the settings page to non-admins. And whoever can run the pipeline holding that token can edit variables, so the scope is what's doing your containment work.

Worth knowing before you raise one: the UI version of your ask is already on the tracker as BCLOUD-22182, raised 2022 and closed as Low Engagement in May 2025. So I wouldn't hold out for that route.

Nikola Perisic · Answer

Welcome @Daniel_Davies

This limitation makes sense, you can create requests here