Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

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

Daniel_Davies
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
September 3, 2026

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.

2 answers

0 votes
Gabriela - LeanZero
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Champions.
September 3, 2026

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.

0 votes
Nikola Perisic
Community Champion
September 3, 2026

Welcome @Daniel_Davies 

This limitation makes sense, you can create requests here

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
TAGS
AUG Leaders

Atlassian Community Events