Data Residency, EMU, and Organization Design for GitHub Enterprise (2026)

Why I wrote this article

This article began with a fresh look at how organizations use GitHub Copilot.

When Copilot is used with GitHub Enterprise Cloud and Enterprise Managed Users (EMU), it becomes more than a generative AI tool. It can support secure, well-governed work across an organization. Companies can use AI through accounts they manage while controlling access, policies, and where data is stored. To me, that puts it a step ahead of other generative AI tools.

Yet when I looked for recommended ways to set up GitHub Enterprise Cloud, I found surprisingly little information that brought the key decisions together. In particular:

• Which country or region should store your code and data? (Data Residency)
• Should the company manage user accounts, or should employees use personal accounts? (Enterprise Managed Users)
• How should repositories be grouped into Organizations? (Governance design)
• To what extent can the code and prompts sent to Copilot remain within your chosen region?

This article gives a high-level overview of these questions, based on GitHub’s official documentation and centered on GitHub Enterprise Cloud. Think of it as a foundation for using Copilot in a well-governed environment.

💡 The previous article, “GitHub Products, Features, and Licensing: An Overview for 2026,” covers GitHub plans, pricing, and purchasing, including Free, Team, Enterprise, Copilot, and Advanced Security billing. This follow-up goes a step further and looks at recommended ways to set up and operate the Enterprise plan you choose.

Table of contents

• Start with the big picture: the different forms of GitHub Enterprise
• 1. What is Data Residency?
• 2. What are Enterprise Managed Users (EMU)?
• 3. Organization design: GitHub’s recommendations
• 4. Additional consideration: keeping Copilot within a region
• 5. Additional references for tightly restricted networks
• 6. How to choose
• Summary
• Official sources

Start with the big picture: the different forms of GitHub Enterprise

“GitHub Enterprise” can refer to several different offerings. Keeping this map in mind makes the rest of the discussion easier to follow.

• GitHub Enterprise Server: A self-hosted offering that runs in your own environment, whether on-premises or on a cloud VM
• GitHub Enterprise Cloud: A managed offering hosted by GitHub, with two main options
  • Enterprise on GitHub.com: Uses the standard github.com domain. Data is stored in the United States by default
  • Data Residency (GHE.com): Uses a dedicated SUBDOMAIN.ghe.com subdomain and lets you choose the storage region

Within GitHub Enterprise Cloud, Enterprise Managed Users (EMU) is an additional consideration for authentication and account management.

The key point is that these three decisions are not completely independent. Most notably, as discussed below, Data Residency requires EMU.

1. What is Data Residency?

By default, GitHub stores GitHub.com data in the United States. With GitHub Enterprise Cloud with data residency, a company can choose the region where its code and data are stored. The enterprise is hosted on a dedicated GHE.com subdomain.

Supported regions

According to the current official documentation, the available regions are:

• US
• EU (including Azure regions in EFTA countries, currently Norway and Switzerland)
• Australia
• Japan

📌 Note: Some readers may still think that a Japan region is not available. The current official documentation lists Japan as a supported region. However, in-region Copilot processing, discussed later, is not yet available in Japan. These are separate capabilities and should be evaluated separately. GitHub says it plans to add more regions in the future.

What changes when you use it?

Without Data Residency, meaning a standard enterprise on GitHub.com, code and data are generally stored in the United States. With Data Residency, GitHub clearly defines which data is stored within your selected region.

What stays in the region, and what may leave it?

Data Residency does not mean that 100% of all data remains within the region. This distinction is important to understand accurately.

Stored within the region (explicitly stated by GitHub)

• User-generated content, including repositories (repository names and source code), pull requests, comments, and file paths
• GitHub Actions data and logs, as well as BCDR (business continuity and disaster recovery) data
• Personally identifiable data such as email addresses, usernames, names, and IP addresses

May be stored outside the region (explicitly stated by GitHub)

