Self-hosted Bitbucket alternative for EU data residency

Why EU data residency rules out Bitbucket Cloud for some teams

If your organization is a regulated EU entity that must keep source code, pull requests and the personal data inside them in-region, Bitbucket Cloud is not a viable option on residency grounds alone. Atlassian's data residency documentation lists Jira, Jira Service Management, Jira Product Discovery, Loom and Confluence as products that support data residency, and Bitbucket is not among them. That narrows the choice to two paths: self-managed Bitbucket Data Center, or a self-hosted forge such as GitLab, Gitea or Forgejo running in your own datacenter or EU cloud accounts.

Treat this as a decision about three things at once: the software, the support model and the physical location. Bitbucket Data Center runs on your infrastructure, but it is a licensed Atlassian product whose future is shaped by the Data Center sunset announced on September 8, 2025, and by the Hybrid License that existing customers are offered. GitLab, Gitea and Forgejo are open source, so the location is yours, but you choose who supports the platform and who patches it. Confirm with Atlassian in writing which Data Center terms apply to your contract before you compare costs.

For the GDPR angle, confirm three things before you commit. First, identify which personal data sits in repositories and collaboration objects, such as commit author details, review comments, issue text and user accounts, and record where each lives. Second, ask every candidate vendor where support staff access data from and whether telemetry or backups leave the EU. Third, check that your data processing records and transfer assessments reflect the chosen hosting model. DeployOpen can prepare the hosting controls and evidence for these checks, but independent auditors issue any assessment or certification.

What the residency constraint requires from a source hosting platform

A residency requirement for source code is less about one checkbox than about where each kind of data lives. Code, metadata, credentials and personal data can sit in different places, so the platform decision has to account for each of them.

Where code and metadata are stored

Repositories are only part of the record. Pull requests, review comments, issues, wikis, CI logs and artifacts also hold content and personal data. In a self-hosted forge, you decide where every one of these stores sits, on which disks, in which data center. For a hosted service, ask the vendor which region holds each category, not just the organization default. Confirm that the storage location covers metadata as well as Git objects.

Knowing which region holds data

Residency claims are only as useful as the documentation behind them. Some hosted Git services offer regional storage on specific plans and in specific regions, and the list of regions can differ by product. Ask for the written list of data categories and regions, and check whether it changes over time. For Atlassian products, the residency documentation names the supported products, and Bitbucket is not among them.

Data kept outside the chosen region

Some hosted services keep parts of their data in a different geography. Azure DevOps, for example, stores customer data in the geography chosen for the organization but keeps tokens and SSH keys in a US datacenter. Those credentials can grant access to code, so they belong in the residency review. List every component that holds credentials, tokens or keys, and where each one is kept.

Control over backups and upgrades

Copies of code and metadata made for backup, disaster recovery or staging can land outside the primary region if the platform does not let you choose. In a self-managed forge, backup targets, retention and restore testing are your decisions, and so are the timing and source of upgrades. Ask where backups are written, who can restore them, and how a vendor-operated upgrade or support session would access your data.

Personal data in commit history and reviews

Commit authors, reviewers, assignees and people named in issues are personal data under the GDPR in many cases, and Git history is hard to edit once published. Self-hosting gives you control over who can read this data and how long it is kept, but it does not remove the obligation to document it. Confirm with your data protection officer how author emails, deletion requests and retention of old repositories will be handled before the migration.

Which options can keep code in your region

This table compares Bitbucket Data Center, self-hosted GitLab, Gitea and Forgejo on in-region hosting, licensing, Bitbucket import paths and trade-offs. Read each row as a question to put to the vendor or your own architecture team, since residency depends on where you run the software, not only on which product you pick.

