The best developer platform for large enterprises with data residency requirements

GitLab Dedicated lets a customer choose the AWS region that holds its instance from a published table that includes Mumbai, Hyderabad, Singapore and Cape Town, and GitLab's hosted runners for Dedicated run on AWS "in the same region as your instance." That is why we name GitLab the best developer platform for a large enterprise with data residency requirements. GitHub Enterprise Cloud with data residency offers the EU, Australia, the US and Japan, and Atlassian's rollout notice says "Bitbucket Cloud currently runs out of a single region."

GitHub is the better pick when one of those regions satisfies your rule and you want accounts provisioned from your own identity provider, since Enterprise Managed Users is the only identity option on its residency service. Atlassian suits an existing Bitbucket Data Center customer that keeps its repositories on servers it runs and plans around the Hybrid License Atlassian has announced for those customers.

What should a large enterprise with a residency rule weigh in a developer platform?

The UK National Cyber Security Centre tells cloud customers to "ensure the locations in which your data is stored and processed meet your needs." On a developer platform those are separate questions, because each of these vendors documents its hosted build runners apart from its repository hosting. So the first check is the list of regions where the vendor will hold your code, and the second is what the vendor says about the data it keeps elsewhere. The UK Department for Work and Pensions, one buyer with such a rule, requires contractual data-residency clauses from its cloud suppliers.

CIOPages' buyer guide for source code management platforms lists "runner/agent model and self-hosted runners" among the points to evaluate. All three vendors document runners you operate yourself alongside their hosted ones. Size your peak concurrent jobs against the hosted capacity in each proposal, then decide whether added hosted capacity, queued work or runners you operate suits your workload and the locations your rule permits.

GitLab, GitHub and Atlassian each sell an edition that runs on infrastructure you operate, so you control where the repositories are placed. Scope the data handled by builds, backups and connected services as separate questions. The edition also moves the operating work to you, and the DWP policy asks for a documented division of responsibility between buyer and provider for each service. The vendors' sizing tables for these editions describe recommended or tested workloads, so read each one against your own request rates and repository sizes.

The NCSC's cloud security principles treat service resilience as part of protecting an asset. An uptime commitment names the functions it covers and the period it is measured over, and the remedy is a credit against fees. Read it for the edition you are buying and for the functions your developers use every day, Git operations and CI job starts among them.

The CIOPages guide also lists "large-binary handling" and the performance of large monorepos. An enforced limit rejects the push that crosses it, so a monorepo or a repository of large binaries has to fit the target platform before a migration starts.

GitLab, GitHub and Atlassian compared on residency and scale

GitLab: a single-tenant instance in the AWS region you choose

GitLab's Dedicated overview describes a single-tenant deployment that GitLab operates on AWS for customers on the Ultimate tier. At onboarding the customer selects a primary region and can add a secondary region for disaster recovery, and the data residency page says the primary region "must meet your data residency requirements." Its supported-region table also lists Jakarta, Seoul, Zurich, Tel Aviv and São Paulo.

The table marks its Bahrain and UAE entries "currently unavailable" and sends customers who want them to a support ticket. Services differ by region as well: where AWS's email service is not offered, the customer configures an external SMTP server. Dedicated runs on AWS alone, and the overview lists LDAP and Kerberos authentication among the features it does not include, so an enterprise standardized on another cloud or on LDAP sign-in fits it less well.

Hosted runners for Dedicated are autoscaling runners on AWS EC2 in the instance's region, with each job on its own temporary virtual machine, per GitLab's runner documentation. Each production runner stack supports up to 1,000 jobs running at once; jobs beyond that queue, and runner tags spread work across more than one stack. GitLab's disaster recovery page adds that hosted runners are supported in the primary region only and are not rebuilt in the secondary region.

GitLab's service level agreement commits to 99.9% monthly uptime for GitLab.com and Dedicated subscriptions bought or renewed on the Ultimate tier on or after January 1, 2026. It counts Git operations over HTTPS and SSH, issues, merge requests, and the container and package registries, and it pays credits against monthly fees when a month falls short. Scheduled maintenance windows and beta features sit outside the count. Hosted runners for Dedicated carry a separate monthly commitment, measured on how quickly pending jobs start.

GitLab Self-Managed runs on infrastructure of your choice, "whether on a cloud provider or on-premises," in the words of the reference architectures page. The largest Linux package design there is for 50,000 users, with a test target of 1,000 API requests a second, and GitLab calls the designs "recommended starting points." The page warns that AI agent usage "doesn't scale with user count" and can push load past those targets. A single environment stays in one region, and GitLab Geo is the supported design for more than one.

On Dedicated, the instance setup page lists an initial storage size for repositories among the instance inputs, with total purchased storage set by the contract, and says repository capacity "can only increase." The account team sizes the instance as a reference architecture tier "named by maximum recommended user count." On Self-Managed, administrators set repository size limits themselves, and no maximum push size is set by default.

GitHub: residency regions with accounts managed by your identity provider

GitHub's documentation for Enterprise Cloud with data residency counts Azure regions in Norway and Switzerland, both EFTA countries, within its EU option. The service requires Enterprise Managed Users, with SAML or OIDC sign-in and SCIM provisioning from your identity provider.