• Telemetry and logs containing identifiers that do not identify a person on their own, such as integer database IDs
• Information needed to manage paid plans, including contracts, billing, payments, and licenses
• Support and feedback data
• GitHub Copilot data (outside the region by default), which can be kept in-region through the policy described later
• Data used for purposes such as Secret scanning validity checks, when the feature is enabled

In short, Data Residency places code and user data in the selected region, while some telemetry, billing, and administrative data may still be handled outside it. Always compare this boundary carefully with your compliance requirements.

Be aware of URL and ecosystem differences

Because GHE.com uses a different URL structure from GitHub.com, existing automation and integrations may not work without changes. For example:

• API requests must be sent to api.SUBDOMAIN.ghe.com
• The container registry is containers.SUBDOMAIN.ghe.com, not ghcr.io
• The issuer for Actions OIDC tokens is token.actions.SUBDOMAIN.ghe.com
• Some features are currently unavailable, including installation through GitHub Marketplace and macOS runners

Before migrating, inventory any automation that depends on GitHub.com URLs and any workflows that assume Marketplace availability.

2. What are Enterprise Managed Users (EMU)?

Enterprise Managed Users (EMU) lets a company centrally manage the account lifecycle and authentication of its users through its IdP (identity provider).

• The IdP provisions user accounts on GitHub
• Users authenticate through the company’s IdP to access the enterprise
• The IdP controls usernames, profiles, Organization membership, and repository access
• Provisioning uses SCIM, while authentication uses SAML or OIDC

How EMU differs from personal accounts

Before creating a GitHub Enterprise Cloud enterprise, you choose whether it will use personal accounts or EMU. The main differences are:

Understand EMU’s strict constraints

EMU intentionally imposes strong restrictions to reduce the risk of information leakage.

• Managed users cannot create public repositories, Gists of any visibility, or externally published GitHub Pages sites
• Managed users can contribute only to repositories within the enterprise
• Anyone who also needs to contribute to external repositories must use a separate personal account, adding account-switching overhead and increasing the risk of using the wrong account

For this reason, GitHub explicitly states that EMU is not necessarily the best choice for every customer. Organizations where contributing to open source or collaborating externally is part of everyday work may be better served by the personal account model.

Partner IdPs and the risks of mixing systems

EMU offers a paved-path integration with partner IdPs such as Entra ID, Okta, and PingFederate. GitHub’s recommendation is clear:

Use a single partner IdP for both authentication and provisioning.

Although it is possible to mix systems, such configurations can fall outside GitHub’s supported paths and require careful evaluation. In particular, mixing Okta and Entra ID across SSO and SCIM is explicitly unsupported and causes provisioning errors.

The relationship with Data Residency (important)

This relationship is easy to misunderstand:

• Using Data Residency (GHE.com) means EMU is required
• Using EMU does not necessarily mean using Data Residency; EMU is also available on GitHub.com

In other words, EMU is a prerequisite for Data Residency, but the reverse is not true.

3. Organization design: GitHub’s recommendations

How you group repositories into Organizations within an enterprise is an architectural decision that can be difficult to change later. GitHub’s official documentation offers several principles.

Principle 1: Group Organizations by work or governance

There are two main models for structuring Organizations:

• Group related work: Keep the repositories for an application and its related services together so the teams responsible can communicate and contribute across the projects
• Group common governance requirements: Keep repositories with similar policy, security, and access requirements together so those controls can be applied at the Organization level. For example, isolate highly confidential projects in an Organization accessible only to a limited group

Principle 2: Create Organizations intentionally, and start with a few

In GitHub’s words, “Organizations are harder to delete than they are to create.” Creating too many without a clear purpose has drawbacks:

• @mentions work only within the same Organization, so excessive separation makes collaboration harder
• Search becomes less convenient across Organization boundaries

GitHub recommends starting with a small number and adding more as operational needs emerge. Enterprise account management supports policy enforcement, access management, and automation across multiple Organizations. You therefore do not need to force everything into one enormous Organization or split everything into fine-grained Organizations from the outset. GitHub also recommends periodically reviewing legacy Organizations.