Criterion	Bitbucket Data Center	Self-hosted GitLab	Self-hosted Gitea or Forgejo
In-region hosting	Runs on your own infrastructure, so location follows your datacenter choice	Runs on your own infrastructure, so location follows your datacenter choice	Runs on your own infrastructure, so location follows your datacenter choice
Bitbucket Cloud residency	Bitbucket Cloud is not listed among Atlassian products with data residency	Not applicable, the Cloud service is not used	Not applicable, the Cloud service is not used
License model	Commercial, with Atlassian's Data Center end of sale and Hybrid License terms to confirm	Open core: MIT outside the ee/ directory, proprietary ee/ code needs a paid subscription	Gitea is MIT licensed; Forgejo is GPL-3.0-or-later from v9.0 with non-profit domain ownership
Governance and support	Atlassian sells and supports the product; confirm the lifecycle in writing	GitLab Inc. maintains the project; paid tiers are sold per user	Gitea has commercial support from CommitGo; Forgejo is governed by its own project and Codeberg e.V. holds domains
Import path from Bitbucket	Native product, no migration tool needed between Data Center products	Documented importers for Bitbucket Cloud and Bitbucket Server	Gitea has no Bitbucket importer; Forgejo dump-repo does not list Bitbucket, so use Git mirrors and a separate plan for pull requests
Air-gapped operation	Confirm with Atlassian for disconnected deployments	Documented offline and air-gapped installation guidance	Runs without external services when packages are mirrored internally; confirm your plugin and runner needs
Main trade-off	Familiar Atlassian integrations, with a licensing and lifecycle decision to make	Broadest feature set, with heavier sizing and a yearly major release cycle	Lightweight to run, with fewer built-in enterprise controls unless you buy them

How each option fits different EU team profiles

If you already run Bitbucket Data Center, the first question is whether the Hybrid License changes your EU position. Atlassian's journey to cloud page states that Bitbucket Data Center continues beyond 2029 and that existing customers gain a Bitbucket Hybrid License covering Data Center and Cloud. Atlassian's data residency documentation does not list Bitbucket among the products with regional storage, so the cloud side needs its own answer. Data Center in your own datacenter keeps repositories where you put them, and that is the part you control.

Renewal terms: Ask Atlassian to confirm in writing how the Hybrid License applies to your subscription and what Data Center support looks like after the sunset date Atlassian announced for March 28, 2029.
Residency scope: Confirm which data stays in your datacenter and which data, if any, reaches Bitbucket Cloud under the hybrid arrangement.
Self-managed peers: GitHub Enterprise Server and Azure DevOps Server also run on customer infrastructure, so compare software and support models, not only hosting location.
Migration effort: Moving to GitLab, Gitea or Forgejo means a separate plan for pull requests, comments and Pipelines, because Git history moves by clone or mirror.

Before you renew, put the Hybrid License scope, the support end date and your exit path in one document.

How to deploy a self-hosted forge inside EU infrastructure

This sequence takes a team from choosing an in-region host to a tested, cut-over forge that keeps repository data, pull requests and backups inside the EU boundary the organization has set.

