Automation should use a token tied to a repository or project, not to a person. Bitbucket Cloud offers repository, project, and workspace access tokens, with project and workspace tokens on Premium. Bitbucket Data Center offers personal tokens plus project and repository HTTP access tokens, which need a Data Center license.
Why not a person's token
A token tied to a user stops when the user leaves, carries that person's permissions, and often has more access than the job needs. A resource token is scoped to one repository or project, so a leak has a smaller blast radius.
Cloud and Data Center side by side
| Question | Bitbucket Cloud | Bitbucket Data Center |
|---|---|---|
| Resource tokens | Repository, project, workspace access tokens | Project and repository HTTP access tokens |
| Plan | Workspace and project tokens need Premium. Repository tokens are not labeled Premium | Requires a Data Center license |
| Who creates | Not stated on the page | Project or repository admins |
| Scope control | Limited permissions set at creation | Read, write, or admin |
| Expiry | Optional expiry date | Optional, but an administrator can make it mandatory, and it cannot be changed later |
| Count limit | Up to 25 tokens per workspace, project, or repository, not increasable | Not stated |
Cloud details
Cloud access tokens are tied to one repository, project, or workspace rather than a user. They cannot be viewed or edited after creation, stop working when revoked, and cannot be used to log in to Bitbucket. Atlassian's page gives no scope list, so follow the permission pages it links to.
Data Center details
- Personal tokens are created under your profile, in Manage account, then HTTP access tokens. By default they get your current access level, and Atlassian recommends narrowing it.
- A repository permission must be at least as high as the project permission, and repository tokens cannot hold project level permissions.
- Since version 8.8, project admins can stop repository admins managing repository level tokens. Existing tokens are not deleted when this is turned on.
- Tokens cannot log in to the web UI, cannot act on a user's behalf, and cannot merge pull requests, since a merge creates a commit that needs a user with a valid email address.
- Project and repository tokens use Bearer authentication with no username. For Basic authentication the username is
x-token-auth. Atlassian recommends Basic for Git LFS because of known issues.
Good habits for both
- Create one token per integration, so you can revoke one without affecting others.
- Grant the lowest permission that works. A build that only clones needs read.
- Always set an expiry, and have a named owner and a renewal date.
- Store tokens in a secret manager, never in a repository.
- Review the token list each quarter and remove anything unrecognized.
- For cloud deployment credentials from Bitbucket Pipelines, consider OIDC.
Moving off app passwords
If you are migrating, see the API token checklist. Resource tokens are often a better fit than a user API token for build servers.
Quick check
Can a Data Center repository token merge a pull request?
No. Atlassian says tokens cannot merge pull requests because the merge creates a commit that needs a user with a valid email address.
Can I change a Data Center token's expiry later?
No. The expiry date cannot be changed after creation, though you can adjust permissions or revoke it.
Safeguard asset discovery and compliance evidence automation can support token and access reviews. Try a free scan at gold.safeguard.sh/scan.
Sources
- Repository, project and workspace access tokens, Atlassian
- HTTP access tokens, Atlassian Bitbucket Data Center
Last reviewed: 19 October 2026.
