Why an EU residency requirement pushes Azure DevOps Services out of scope
If your organization is regulated in the EU and must show where source code, work items, credentials and build data live, the short answer is that Azure DevOps Services keeps personal access tokens and SSH keys in a US datacenter and sends data from Microsoft-provided macOS build agents to a GitHub datacenter in the United States. Microsoft's data locations documentation says customer data such as source code and work items stays in the geography you select, with limited exceptions, but those exceptions are exactly what a strict EU-only position has to test. A requirement that all data stays in the EU therefore cannot be met by the hosted service as documented, and the choice is between accepting a documented exception in writing and moving to a self-hosted option.
Confirm the exact scope of that exception with your Microsoft account team and your data protection officer before you decide. Ask which tokens, identities and profile fields are covered, whether preview services are in use (Microsoft says preview services typically store data in the United States), and which of your pipelines run on Microsoft-hosted macOS agents. Record the answers in your data inventory, because an auditor will ask where each category of data lives, and a sentence that says "geography-selected" will not answer for tokens or build logs.
Choosing open source is a choice of software and support model as well as location. Azure DevOps Server, GitHub Enterprise Server and Bitbucket Data Center all run on your own infrastructure, so a self-managed commercial edition can also keep data in an EU data center. Self-hosted GitLab, Gitea or Forgejo moves the operating burden to you: you own the servers, backups, upgrades, identity integration and the vendor relationship for support. Ask each candidate who signs the support contract, which upgrade path it documents, and whether its license terms let you run it in your own environment without a metered fee for data residency.
What EU data residency requires from a Git platform
A residency policy usually reaches further than the repository itself. Source code, credentials, build agents, backups and administrators each hold data or access that may sit outside the region you expect, so each one needs its own answer before you choose a platform.
Repositories and work item data
Source code, work items, test results and their geo-redundant mirrors and offsite backups are kept within the geography chosen for an Azure DevOps Services organization, with limited exceptions. Ask your vendor to confirm which exceptions apply to your tenant and which data types they cover. For a self-hosted GitLab, Gitea or Forgejo, the question becomes which data center holds the server and its storage volumes.
Tokens and SSH keys
Personal access tokens and SSH keys for Azure DevOps Services are stored in a US datacenter, even when the organization's code is in the EU. If your policy covers credentials as personal or security data, this is a gap you must document or accept in writing. A self-hosted forge keeps these credentials in the database you operate, so you can state exactly where they live.
Build agents and transit data
Azure DevOps builds that use Microsoft-provided macOS agents transfer data to a GitHub datacenter in the United States. Pipelines that compile Apple targets therefore move data outside the EU even when the project is in an EU geography. Check every pipeline for hosted macOS jobs, and decide whether to use self-hosted runners in your own network for those builds.
Preview services and profile data
Preview services typically store data in the United States, and profile data for users outside the US, EU and UK is stored in the US. Ask which features your teams enable before a policy review, and list any preview feature in use. Profile data also depends on where your users sign in from, so include user location in the inventory.
Backups, mirrors and recovery copies
Residency applies to copies as well as to the primary data. Geo-redundant mirrors and offsite backups in Azure DevOps stay within the selected geography under the stated exceptions. For a self-hosted platform, list every replica, backup target and disaster recovery site, and confirm each sits in the approved region. Backup tooling and object storage are often forgotten in this review.
Administrators and support access
Residency also concerns who can read the data. Identify which administrators, vendor staff and support engineers can reach repositories, logs and backups, from which countries and under which approval process. With a self-hosted forge, your own team controls administrator access and logging, and any external support contract should state its access rules in writing.
Which options keep data in the EU and what each one gives up
This table compares Azure DevOps Services, Azure DevOps Server, self-hosted GitLab, Gitea and Forgejo on where data sits, where tokens and SSH keys sit, where CI jobs run, how each is licensed and what features each gives up. Read the residency rows as the starting point for your own data flow review, and confirm the open items with each vendor before you decide.
| Criterion | Azure DevOps Services | Azure DevOps Server and self-hosted open source |
|---|---|---|
| Repository and work item data | Kept in the selected geography, with limited exceptions, per Microsoft's data locations documentation | Stored in the EU data center you choose for the server or VM, under your own backup and replication rules |
| Personal access tokens and SSH keys | Stored in a US datacenter, so this sits outside the EU geography | Stored wherever you host the instance, with the location set by your infrastructure |
| macOS build agents | Microsoft-provided macOS agents transfer data to a GitHub datacenter in the United States | Self-hosted runners stay on hardware you place in the EU, including Apple hardware you own |
| Profile data for users outside the US, EU and UK | Stored in the US under Microsoft's data locations documentation | Depends on your identity provider and user directory, so confirm where those records live |
| Preview services | Typically store data in the United States, per Microsoft's data locations documentation | Not applicable, since you choose which features to run on your own servers |
| Licensing and governance | Proprietary cloud service run by Microsoft | Azure DevOps Server is commercial. GitLab is open core, Gitea is MIT licensed and Forgejo is GPL-3.0-or-later from v9.0 |
| Boards and Test Plans | Included in the suite | No direct equivalent in GitLab, Gitea or Forgejo, so plan a separate tool or confirm fit with the vendor |
| Data location confirmation | Confirm current data handling with Microsoft before signing off | Confirm Azure DevOps Server data handling and any GitLab data location with the vendor in writing |
Where Azure DevOps Services sends data outside the selected geography
Customer data such as source code and work items stays in the geography you select, with limited exceptions. Microsoft's data locations documentation covers source code, work items, test results, geo-redundant mirrors and offsite backups within that geography. The exceptions sit outside that list, and they are the part a residency policy has to address. Four are documented: personal access tokens and SSH keys are stored in a US datacenter, profile data for users outside the US, EU and UK is stored in the US, macOS agent builds that use Microsoft-provided agents transfer data to a GitHub datacenter in the United States, and preview services typically store data in the United States. Read the Azure DevOps data locations documentation against your current tenant, because the list can change.
Map each exception to a decision you own. Token and SSH key storage matters most where your policy treats credentials as regulated personal or security data, so confirm with your privacy and security teams whether a US location for credentials is acceptable and how you will rotate or revoke them. Profile data of staff located outside the US, EU and UK needs a check against your employee data rules, since those users' identity details leave the EU by default. For pipelines, ask which agent pools run on Microsoft-hosted macOS images, because those build transfers cross to the US. Preview features should be disabled or excluded from regulated projects unless you have reviewed where their data lands.
Document these findings as a residency register that lists each exception, the data it touches, the accepted risk and the owner. A self-hosted GitLab, Gitea or Forgejo instance in an EU data center removes most of these flows because the server, its database and its tokens sit under your control, but it does not remove your own dependencies. Confirm any external services you still connect to, such as container registries, mirror sources or hosted runners, and verify them the same way before you describe the new setup as EU-only.
Choosing between GitLab, Gitea and Forgejo for an EU deployment
Teams that use Azure Repos, Pipelines, Boards and Artifacts together, and want one self-hosted product to cover most of that surface, will look first at GitLab. Its source is open core: code outside the ee/ directory is available under the MIT Expat license, while code under ee/ is licensed under the GitLab Enterprise Edition license. The GitLab pricing page lists Free at 0 US dollars, Premium at 29 US dollars per user per month billed annually, and Ultimate as custom priced, with all three tiers available for self-managed installations.
- The ee/ boundary: A feature you need may sit in ee/ and therefore behind a paid tier, even though most of the code is MIT. Check each required feature against the tier it belongs to before assuming it is free.
- Tier mapping: The pricing page lists advanced CI/CD and priority support for Premium, and application security testing, software supply chain security, vulnerability management and compliance features for Ultimate.
- Operating footprint: Reference architectures run from 1,000 to 50,000 users, and the docs generally recommend a high availability strategy at 3,000 or more users. Stateful components such as PostgreSQL and Redis are not supported inside Kubernetes, so they belong on VMs or managed services.
- Upgrade discipline: Required upgrade stops since GitLab 17.5 fall at x.2, x.5, x.8 and x.11, so upgrades must be planned around them.
- Offline operation: GitLab documents air-gapped operation, with separate guidance for security scanners and GitLab Duo Self-Hosted.
Confirm in writing which tier and ee/ features your EU deployment requires, and confirm the offline guidance applies to the version you plan to run.
Teams that mainly need Git hosting, code review, package registries and CI that resembles GitHub Actions will find Gitea the most direct fit. Gitea is MIT licensed, written in Go, and describes itself as an all-in-one development service. Gitea Actions is designed to be compatible with GitHub Actions, and Gitea supports more than 20 package registry types, including npm, PyPI, Maven, container images and Helm charts. It runs on MySQL, PostgreSQL, SQLite and MSSQL, and on Linux, macOS and Windows.
- Commercial support: CommitGo, Inc. provides leadership and commercial support and sells Gitea Enterprise, which adds SAML 2.0 service provider support, audit logging, organization-level branch protection inheritance, IP allowlisting, mandatory two-factor authentication and dependency scanning.
- Actions compatibility: The compatibility is a design goal. Run your actual workflows, including any third-party actions and secrets handling, on a test instance before committing.
- Import limits: Gitea's migration code includes importers for GitHub, GitLab, Gitea, Gogs, OneDev, GitBucket, Codebase and AWS CodeCommit. Azure Repos is not on that list, so Git history moves by clone or mirror, and pull requests and reviews need a separate export and rebuild.
- Managed option: Gitea Cloud exists alongside self-hosted installs. For an EU data residency requirement, the self-hosted option is the one this page assumes, so check any managed service separately.
- Database standards: Choose the database your DBA and backup standards already support, and confirm it against the release you deploy.
Ask CommitGo or your implementation partner which Enterprise features your audit and identity requirements need, and test your CI workflows on the version you intend to run.
Organizations that want a community-governed forge with a copyleft license will look at Forgejo, a community fork of Gitea. Forgejo is licensed GPL-3.0-or-later from v9.0 onward, with earlier versions under MIT. Codeberg e.V., a non-profit association registered in Berlin, owns the project's domains, while project governance stays independent. Forgejo's FAQ also describes federation as experimental, built on the ForgeFed protocol based on ActivityPub.
- License obligations: GPL-3.0-or-later carries copyleft obligations when you distribute modified versions. Ask counsel how those obligations apply to internal use and to any patches your team carries.
- Actions are not GitHub Actions compatible: Forgejo Actions is built in, uses separate runners and is familiar to GitHub Actions users, but it is not compatible with GitHub Actions. Workflows must be ported and tested.
- Support windows: Stable releases receive full support for three months plus a two-week window. LTS releases, published in the first quarter of each year, receive critical bugfixes and security support for one year and three months. v15 is the LTS release supported until July 15, 2027.
- Gitea upgrade path: Forgejo documents transparent upgrades from Gitea up to v1.22, in two steps: first to Forgejo v10.0.x, then to later Forgejo versions.
- Governance tradeoff: No vendor sells a commercial edition of Forgejo in the supplied facts, so patching capacity and incident response sit with your team or with a provider you contract separately.
Confirm which release line you will deploy, its end-of-support date, and who will apply security updates within that window.
How to deploy a self-hosted forge in an EU data center
This sequence takes a residency requirement from policy scope to a running, backed-up forge in an EU data center, with repositories imported and an upgrade cadence the team can keep.
Confirm the residency scope with the policy owner
Agree in writing with the policy owner which data must stay in the EU: source code, issues and reviews, package feeds, CI logs, and the identity and token data that Azure DevOps Services holds in a US datacenter. Record which EU data center, cloud region or on-premises site will host each component, and whether support staff outside the EU may access production. Done when the scope document lists every data class with its location and an owner who signed it.
Choose the install method and architecture
Use the GitLab Linux package for a single-node or small multi-node GitLab installation, or a reference architecture when the expected user count is larger, since GitLab's reference architectures run from 1,000 to 50,000 users. For smaller footprints, Gitea or Forgejo can run on a single server with a supported database. Confirm with the vendor whether your user count and API load fit the chosen layout. Done when the architecture decision record names the install method, database, and the reasons for it.
Place stateful services inside the EU boundary
Deploy databases, Git storage, object storage for artifacts and backups, and cache services in the EU location confirmed in step one. For GitLab at larger scale, the reference architectures note that PostgreSQL and Redis inside Kubernetes are not supported, so run stateful components on virtual machines or managed services in the EU and keep only stateless components on Kubernetes if you use that model. Verify the placement with a network and storage inventory. Done when every stateful service has an EU address range and a documented location.
Configure identity, access and runners
Connect the forge to your identity provider using the authentication options in the GitLab documentation or the equivalent for Gitea and Forgejo, and enforce two-factor authentication for administrators. Register CI runners in the EU network so build logs and secrets stay inside the boundary. Document which runner tags each project uses. Done when a test user signs in through the identity provider, a sample pipeline runs on an EU runner, and the access review is recorded.
Plan backup and restore before any import
Set backup targets and retention in the EU, then run a full backup and a restore into a separate test instance. For GitLab, follow the backup and restore documentation and include repository data, database and object storage. For Forgejo and Gitea, confirm the backup procedure for your database and data directory. Keep the restore test as evidence for the policy owner. Done when a restored test instance serves the same repositories and issues as the source.
Mirror and import repositories and project data
Mirror Git history with a clone or mirror push, which works between any two forges. Use the platform importer to move issues, pull requests, reviews and wikis: GitLab can import from Bitbucket Server, Gitea and other GitLab instances and from Git URLs, and Forgejo's dump-repo and restore-repo commands handle repository exports and restores. Azure Repos pull requests generally need a scripted export through the Azure DevOps REST API, which is subject to throughput limits. Done when a sample of repositories matches the source commit counts and the migrated pull requests and issues are checked by their owners.
Set the upgrade cadence and cut over
Set a monthly review of GitLab minor releases, which ship on the third Thursday of each month, and apply patch releases based on your security policy. Plan GitLab upgrades through the required upgrade stops, which since GitLab 17.5 fall at versions x.2, x.5, x.8 and x.11. For Forgejo, track the support window of each stable and LTS release, and for Gitea upgrades, follow the Forgejo transparent upgrade path where applicable. Cut over only after the restore test and the import check pass. Done when the upgrade calendar is approved and the cut-over checklist is signed by the service owner.
Moving repositories and issues without sending data through the US
Git history is the easy part of this move. A clone or mirror of each repository carries commits, branches and tags to any forge, but issues, pull requests, reviews, labels, milestones and wikis need a platform importer or dump tool. Gitea's migration code includes importers for GitHub, GitLab, Gitea, Gogs, OneDev, GitBucket, Codebase and AWS CodeCommit, but none for Azure DevOps, so pull requests and work items from Azure Repos must be exported to an intermediate form or re-created. Confirm this with the Gitea version you plan to run before you commit to a path. GitLab can import projects from GitHub, Bitbucket, Gitea and other GitLab instances, and Git repositories by URL, while Forgejo's dump-repo and restore-repo commands move repositories with issues, pull requests, releases, labels, milestones, comments and wiki between Forgejo, Gitea, GitLab and GitHub.
Bulk export from Azure DevOps is limited by API throttling. Azure DevOps delays users who exceed 200 throughput units in a five-minute window, so large organizations should plan extraction in batches and schedule it outside peak hours. Ask your migration partner to measure a sample project end to end before setting a window for the full cut-over.
The EU boundary applies to the export as well as the destination. The workstation, jump host or pipeline that calls the Azure DevOps REST API and writes the export files must run inside your EU environment, and the exported archives must be written to EU storage. Check that no step uses a hosted runner or a US-hosted helper, since Microsoft-provided macOS agents transfer data to a GitHub datacenter in the United States. Record which personal access tokens were used for the export and revoke them afterward, because those tokens are stored in the US.
Evidence a regulator or auditor will ask for
A residency review tests where data sits, who can reach it and how it is recovered. The cards below list the records that answer those questions, so the evidence is gathered once and kept current rather than rebuilt for each assessment. DeployOpen prepares this evidence, but independent auditors and certification bodies issue any assessment or attestation.
Data location register
A register lists each data class (source code, issues, pull requests, CI logs, package artifacts, backups) with the country, data center and cloud region where it lives. For Azure DevOps Services, compare the register against Microsoft's data location rules, which keep most customer data in the chosen geography but place token data such as personal access tokens and SSH keys in a US datacenter. Confirm the same mapping for any self-hosted GitLab, Gitea or Forgejo instance, including copies made by mirrors and monitoring tools.
Sub-processor and vendor data flows
Map every external service that receives code, identity or telemetry data, including hosted macOS build agents that send data to a GitHub datacenter in the United States. Record the purpose, the data sent, the processing region and the contract terms for each flow. Self-hosting removes most of these flows, but mail relays, SaaS runners, container registries and license checks still need entries.
Storage region and access configuration
Auditors ask which storage regions are configured and who can change them. Keep exported configuration for the Git storage path, database and object storage backends, and the reverse proxy in version control. Record which administrators can alter storage locations, and confirm that the platform's configuration files show no external storage endpoints.
Access control and token lifecycle records
Keep records of who holds administrator roles, how single sign-on is enforced, and how personal access tokens, deploy keys and SSH keys are issued, rotated and revoked. Export token inventories on a schedule and document the expiry rule. For regulated work, confirm which authentication settings the chosen platform can enforce and which need a separate control.
Backup location and restore tests
A residency review checks where backups are stored, how they are encrypted and whether they leave the approved region. Keep the backup schedule, storage location and retention setting, then keep dated restore test records that show a repository, its issues and its CI configuration came back intact. A backup that was never restored is weak evidence, so record the restore result and any gaps.
Upgrade, patch and runner placement records
Keep a log of platform versions, patch dates and the security fixes applied, along with the support window for each release line. Record where CI runners execute, since a runner outside the EU can move source code out of the region even when the server stays inside it. Confirm the support policy of the chosen platform before writing the upgrade calendar into the evidence file.
Questions buyers ask before moving an EU Azure DevOps estate
What drives the cost of moving Azure DevOps to a self-hosted forge?
The cost depends on which parts of Azure DevOps you replace and how you run the replacement. The main components are the software (GitLab Free and Premium are priced per user, while Gitea and Forgejo are open source), the servers and storage in your EU data center, the upgrade and backup work, support, and the staff time to operate it. Recurring costs include infrastructure, support subscriptions and upkeep. One-time costs include the migration, pipeline conversion and access design. Ask any quote to separate these components and to state which Azure DevOps modules are in scope.
How long does an EU Azure DevOps migration usually take?
The duration depends mainly on the number of repositories, the volume of pull request and work item history you need to keep, and how many pipelines must be rewritten. Azure DevOps rate limits also matter for bulk exports: Azure DevOps delays users above 200 throughput units in a five-minute window, so large extractions run in batches. Git history can be mirrored quickly, but issues, pull requests and reviews need a platform importer. Agree a timeline in writing against a defined scope and a repository inventory, rather than relying on a generic estimate.
What does the work need from our own engineering team?
Your team needs to supply access, decisions and knowledge that only your organization holds. Typical inputs are a repository and pipeline inventory, a list of users and groups mapped to your identity provider, branch policy and approval rules, and sign-off on data residency and retention. Engineers also need time to review converted pipelines and test builds, and security staff must approve hardening and backup targets. Name a technical owner and a business approver before work starts so the scope stays fixed.
Can our own team run the migration and operate the forge without a partner?
Yes, many teams do, provided they have Git, CI/CD and Linux operations skills. A small Gitea or Forgejo instance is simpler to run than a GitLab installation that must follow the required upgrade stops, which fall at x.2, x.5, x.8 and x.11 since GitLab 17.5. GitLab also recommends a high availability design for 3,000 or more users, using components such as Gitaly Cluster and PostgreSQL with Patroni. Assess your team's capacity for upgrades, backups and on-call work before deciding. An implementation partner can cover some of this work under a fixed scope, with ongoing support available as a retainer.
Does the choice of support model change the total cost?
Yes. Open-source software has no license fee, but support is a separate decision. Gitea has commercial support from CommitGo, Inc., which sells Gitea Enterprise with features such as SAML 2.0 service provider support, audit logging and IP allowlisting. GitLab sells Premium and Ultimate subscriptions, with priority support in Premium, and both tiers are available for self-managed installations. Forgejo is community-governed under GPL-3.0-or-later. Compare the subscription price with the staff time saved, and ask the support provider which EU hosting and patch windows apply.
Do Azure Boards and Test Plans need separate tools after the move?
Usually yes. Git hosting, pull requests and CI/CD move to GitLab, Gitea or Forgejo, but Azure Boards work items and Test Plans have no direct equivalent in these forges. GitLab covers issues, epics and some planning features, so it is the closest single-platform option. Gitea and Forgejo cover issues and milestones, but not the full work item model. Teams often pair the forge with a dedicated work management tool or export Boards data first. Confirm the feature set of each candidate against your real Boards and Test Plans usage before you choose.
How do data residency and token storage affect the move?
Azure DevOps Services keeps customer data, including source code and work items, in the selected geography, but it stores personal access tokens and SSH keys in a US datacenter, and macOS builds on Microsoft-provided agents transfer data to a GitHub datacenter in the United States. Hosting GitLab, Gitea or Forgejo in an EU data center removes these transfers from your scope. Azure DevOps Server keeps everything on your own infrastructure. Confirm with your compliance team which data categories must stay in the EU, and document where credentials and build agents run.
What does the engagement cover, and what does it not?
A fixed-scope engagement typically covers planning, installation in your own cloud account, data center or air-gapped network, integration with identity, migration of agreed repositories and pipelines, hardening, backup setup and documentation. DeployOpen prepares systems, controls and evidence for compliance assessments but does not issue audit reports or certifications. Ongoing upgrades, support and continuous testing are available as retainers. Scope, deliverables and timelines are agreed in writing before work starts, and a quote follows from that written scope.
How DeployOpen deploys a self-hosted forge under EU residency rules
DeployOpen plans, implements, hardens, backs up, documents and supports self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks. For EU residency, that means the forge, its database, backups and runners sit where the organization decides, with every component reviewed against the data locations it actually uses.
How we scope
- Map every Azure DevOps data class to a target location, including tokens, SSH keys, macOS build traffic and profile data.
- Agree which forge, tier and deployment model fit the residency rules before any installation begins.
- Confirm the written scope, deliverables and timelines in writing, since most engagements are fixed-scope.
How we build
- Install and configure the chosen forge in the client's EU environment, including its database, storage and runners.
- Migrate repositories by mirror, and move issues, pull requests and wikis with the platform's own importer or export tooling.
- Test authentication, backup restore and access controls, and document the results for the client's compliance assessment.
How we hand over
- Provide runbooks for administration, upgrades, backups and restores, written for the client's own operations staff.
- Document data flows and storage locations so the client can show residency controls to its assessors.
- Walk the client's team through the running system and confirm the handover checklist against the agreed scope.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover.
- Plan upgrade paths and vendor release cycles with the client, so the forge stays on a supported version.
- Prepare control evidence for compliance assessments, while independent auditors and certification bodies issue the actual reports.