Confirm the in-region hosting boundary
Your security or compliance lead, with the infrastructure team, records which datacenter, cloud region or private facility will hold the code, databases, object storage, backups and logs. Include administrator access paths and any support tooling that can reach the data. Confirm with your cloud or colocation provider where each service physically runs and which sub-processors can access it. The step is done when the boundary is written down and signed off, so every later decision can be checked against it.
Choose the install method and architecture size
The platform team selects a deployment method for the chosen forge. For GitLab, the documented installation methods include the Linux package, the Helm chart, the GitLab Operator, Docker and source installs, and the Linux package is described as the most mature and scalable option. Size the instance using GitLab's reference architectures, which run from 1,000 users to 50,000 users. Note that the reference architecture does not support running stateful components such as PostgreSQL and Redis inside Kubernetes, so a Kubernetes-based design must place those services on VMs or managed services. Confirm the user count, peak API load and availability target with the business owner. Done when a written architecture diagram exists and has been reviewed.
Plan the offline or restricted network option
If the environment cannot reach the public internet, the team follows GitLab's offline environment guidance and confirms how packages, container images, security scanner data and updates will arrive. Decide who will move software and advisory updates across the boundary and how they are verified. This step applies to any forge in a sealed network, and the team should confirm the offline support of each candidate product in writing before selecting it. The output is a documented update path that the security team has accepted.
Set up identity, access and encryption
The identity team connects the forge to the corporate directory using the authentication options the chosen platform documents, such as SAML or LDAP for GitLab, and defines which groups map to roles. Enforce multi-factor authentication for administrators, set repository visibility defaults and create branch protection rules for sensitive projects. Confirm that transport encryption, certificates and secrets storage meet your internal standard. Done when a test user can sign in through the directory, a non-member is denied access to a private project, and the access review owner is named.
Plan backup, restore and disaster recovery
The operations team designs backups for the repository data, database, uploads and configuration secrets, and stores copies inside the same EU boundary unless the compliance lead approves otherwise. Use the platform's documented backup and restore procedure, then test a full restore into an isolated environment. Record the recovery point and recovery time that the business accepts, and confirm them with the owners of the code. Done when a restore has been completed and the results are filed with the change record.
Mirror repositories and import pull requests
Git history can move with a clone or mirror from Bitbucket, including LFS objects after you confirm they were fetched. Issues, pull requests, reviews and wikis need a platform importer. GitLab can import from Bitbucket Cloud and Bitbucket Server, and Gitea and Forgejo have their own import paths, though Gitea has no Bitbucket importer, so confirm the path for your Bitbucket version before choosing a target. Respect Bitbucket API rate limits when exporting metadata in bulk. Done when a sample of repositories shows matching commit counts, tags, branches and LFS files, and when a reviewer confirms that pull request comments appear as expected.
Rehearse and cut over
The team runs at least one full rehearsal with a copy of the data, then freezes writes on Bitbucket for the agreed window and performs a final mirror sync. It updates clone remotes, CI runners, webhooks and single sign-on links, and it moves Pipelines variables manually because Bitbucket does not expose stored secret values for export. Confirm with each team lead that their repositories, permissions and pipelines work on the new forge. The cut-over is complete when the old Bitbucket repositories are read-only, the new forge passes the agreed checks, and the decommission date for Bitbucket is recorded.

Questions EU teams ask before moving source hosting in-region

What does an in-region move of source hosting cost?

The cost is driven by people, servers, storage, backups, upgrades and support, and most of it is staff time rather than software fees, because GitLab Community Edition, Gitea and Forgejo carry no license fee for the self-hosted core. The one-time costs are the migration, the target environment build and the integration with identity, CI runners and backup. The recurring costs are server capacity, storage growth, backup retention, patching and the platform team's time, plus any paid support or subscription you choose. GitLab's pricing page lists Premium at 29 US dollars per user per month billed annually, and Ultimate is custom priced, so ask whether a paid tier is needed for the controls you require. Ask any quote to split one-time from recurring costs and to show each component separately.

How long does a move from Bitbucket take?

The timeline depends on repository count, repository size, how much pull request and review history you need to keep, and how many integrations must be rebuilt. Git history moves with a clone or mirror, which is usually quick for a few repositories, but issues, pull requests, reviews and wikis need a platform importer or an API export. GitLab documents importers for Bitbucket Cloud and Bitbucket Server, while Gitea's migration code has no Bitbucket importer, so the plan for pull request history differs by target. Bitbucket Cloud's API limit of 1,000 requests per hour for most resources can stretch a bulk export. Ask the provider for a timeline built from an inventory of your repositories and integrations, not from a generic template.

What does our team need to provide for the work?

You need named owners for identity, networking, storage, backup and the CI runners that replace Pipelines, plus someone who can approve the data residency design. Your team also supplies an inventory of repositories, large files and LFS objects, branch permission rules, user and group mappings, and the Jira or other integrations that must keep working. Repository size matters because hosted services cap it, for example Bitbucket Cloud's 4 GB repository limit, so you should know which repositories are near that size. Confirm with the provider which of these inputs they need before work starts, and write them into the scope.

Can our own engineers run a self-hosted forge without outside help?

