Bitbucket backup
Bitbucket comes in two forms at customers: Bitbucket Cloud as a service from Atlassian, and Bitbucket Data Center run by the customer. Most people assume the self-hosted one is the better protected.
It is the other way round. The vendor's two lists are of different lengths, and the difference is large enough to change what you can promise. That is why this page starts with the comparison rather than with a feature list.
ARJ Distribution sells exclusively through resellers and MSPs in the Nordics — Sweden, Norway, Denmark, Finland and Iceland. We never sell directly to end customers.
The vendor's list for the self-hosted version is considerably shorter than the one for the cloud version. That is the opposite of what most people assume — and you only see it if you put the two pages side by side.
Cloud and Data Center side by side
Each version has its own page in the vendor's documentation. Set next to each other, they look like this:
Why this deserves a conversation rather than a footnote: a customer who moved to Data Center often did so to get more control. That the protection then becomes narrower than in the cloud is not obvious to anyone, and it is not something you want to discover during a restore.
Bitbucket Cloud in detail
From the vendor's own list, which has nine main areas:
| Area | What it covers |
|---|---|
| Repository | Branches, commits with creator and text, tags, refs, objects, logs, LFS and wiki — plus the details: description, forking, language, name, project and website. |
| Pull requests | Open ones, with comments, commits, reviewers, title, description, creator and creation date. Read the note below. |
| Issues | Open and closed, with assignee, attachments, comments, description, kind, priority, status and title. |
| Pipelines | Whether pipelines are enabled, the configuration file, repository variables, known hosts, and schedules with selected branch and pipeline. |
| Branch restrictions | Branch name, pattern and type, merge access via pull request, merge conditions such as minimum approvals, successful builds and unresolved tasks, plus write access including deletion and rewritten history. |
| Branching model | Prefixes for bugfix, feature, hotfix and release, development and production branches, and inherited settings. |
| Other | Access keys with label and key, downloads with file name and content, and webhooks with their triggers for issues, pull requests and the repository. |
One thing to keep in mind: the vendor states no explicit limitations for Bitbucket Cloud — but the pull request list mentions only open ones. Closed and merged are not listed, unlike on GitHub and GitLab, where they are named explicitly. If the customer needs to go back to a completed review, ask us first — we have put the question to the vendor.
Bitbucket Data Center in detail
This list is short enough to reproduce in full. The vendor states: branches, commits, LFS, pull requests, repository, tags and webhooks.
That is seven entries with no sub-items, against Cloud's nine areas with considerably more. Issues, pipelines, branch restrictions, branching model, access keys and downloads — everything that describes how the customer works rather than what they store — is missing from the Data Center list.
That does not automatically mean it is not possible. It means the vendor does not say that it is, and then we do not promise it. See the next section.
What we do not promise yet
While going through this we found a contradiction in the vendor's documentation, and we have chosen to report it rather than paper over it.
The Data Center page's summary line describes the protected resources as including wikis and metadata. The list on the same page contains neither wiki nor metadata. We therefore do not know which applies, and we have asked GitProtect.
Until we have an answer: do not promise wiki or metadata on Bitbucket Data Center. If the customer needs it, ask us first — we have the vendor relationship and get an answer faster than an individual partner does.
The same goes for the difference itself: we have asked the vendor to confirm that Data Center really does lack what Cloud has, or explain why the lists differ. We do not think the difference is a mistake in the product — but it may well be a mistake in the documentation, and both outcomes matter to you.
Four questions to ask the customer
- Cloud or Data Center? On Bitbucket this is not an administrative question — it decides what can be protected.
- Do you use Bitbucket's own issues? Many run Jira instead, and then the question does not matter. If they do not, it is decisive on Data Center.
- How much sits in branch restrictions and the branching model? That is often what satisfies the customer's own rules for how code reaches production.
- Do you run Bitbucket Pipelines? If yes, and the customer is on Data Center — ask us before promising anything about them.
Why through a distributor
We do not sell to end customers. That is not a courtesy — it is the business model: everything goes through you, and we never compete with you at your customer.
What you get besides the licences: technical pre-sales help, support during a proof of concept, support in English and Swedish, and a named contact who knows your business instead of a ticket number. The uncertainty described above is an example of what we do for you: we read both pages, compared them, and asked the question.
Getting started
Tell us whether the customer runs Cloud or Data Center, and what they use besides the repositories themselves. Then we will tell you what can be promised, and what it costs.
Read more
Tell us about your project
or book a short technical call
About the content on this page. This is a sales-oriented overview — not complete product documentation. The information is taken from GitProtect's own documentation in October 2026 and we review it regularly, but features and support change — and a change can get past us. So always check against the vendor's current documentation before anything is promised to a customer: GitProtect's knowledge base. If you are unsure, it is faster to ask us — we take the question to the vendor and come back with an answer you can put in a quote. And if something does not work the way it is described — here or in the vendor's documentation — tell us. We report it to the vendor and correct the page.