Repositories, pull requests and comments, GitHub Actions data and logs, and disaster recovery data are stored in the chosen region, GitHub's data storage page says. The same page lists what GitHub keeps outside it: telemetry and logs tied to user identifiers, billing and contact information, support data, and GitHub Copilot data by default. A policy that restricts Copilot to data residency compliant models keeps prompts and responses in the region. The page gives the reasons data leaves the region and says GitHub does not notify customers when a transfer occurs.

Hosted runners attached to Azure private networking are deployed in the same Azure region as the subnet you connect, and GitHub's network details for GHE.com name the supported Azure regions for each residency region, France Central and Sweden Central among them for the EU. The feature overview for GHE.com lists macOS runners and GitHub Marketplace as currently unavailable and public repositories as permanently unavailable, which matters to a team that builds for Apple platforms on hosted runners.

On the Enterprise plan, GitHub's Actions limits allow 500 concurrent jobs on standard hosted runners and 1,000 on larger runners, and a job on a hosted runner ends at 6 hours. GitHub's repository limits enforce a 2 GB ceiling on a push and block a single object at 100 MB.

GitHub's Online Services SLA commits to 99.9% uptime per calendar quarter for GitHub Enterprise Cloud, GitHub Actions and GitHub Packages. For Enterprise Cloud it measures Git operations, issues, pull requests, Pages and webhooks, with API requests to them, and for Actions it counts executions that fail to run. Credits are a share of the fees for that quarter, and the SLA excludes scheduled downtime and preview features.

GitHub Enterprise Server 3.22 is a virtual appliance that runs on VMware, Hyper-V, KVM, AWS, Google Cloud or Azure, per GitHub's overview of the product. Its installation guide recommends hardware by user-license band, and the top band, 8,000 to 10,000+ users, lists 64 vCPUs and 512 GB of memory. Actions on Server runs on self-hosted runners only. The overview points an enterprise whose main requirement is in-region data toward the residency cloud, and Enterprise Live Migrations moves repositories from Server to GHE.com.

Atlassian: self-managed Bitbucket while Cloud residency is planned

Atlassian's rollout notice for Bitbucket Cloud plans EU data residency in stages: an early access program for eligible customers in December 2026, and general availability for new and existing Premium workspaces in September 2027. An earlier engineering post names "source code, pull requests, and repository metadata" as data the regional design will cover. Atlassian's data residency page lists Jira, Jira Service Management, Jira Product Discovery, Loom and Confluence as the apps an admin can pin, and Bitbucket is not among them, so pinning a Jira site does not settle where the repositories are stored.

Atlassian's Data Center end-of-life page exempts the self-managed Bitbucket product: "Bitbucket and Bamboo Data Center will not end of life." The Hybrid License is announced for early 2027, for existing Bitbucket and Bamboo Data Center or Server customers. Under it they keep the self-managed environment where it is, with no data transfer required, and gain access to Bitbucket Cloud Pipelines. Pipelines on Bitbucket Cloud is the vendor-run side of that license, so scope with Atlassian which builds and data would use it. Legacy Data Center licenses change over to the Hybrid License in 2029.

Atlassian's AWS sizing guide for Bitbucket Data Center publishes a Large test profile of about 25,000 active users. The test ran on Data Center 5.16, and the guide presents its profiles as planning recommendations for sizing.

On Bitbucket Cloud, the step options for Pipelines allow 100 steps in a pipeline, and a step times out at 120 minutes unless the max-time option is set. Self-hosted runners execute steps on your own infrastructure, and with Premium Runners the runner configuration can send artifacts and caches to an S3 bucket in an AWS region you choose.

Atlassian's cloud SLA commits Bitbucket Cloud Premium to 99.90% monthly uptime, measured on pull requests in the browser, Git over HTTPS and SSH, and pipeline starts on Atlassian-hosted runners. Credits apply to production instances, and trials and sandboxes are ineligible. Bitbucket Cloud limits a repository to 4 GB, and a default setting that admins can turn off blocks files of 100 MB or more.

Which developer platform should a large enterprise with data residency requirements choose?

GitLab is our pick for a large enterprise with data residency requirements. Dedicated's region table reaches India, Singapore and South Africa, where GitHub's residency service lists no region, and GitLab documents its hosted runners in the same region as the instance. An enterprise that prefers to run the platform itself has GitLab Self-Managed, with published designs for large user counts.

GitLab's region choices are permanent once the instance is provisioned, and that is the commitment to weigh. For an enterprise whose proposed primary region meets its policy and that can accept a permanent selection, we put the listed regions and the runners placed in the primary region above that commitment. Confirm before signing that the region you need is open and offers the services you use, since GitLab's region table marks some entries unavailable and service support varies by region.

GitHub is the better pick when one of its regions satisfies your rule and you want every account provisioned from your identity provider. Its documentation spells out which data stays in the region and which leaves it. For builds, hosted runners on Azure private networking sit in the Azure region of your own subnet, which suits an enterprise already on Azure.

An enterprise already on Bitbucket Data Center has the strongest case for Atlassian. Its repositories sit on servers it runs, and the announced Hybrid License keeps that environment in place for existing customers with no data transfer. Scope the license terms and the Cloud Pipelines connection with Atlassian, and treat EU residency on Bitbucket Cloud as a plan until it ships.

Other developer platforms