Yes, many teams run GitLab, Gitea or Forgejo internally, but the answer depends on how much operational depth you can staff. GitLab's reference architectures range from 1,000 users to 50,000 users, and GitLab recommends a high availability strategy for 3,000 or more users, which means Gitaly Cluster, PostgreSQL with Patroni, Redis Sentinel and Consul. GitLab's documentation says PostgreSQL and Redis inside Kubernetes are not supported, so the platform design matters. Gitea and Forgejo are lighter to run, but they still need backup, upgrade and security patching. Ask a provider to separate the work they deliver from the work you keep, and to name who does upgrades after handover.

Which forge should we choose for licensing and support?

The choice turns on license terms, governance and who supports the software. GitLab is open core, with MIT-licensed code outside the ee/ directory and proprietary code under the ee/ directory that needs a paid subscription. Gitea is MIT licensed and has commercial support from CommitGo, which sells Gitea Enterprise with SAML 2.0 service provider support, audit logging and mandatory two-factor authentication. Forgejo is GPL-3.0-or-later from v9.0, with its domains held by Codeberg e.V. and independent project governance. Confirm which features your security and identity requirements need, because some controls sit only in paid tiers or enterprise editions.

Does Bitbucket Data Center remain available after Atlassian's sunset dates?

Atlassian announced on September 8, 2025 that it is sunsetting its Data Center products by March 28, 2029, while its journey-to-cloud page states that Bitbucket Data Center will continue beyond 2029. Existing customers gain a Bitbucket Hybrid License covering Data Center and Cloud. Atlassian stopped selling new Data Center subscriptions on March 30, 2026, so a new in-region Data Center deployment is no longer a purchase option. Confirm the current terms in writing with Atlassian and in your renewal paperwork, since the choice between renewing, moving or replacing depends on those terms.

Does Bitbucket Cloud store code in the EU?

Bitbucket Cloud is not among the Atlassian products listed with data residency in Atlassian's data residency documentation, which covers Jira, Jira Service Management, Jira Product Discovery, Loom and Confluence. That means you should not assume your repositories stay in the EU, and you should ask Atlassian for the written position for your contract. A self-managed alternative puts storage, backups and logs in a datacenter or cloud account you choose, which is the main reason EU teams move. Your data protection officer should review the transfer and processor terms for any remaining hosted service.

Does moving in-region give us GDPR compliance by itself?

No, self-hosting supports GDPR obligations but does not provide them by itself. Storing code in-region helps you control where personal data in repositories, issues and logs sits, but you still need a records of processing, access controls, retention rules and breach procedures. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications, and independent auditors and certification bodies do that work. Ask your legal and security team to define the scope before the design is agreed.

Evidence a regulator or auditor will ask you to produce

A data residency decision is only as strong as the records behind it. The cards below list the evidence EU teams usually need to show when a regulator, customer or auditor asks where code lives, who can reach it and how it is kept running. DeployOpen prepares this evidence inside your environment, but auditors and certification bodies issue the conclusions.

Data location record

Document the physical location of every component that holds code, issues, reviews and backups: the application servers, the Git storage, the database, the search index and each backup copy. Record the datacenter, country and cloud region for each, and confirm that no component sends telemetry, package metadata or runner logs to a location outside the EU. Ask your forge vendor or project to confirm which optional features call external services, since these are the gaps most often missed.

Access control and authentication configuration

Keep an exported and dated copy of the authentication settings: the identity provider link, SSO enforcement, two-factor requirements, repository visibility defaults, branch protection rules and organization roles. Auditors usually test whether a departing developer loses access on the same day and whether administrators are a short, named list. Store the configuration as code where possible so changes leave a history.

Backup and restore test results

A backup policy is only evidence once a restore has been performed. Record the backup schedule, retention period, encryption method and storage location, then keep dated results from restore tests that rebuild a sample project, its issues and its pull requests in a separate environment. Note the time each test took and any gaps found, and retest after every platform upgrade.

Upgrade and patch record