Principle 3: Manage people through Teams, preferably synchronized with the IdP

Teams are the best way to scale access and permissions.

• Whenever possible, use Teams to add users to Organizations, assign licenses, and delegate permissions
• Because Team membership has a broad impact, limit membership management to a small number of people
• When using an IdP, synchronize Teams with IdP groups so central administrators retain control
• Use roles to delegate administrative work and keep the number of Enterprise Owners low. For example, give auditors access only to audit logs

Principle 4: Collaborate in Organization-owned repositories

GitHub recommends collaborating in Organization-owned repositories rather than repositories owned by individuals. Organization-owned repositories provide more advanced security and management features, and access remains intact as team membership changes. An innersource model, which applies open source-style reuse inside the company, can also reduce duplicated work across teams.

4. Additional consideration: keeping Copilot within a region

This was the area I most wanted to clarify. For organizations that want to use AI without sending code or prompts outside their region, GitHub offers GitHub Copilot with data residency.

What does it provide?

For GitHub Enterprise Cloud with data residency, enabling the “Restrict Copilot to data residency compliant models” policy keeps Copilot’s inference processing and related data within the specified region.

• User authentication tokens can access only the region-specific endpoint, preventing traffic from leaving the region
• Copilot offers only models approved for that region; out-of-region models cannot be selected
• Logs and telemetry are stored in compliant storage within the region

As noted earlier, Copilot data is stored outside the region by default. Only after this policy is enabled do inference, prompts, responses, logs, and telemetry remain in-region.

Only the US and EU currently support in-region Copilot processing

This distinction matters: in-region Copilot processing currently supports only two regions, the US and EU.

• US
• European Union (EU)

GHE.com Data Residency itself supports the US, EU, Australia, and Japan. However, in-region Copilot inference is not yet available in Japan or Australia. GitHub says it plans to expand availability in the near future.

Other points to keep in mind

• Available models vary by region. The US and EU offer different model lineups, and availability changes over time. New models may arrive later while regional infrastructure is prepared and certifications are completed. Check the model selector and official documentation for the latest availability
• AI credit consumption increases by 10% to account for the additional infrastructure required by regional, compliance-certified endpoints. For example, a request that normally consumes 100 credits consumes 110 credits
• Clients must be versions released in 2025 or later. Older extensions and CLI versions do not enforce the policy and prompt users to upgrade
• Copilot Individual is not available. Managed users must receive Copilot through Copilot Business or Copilot Enterprise

If you need an LLM hosted in Japan: BYOK and custom models

In-region Copilot processing is not yet available in Japan. However, organizations that need the inference model itself to run in Japan have another option: BYOK (Bring Your Own Key). For example, you can connect Copilot to an LLM deployed in a Japan region through Microsoft Foundry. Supported providers include Anthropic, AWS Bedrock, Google AI Studio, Microsoft Foundry, OpenAI, and xAI. Fine-tuned models are also supported. This feature is in public preview.

There is an important distinction, however: BYOK has two different data flows. GitHub uses the same broad name for two mechanisms with different characteristics.

• With Local BYOK, the key is stored only on the client. Prompts and code are sent directly from the client to your model endpoint, such as Foundry in a Japan region. The official documentation describes this as removing the dependency on GitHub’s Copilot API, so traffic does not pass through GitHub’s proxy. Local BYOK is available in VS Code, JetBrains IDEs, Xcode, Copilot CLI, the Copilot app, and the Copilot SDK. Business and Enterprise administrators can also disable it by policy
• Enterprise BYOK (Custom models) is handled server-side and operates as a model delivered through the Copilot API. An administrator registers the key in the Enterprise or Organization settings, and the model appears in the model selector. Even if the model is hosted in Japan, the request first passes through GitHub’s Copilot API proxy

