A release manager asks for permission to push a build to staging. To say yes, you have to make them a repository administrator — which also hands them the power to rewrite branch rules, edit merge checks, and delete the repository outright. You say yes, because the release has to ship. Then you make a note to tighten it up later. Later, as ever, does not come.

That trade-off has been baked into how teams run source control for the better part of two decades, across every platform rather than any one of them. On three consecutive days this week, Atlassian shipped three separate Bitbucket features that each dissolve a piece of it. They landed without much fanfare, which is a shame, because unglamorous permission plumbing is where I spend an embarrassing share of my professional life — and taken together, these three releases say something more interesting than any one of them says alone.

Monday: separating ‘can merge’ from ‘can deploy’

On July 20, Bitbucket Pipelines introduced custom deployment permissions, currently in beta. You can now gate a specific environment to named users and groups from Repository settings → Pipelines → Deployments: add people or groups, audit who currently holds access, revoke it when they move on.

The detail that made me sit up is that this lets you separate who can merge code from who can deploy it. That is segregation of duties — the thing your auditor asks about every single year — and it becomes something you can point at in a settings panel rather than something you have to explain in a paragraph. Release managers, SREs, and on-call engineers can hold deployment rights to a sensitive environment without ever becoming repository admins.

A few things to know before you plan around it. This needs a Premium workspace, Pipelines enabled, and at least one environment configured. Each environment supports up to 100 users and groups combined. And here is the behavior worth rehearsing: deployment permissions take precedence over scheduled and automated deployments too, so an unattended release will halt and wait for an authorized human to resume it. That is the right call — a gate that automation can walk around is not really a gate. It is also the kind of thing you want to meet in staging rather than at 2 a.m.

Tuesday: share the artifact, not the repository

On July 21, Bitbucket Packages gained internal packages. Every package until now — container images, Maven, npm, PyPI, NuGet — lived inside a single repository and inherited that repository’s permissions. That is the right default most of the time, but it meant letting another team pull a shared base image required granting them read access to source code they had no particular need to see.

Mark a package internal and any member of the workspace can pull it from anywhere, without being given anything on the linked repository. The source repo stays hidden — kept out of breadcrumbs, URLs, and package details — so nothing leaks about where it lives. Pipelines in other repositories can pull it too, which clears the builds that used to sit waiting on an access request.

The design restraint is the part I admire most. Internal changes who can read a package. It never changes who can write to one. Push, publish, delete, and visibility changes all still require write access to the linked repository, and there is no cross-repository write tier at all. Private stays the default, so nothing moves until you deliberately move it. Sharing widened; authority did not. That is a disciplined piece of product design, and the restraint is what makes it safe to turn on.

Wednesday: main is not where most teams ship from

On July 22, Bitbucket Tests began tracking up to five branches per repository rather than only the default. Integration happens on develop. Stabilization on staging. Releases cut from release. Atlassian named this one of the most requested capabilities during the Tests beta and turned it around quickly — the kind of responsiveness worth pointing out when you see it.

Failure rates, flaky scores, and test history now aggregate across every tracked branch, and each execution shows the branch it came from, with a filter to isolate one. If you followed our earlier piece on Bitbucket’s agentic pipelines, this is the missing input: automated flaky-test detection is only ever as good as the branches it can see.

Three releases, one assumption

Here is the throughline. For most of Git’s corporate life — across every platform, not any single vendor — the repository has been the unit of everything: the unit of access, the unit of sharing, the unit of truth. If you needed to do anything with a repository’s outputs, you needed rights to the repository itself.

Each of these features severs one strand of that assumption. Deployment permissions detach the right to release from the right to administer. Internal packages detach the right to consume an artifact from the right to read its source. Multi-branch tests detach your picture of quality from the default branch. Three different teams, three different surfaces, one direction of travel: the repository becomes one boundary among several rather than the only one that counts.

That is worth knowing if Bitbucket is on your evaluation list, and it lands in the same stretch as Atlassian’s fourth consecutive year as a Leader across Gartner’s DevOps and DevSecOps research, placed highest in execution this time around. Recognition like that tends to be built from precisely this sort of steady, unglamorous plumbing — which is also what makes a platform pleasant to live in three years after you adopt it.

The Avaratak Take

Granular permissions are only an improvement if somebody owns them. Each of these features replaces a single coarse control with several precise ones, and precise controls drift — quietly, and always in the direction of ‘just add them, we’ll tidy it up later.’ A permission model with a hundred well-meant entries and no review cadence is not more secure than a blunt one. It is simply harder to audit. That part is on us as operators, not on the tooling.

So the work is genuinely small, and I would do it in this order. Pick the one environment where an accidental deploy would ruin your quarter and gate that first, rather than all of them at once. Look at which packages currently require repository access on paperwork rather than on merit, and make those internal. Add the two or three branches your team actually ships from to test tracking, and leave the rest alone. Then put a recurring thirty minutes on someone’s calendar to read the access lists out loud. That last step is the one everybody skips, and the only one that keeps the other three honest.

One more thing worth saying plainly: these controls matter more now that agents are doing real work in your pipelines, not less. When a coding agent can open a pull request on its own, an environment gate stops being bureaucratic overhead and becomes the thing standing between an autonomous merge and an unattended production release. Shipping this now, ahead of the first incident rather than after it, is good timing. We made a version of this argument about governing your context layer recently; this is the same principle, one layer further down the stack.

If you would like a second set of eyes on your Bitbucket permission model — or a hand putting these three capabilities to work without creating a governance headache six months from now — that is exactly the conversation we enjoy at Avaratak. Come find us at avaratak.com. Bring your access list; we’ll bring the good questions.