Keep a log of every version you run, the date you moved to it and the security fixes it carried. Compare the log against the release cadence your chosen platform publishes, so you can show that you applied security fixes within the window the vendor backports them. For GitLab, check the maintenance policy and the required upgrade stops, since skipping one can block an upgrade entirely.

Processing records for personal data in repositories

Repositories, issues and review comments often contain names, email addresses, commit author data and sometimes personal data pasted into tickets. Under GDPR, record the purposes, categories of data, recipients, retention periods and transfer status for this processing, and identify who acts as controller and processor for each forge instance. Add a plan for handling erasure requests in Git history, which cannot be edited without rewriting commits.

Vendor and project support agreements

List every party that can change or repair the platform: the open-source project, any commercial support vendor, your implementation partner and your hosting provider. For each one, keep the written agreement, the support hours, the response commitments and the named escalation contact. Where a project has no contractual support, record that fact so the risk is visible and accepted by the owner of the system.

What moves in a Bitbucket to in-region migration

Git history is the easy part of this move. A clone or mirror carries every branch, tag and commit to a self-hosted forge in your own datacenter, and that step does not depend on which platform you pick. What does not travel with a clone is the rest of the collaboration record: pull requests, review comments, issues and wiki pages. Those need a platform importer, and the importer coverage differs by target. GitLab's documented import sources include Bitbucket Cloud and Bitbucket Server, so a GitLab target can bring pull request and issue data across through its own tooling. Gitea's migration code, per the go-gitea/gitea repository, has importers for GitHub, GitLab, Gitea, Gogs, OneDev, GitBucket, Codebase and AWS CodeCommit, but not Bitbucket, so a Gitea target means a separate plan for historical pull requests. Confirm the importer status for your exact Bitbucket edition and version against the current documentation before you commit to a target.

Forgejo's dump-repo command covers git, GitHub, Gitea and GitLab sources, and it does not list Bitbucket. For a Forgejo target, the realistic path is a Git mirror for history, with pull request and review records either archived as exports or left in Bitbucket as a read-only reference. Decide early which of those records your auditors and legal team need to reach, because that choice determines how long the Bitbucket contract must stay open.

Two items never move by import and need their own workstream. The first is Pipelines: build definitions in bitbucket-pipelines.yml must be rewritten for the CI system you choose, and any secured variables stored in Bitbucket cannot be read back, so they must be re-entered from your secrets store. The second is access rules: branch permissions, workspace and project roles, and group memberships must be recreated on the new platform and mapped to your identity provider. Document each of these as a checklist item with an owner, and confirm what your export process can and cannot retrieve before the Bitbucket contract ends. For the full export steps and API rate limits, see How to export your data from Bitbucket.

How DeployOpen works on this

DeployOpen plans, implements, hardens, backs up and documents self-hosted open-source forges inside the client's own infrastructure, so repositories, reviews and CI data stay where the residency rules require. For EU teams, the work starts with where code and metadata must live, then fixes the platform choice to that answer.

How we scope

Map which repositories, issues, reviews and CI logs fall under the residency and GDPR obligations for your organization.
Confirm the target EU datacenter, cloud region or air-gapped network, and who holds administrative access there.
Agree the forge choice among GitLab, Gitea and Forgejo in writing, with deliverables and timelines, before any work starts.

How we build

Install the chosen forge in your environment with its database, object storage, SSO and TLS configured to your standards.
Migrate Git history by mirror, and move pull requests and issues with the platform importer or a documented export.
Test access controls, backups and restore procedures, and run the security checks agreed in the scope before go-live.

How we hand over

Deliver architecture, runbooks, data flow records and configuration documentation that your team can keep current.
Train administrators on upgrades, runner management and restore testing so operations stay with your staff.
Prepare evidence for your compliance assessment, while independent auditors and certification bodies issue any formal reports.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Upgrade planning follows each platform's documented release and upgrade path, checked against your change process.
Ask any provider, including DeployOpen, to confirm support windows, SLAs and the exact scope of a retainer in writing.