⚠️ This is not an official Data Residency capability. BYOK lets you choose the model used for inference; it does not constrain all Copilot data, including telemetry, to a particular region. Evaluate the model’s location and the location of Copilot data as separate concerns. Because Enterprise BYOK uses GitHub’s Copilot API, whether that proxy is in the request path may be significant for your compliance requirements.

5. Additional references for tightly restricted networks

Organizations that tightly restrict external connections through firewalls or DNS filtering must add the domains and IP addresses used by GitHub services to an allowlist. The exact entries vary by environment and version, so this article does not reproduce them. GitHub provides official references instead.

Copilot is not the only service that may require an allowlist. GitHub provides references for the platform and individual products, with the Meta API as the primary source.

GitHub-wide references

• Meta API (api.github.com/meta): The primary source. It returns machine-readable IP ranges by service, including actions, packages, pages, hooks, web, api, git, copilot, and dependabot. Product-specific allowlist pages derive their data from this API
• Allowing access to GitHub’s services from a restricted network: General guidance on allowing domains in environments restricted by DNS or firewalls
• About GitHub’s IP addresses: Guidance on IP ranges, including allowing TCP ports 22, 80, and 443 to github.com or SUBDOMAIN.ghe.com

Product- and environment-specific references

• GitHub Copilot: Copilot allowlist reference
• GitHub Actions: GitHub-hosted runner IP ranges are available from the Meta API under the actions key. Self-hosted runners have separate connectivity requirements
• GitHub Codespaces: GitHub provides network and connectivity guidance
• Data Residency (GHE.com): Network details for GHE.com. Its IP ranges and SSH fingerprints differ from those for github.com
• GitHub Enterprise Server (GHES): Uses a separate network architecture because it is self-hosted

How the references relate

Meta API (api.github.com/meta) <- source of all IP range data
   |- Copilot allowlist reference <- Copilot-specific presentation
   |- Actions runner IP ranges
   |- Domain allowlists for restricted networks
   `- GHE.com uses separate ranges (Network details for GHE.com)

⚠️ These pages state that the lists are not exhaustive, discourage relying on hard-coded IP addresses, and recommend regular monitoring. When possible, build an operating process that retrieves and applies updates from the Meta API instead of maintaining static IP entries.

6. How to choose

With so many considerations, it helps to work backward from your requirements.

Adopting Data Residency means EMU is required, and EMU restricts public repositories and external collaboration. Evaluate the benefits of keeping data in-region together with the resulting constraints on the developer experience.

Summary

GitHub Enterprise design becomes easier to reason about when divided into three layers:

1. Where data is stored (Data Residency): The default is the United States. GHE.com lets you choose the US, EU, Australia, or Japan, although some telemetry, billing, and other information may still be handled outside the selected region
2. Who manages identities (EMU): Choose between company-provisioned accounts through an IdP and the personal account model. Data Residency requires EMU, and EMU places strict limits on public and external collaboration
3. How work is grouped (Organizations): Group by work or governance, start intentionally with a small number, and manage people through Teams synchronized with the IdP

AI adds another layer: in-region Copilot processing, currently available only in the US and EU. Its regional coverage differs from GHE.com Data Residency. You can store data in Japan, but at present that does not mean Copilot inference can also remain entirely within Japan.

The most reliable approach is to list your compliance, developer experience, and AI requirements, then design the three layers together with the separate Copilot layer.

Official sources

• About GitHub Enterprise Cloud with data residency
• About storage of your data with data residency
• Feature overview for GitHub Enterprise Cloud with data residency
• About Enterprise Managed Users
• Choosing an enterprise type for GitHub Enterprise Cloud
• Best practices for organizing work in your enterprise
• GitHub Copilot with data residency
• Bring your own key for GitHub Copilot
• Enabling custom models for GitHub Copilot in your enterprise
• Copilot allowlist reference
• Allowing access to GitHub’s services from a restricted network
• REST API endpoints for meta data (Meta API)
• About GitHub’s IP addresses