Enterprise Cloud gains regional data residency, starting in the EU

GitHub has announced that Enterprise Cloud will support data residency, beginning with the European Union on October 29, 2024. The move addresses long-standing enterprise demand for control over where code and repository data are stored. With data residency enabled, organizations can keep their GitHub data within a preferred geographic region while retaining access to the broader platform.

Enterprise Cloud with data residency offers unique namespaces on ghe.com, isolated from the open source cloud on github.com, and rests on the security, business continuity, and disaster recovery capabilities of Microsoft Azure. The project, which began with a proof of concept in summer 2022, was a multi-year company-wide effort—one that GitHub used its own tools to organize, build, and deploy.

Image of a Contoso repository displaying a unique namespace which is magnified.

Architecture: an extension of Enterprise Cloud, not a fork

After iterating on several approaches, the team chose to build data residency as a feature set extending Enterprise Cloud rather than as a separate product. That decision kept the two environments closely in sync on features and aligned with the performance, reliability, and security expectations of existing customers. Hosting on Azure meant GitHub could leverage the provider’s scale and regional footprint without constructing its own data centers.

A key design goal was minimizing differences for developers working across both environments. The architectures are nearly identical, which reduces complexity, risk, and development costs. Deployment is familiar: it builds on GitHub Actions, and changes to github.com and Enterprise Cloud with data residency ship minutes apart through a unified pipeline.

Achieving that required reworking build and deployment systems, coordinating work across more than 100 teams, and validating platform quality—all done using GitHub itself.

Coordinating 2,000+ issues across 100 teams

The team used GitHub Issues and Projects to manage the initiative, relying on multiple project views to help stakeholders across different teams focus on what mattered to them. Technical program managers used filtering and slicing capabilities in Projects to present milestone-specific updates in digestible formats.

Early access to upcoming features—issues hierarchy and issue types—helped clarify relationships between issues and classify work across repositories. Using these unreleased features internally gave GitHub feedback that shaped the final product before public release.

Image of hierarchies directly inside a GitHub project.

Image of issue types.

These tracking capabilities surfaced risk areas early and enabled teams to resolve blockers and dependencies, keeping the multi-year project on schedule.

Build and deployment: extending the existing flow

Development continued in GitHub Codespaces, with GitHub Actions handling continuous integration. The notable addition was new deployment targets for the data residency regions. That meant developers saw no change to their daily workflow; only the deployment pipeline expanded.

GitHub’s "deploy then merge" model was extended so that changes had to deploy successfully to data residency targets before a pull request could merge. The existing merge queue remained the gatekeeper. The pipeline operates in stages:

  • Deploy to internal environments (used by GitHub employees) in parallel.
  • Run automated and manual testing.
  • Roll out to "Canary," where load balancers gradually shift a percentage of github.com traffic to the new code.
  • After successful staging, deploy and validate Enterprise Cloud with data residency in the EU.
  • Only then is the pull request merged.

Image showing a visualization of the deployment pipeline.

If any deployment target fails, the change is rolled back and the process restarts at the merge queue. Feature flags supplement deployments, enabling gradual rollouts to customer groups for additional risk reduction.

To keep over 100 services consistent across all new targets, GitHub automated the generation of deployment pipelines so each service deploys to a new environment in a uniform order.

Dogfooding the data-resident environment

To validate the product, GitHub stood up an isolated data-resident environment and moved the daily development work of the GitHub Enterprise Importer team into it, using GitHub’s own migration tooling. Build, deploy, and development environments were updated to support working from within the data resident environment.

Since creation, that environment has seen over 8,000 deployments. It has provided early feedback on issues, pull requests, and Actions workflows, and helped iterate on status page tooling and internal Service Level Objective processes. The team continues to work there today, running over 1,000 Actions jobs per month—evidence of the platform’s stability.

What’s next

With data residency live in the EU on October 29, 2024, GitHub expects to expand to more regions over time. The company will discuss the feature further at GitHub Universe 2024.