GitHub Enterprise Cloud vs. Server: User Management, Copilot, and Related Features

Why I decided to write this article

The introduction of Data Residency for GitHub Enterprise Cloud has made it easier for organizations to choose where their code and user data are stored.

Even so, requirements such as “source code must not leave our managed environment” and “the entire network must remain on-premises” are still common. In those cases, the self-hosted GitHub Enterprise Server (GHES) is one option.

As a Cloud Solution Architect (CSA) who primarily works with cloud environments, I honestly was not very familiar with how GHES handles users or where the management boundaries fall when it is used with GitHub Copilot.

In this article, I use GitHub’s official documentation to explore the following questions:

• How are users registered and managed on GHES? Can it use Enterprise Managed Users (EMU)?
• Are GitHub Copilot licenses and policies managed in GHES or in the cloud?
• Can Copilot policies differ by organization?
• Can developers use the GitHub Copilot cloud agent or Agent Mode in an IDE?
• What are the differences involving Actions, Codespaces, Dependabot, and Code Security?

⚠️ Scope of verification
I do not have access to a working GHES environment, so I have not verified the information in this article on an actual instance. This is a summary, written for my own understanding, of research that I asked GitHub Copilot to collect and organize from GitHub’s official documentation as of July 27, 2026 (latest referred to GHES 3.21). GHES feature availability varies by version, license agreement, and network architecture. Before a production deployment, always consult the official documentation for the version you plan to use and confirm the details with GitHub Sales or Support.

Table of Contents

• Key takeaways
• 1. Cloud and Server differ in what they can keep isolated
• 2. GHES user management and EMU
• 3. Management boundaries when GHES users use Copilot
• 4. Can Copilot policies differ by organization?
• 5. Some Copilot policies do not apply everywhere
• 6. Can the Copilot cloud agent be used with GHES?
• 7. Key constraints in other GitHub products
• 8. What to confirm before deployment
• Summary
• Official sources

Key takeaways

Here is a high-level summary of what I found.

The most important point is that choosing GHES does not bring Copilot on-premises.

GHES can keep development data such as code, issues, and pull requests in an environment managed by your organization. Copilot inference, licensing, and policies, however, are GitHub cloud services. The resulting architecture combines two management planes: repositories on GHES and AI in the cloud.

1. Cloud and Server differ in what they can keep isolated

GitHub Enterprise includes GitHub Enterprise Cloud (GHEC), operated by GitHub, and GitHub Enterprise Server (GHES), operated by the customer.

GitHub Enterprise Cloud

• GitHub operates the service
• You use either the standard github.com domain or SUBDOMAIN.ghe.com with Data Residency
• GitHub handles upgrades, availability, backups, and infrastructure capacity
• You can more readily use the latest AI capabilities integrated with GitHub.com, Codespaces, Marketplace, and GitHub-hosted runners

GitHub Enterprise Server

• You deploy the appliance on-premises or in an environment you manage on AWS, Azure, Google Cloud, VMware, or another supported platform
• Repositories, issues, pull requests, and user information are stored on your organization’s instance
• Your organization handles upgrades, backups, high availability, monitoring, certificates, DNS, capacity, and incident response
• Features ship with GHES releases, so they do not necessarily arrive at the same time as new GitHub.com features

GHES does not, however, always operate in complete isolation.

For example, enabling GitHub Connect links GHES to an enterprise account on GitHub Enterprise Cloud and can provide license synchronization, Dependabot, Actions on GitHub.com, and unified search. GitHub Connect itself does not transfer repositories, issues, or pull requests to the cloud. It does send connection information and license usage counts, however, and enabled features may also send user IDs and email addresses, Action names and YAML, search terms, and search results.

Two details are particularly important:

• GitHub Connect’s automatic license synchronization deduplicates licenses for GitHub Enterprise plans and GitHub Advanced Security products. It does not replace Copilot license assignment
• When GHES is connected to an enterprise on GHE.com, Server Statistics and GitHub.com Actions are not currently available through GitHub Connect

In other words, choosing GHES does not automatically keep every communication and every type of data on-premises. For each feature, you need to identify what data is sent and in which direction.

2. GHES user management and EMU

Authentication methods available on GHES

GHES users have accounts created within the GHES instance. The available authentication methods are:

• Built-in authentication: GHES manages usernames and passwords
• CAS: users authenticate through an external CAS server
• LDAP: users authenticate through an external directory
• SAML SSO: users authenticate through an IdP such as Microsoft Entra ID or Okta

With built-in authentication, users create an account after receiving an invitation or through sign-up. With CAS, LDAP, or SAML, GHES can create an account just in time (JIT) when an authenticated user first accesses the instance.

SAML + SCIM enables IdP-driven provisioning and suspension

Current GHES releases can combine SAML SSO and SCIM to manage the following lifecycle operations from an IdP:

• Assigning a user or group to the IdP application creates a GHES account
• Changes to names and email addresses in the IdP are reflected in GHES
• Removing an assignment or disabling a user revokes GHES sessions and suspends the account
• Reassigning the user restores the account
• IdP groups can manage team and organization membership

The official documentation lists the following partner IdPs:

• Microsoft Entra ID
• Okta
• PingFederate (Public Preview)

GitHub recommends using the same partner IdP for authentication and provisioning. SCIM requires SAML or SAML with built-in authentication; it cannot be combined with CAS or LDAP.

Adding SCIM to an existing SAML environment also requires careful migration planning. After SCIM is enabled, existing SAML users cannot sign in until their identities have been provisioned through SCIM. GHES links existing accounts by matching the SCIM userName to the GHES username. Before migration, plan for phased assignments, username matching, and an emergency administrator account that uses built-in authentication.

EMU is not available on GHES

This is the easiest distinction to misunderstand.

Enterprise Managed Users (EMU) is an account model for GitHub Enterprise Cloud. It does not exist on GHES.

SAML + SCIM on GHES lets an IdP create and suspend accounts within the GHES instance. Although parts of the operational model may resemble EMU, they are different systems.

GHES SCIM can meet a requirement to provision users automatically from an IdP. If the requirement is to govern Copilot and other cloud features under the same managed identity model on GitHub Cloud, however, you must separately design either personal accounts or EMU on the cloud side.

3. Management boundaries when GHES users use Copilot

GitHub Copilot does not perform inference inside the GHES appliance. Users connect to GitHub’s Copilot service from an IDE extension or the CLI.

As a result, a developer who uses Copilot with a GHES repository typically has two identities:

1. A GHES account for signing in to GHES and accessing repositories
2. A cloud-side GitHub account that receives the Copilot license and authenticates to Copilot from the IDE

Even if the two accounts use the same corporate email address or IdP, GitHub manages them as separate accounts.

A dedicated enterprise for Copilot Business

For companies that do not already manage users in a cloud-side organization or enterprise, GitHub’s official documentation describes an option to create a dedicated enterprise solely for managing Copilot Business licenses. This is not mandatory for companies using GHES; it is one way to centralize Copilot management.

The dedicated enterprise can use either of these identity models:

• Invite personal GitHub accounts to the enterprise
• Choose EMU and use IdP + SCIM to provision managed accounts for Copilot

Users can be added directly to the enterprise without being placed in an organization, and Copilot Business licenses can be assigned to individual users or enterprise teams. This approach avoids assigning a GitHub Enterprise license to every user solely to provide Copilot.

Developer
  ├─ GHES account ── Access repositories, issues, and pull requests on company GHES
  └─ Cloud account ── Receive Copilot Business license and policies
                         └─ Connect to the Copilot service from an IDE or CLI

It is therefore easiest to think of Copilot licenses and policies as being managed through AI Controls in the cloud-side enterprise settings, not through the GHES enterprise settings.

The GitHub Enterprise plan includes both GitHub Enterprise Cloud and GitHub Enterprise Server. If your agreement already includes a cloud-side enterprise, whether to use it for Copilot management or create a separate Copilot-only enterprise depends on your contract and identity architecture. Confirming this with your GitHub sales representative is the safest approach.

The differences between Copilot Business and Copilot Enterprise also include features that assume repositories and pull requests are hosted on GitHub.com. If the authoritative copy of your code exists only on GHES, not every higher-tier feature may be available. Do not choose a plan by name alone; verify feature by feature whether the capabilities you need apply to GHES repositories.

4. Can Copilot policies differ by organization?

The short answer is yes, if you create organizations on the cloud side. An organization is not always necessary, however.

Without an organization

• Assign Copilot Business licenses directly to users or enterprise teams
• Apply enterprise policies consistently
• When an enterprise policy is set to “No policy,” use the default under Policies for enterprise-assigned users to enable or disable the feature
• Best suited to a configuration used only to distribute Copilot licenses

With an organization

• The enterprise owner can enforce a policy across the enterprise or delegate it to organization owners by selecting No policy
• Copilot Business or Copilot Enterprise enablement and policies can differ by organization
• Organization owners can manage license assignment for their members
• Adding a user to an organization consumes both a Copilot license and a GitHub Enterprise license

GitHub’s official setup guidance for a dedicated Copilot Business enterprise tells administrators not to create an organization during the initial setup. If you only need to manage Copilot licenses, assigning users and teams directly under the enterprise is the simplest place to start.

On the other hand, repository-based centralized configuration, such as distributing server-managed settings from a .github-private repository, requires an organization. The users who create and manage that organization need GitHub Enterprise licenses. Managed settings can also be deployed through MDM or file distribution.

Watch for policy conflicts across multiple organizations

If the same user receives a Copilot license from multiple organizations with different policies, most features apply the least restrictive policy.

Some policies instead apply the most restrictive setting. These include suggestions matching public code, semantic indexing for repositories outside GitHub, the Copilot Metrics API, and Copilot code review for members who do not have a license.

Placing a user in a tightly controlled organization does not necessarily make all of that user’s Copilot access equally restrictive. If strict governance is required, explicitly enforce the relevant policies at the enterprise level instead of broadly delegating them to organizations.

5. Some Copilot policies do not apply everywhere

Copilot is available in several contexts, including IDEs, the CLI, GitHub.com, the Copilot cloud agent, and Copilot code review. The same policy does not necessarily apply to every feature.

Representative examples include:

Content exclusion requires particular care.

Cloud-side enterprise and organization settings can specify any Git remote URL, including a GHES URL, to exclude particular files or paths from Copilot context. The exclusion applies to inline suggestions and supported Copilot Chat features, but it does not apply to Edit Mode or Agent Mode in Copilot Chat, Copilot CLI, or the Copilot cloud agent.

It is dangerous to assume that configuring an exclusion policy removes a file from every Copilot feature. During rollout, allow features individually and consult the policy support matrix for each capability you plan to enable.

6. Can the Copilot cloud agent be used with GHES?

It is important to distinguish between the following two capabilities.

Agent Mode in an IDE

Agent Mode can read local files, run commands, and modify code within an IDE. It can be used with a locally cloned GHES repository as long as the developer can authenticate to Copilot with a cloud-side account.

As noted above, content exclusion is not supported in Agent Mode. Client-side controls for network access, terminal execution, MCP, approval flows, and related capabilities must be designed separately.

Copilot cloud agent

The Copilot cloud agent accepts delegated work from GitHub issues or Chat, then creates a branch, makes changes, runs tests, and opens a pull request from a temporary development environment powered by GitHub Actions.

The official administration procedures assume the following GitHub.com resources:

• AI Controls in a cloud-side enterprise
• A cloud-side organization
• Repositories owned by that organization
• A GitHub Actions execution environment

GitHub’s official documentation states that the Copilot cloud agent works only with repositories hosted on GitHub. Its administration procedures assume an enterprise, organization, and repositories on GitHub.com, and the GHES 3.21 documentation does not contain a feature page for the Copilot cloud agent. This article therefore treats repositories that exist only on GHES as unsupported by the Copilot cloud agent.

For now, the following interpretation is the safest:

• Using Agent Mode in an IDE with a locally cloned GHES repository: supported
• Assigning the Copilot cloud agent directly to a repository that exists only on GHES: treat as unsupported
• Mirroring or migrating a repository to the cloud to use the Copilot cloud agent: technically an alternative, but one that conflicts with a requirement to keep code on-premises

If the Copilot cloud agent is a requirement, first decide where the authoritative repository will reside and what may be copied to the cloud. Then confirm the latest GHES support status with GitHub Sales or Support.

7. Key constraints in other GitHub products

GitHub Actions

GitHub Actions is available on GHES, but its operating model differs significantly from the cloud service.

• GitHub Actions is disabled by default on GHES and must be enabled by a site administrator
• GitHub-hosted runners are unavailable; self-hosted runners are required
• External object storage is required for workflow logs, caches, and artifacts
• Your organization must manage runner operating systems, patching, autoscaling, networking, and secret protection
• Actions from GitHub.com and Marketplace are unavailable by default
• You can use GitHub Connect to access public Actions automatically or use actions-sync to bring the required Actions into GHES

GHES bundles several widely used official Actions, but they are snapshots from the time of the release. In a fully isolated environment, you must mirror not only the Actions themselves but also tool caches fetched by setup-*, package manager sources, container registries, and other dependencies.

GitHub Codespaces

Codespaces is a cloud-hosted development environment operated by GitHub. The GHES 3.21 documentation does not contain a Codespaces feature page, and I could not find a documented configuration for creating Codespaces from GHES repositories.

If you need a similar experience with GHES, consider local development environments based on Dev Containers, an internal VDI, or another self-hosted development environment.

Dependabot

Dependabot alerts and updates are available on GHES, but they have additional configuration requirements.

• Alerts synchronize the GitHub Advisory Database through GitHub Connect
• Vulnerability data from the Advisory Database is synchronized to GHES; the code itself is not uploaded to GitHub
• Updates require GitHub Actions and a dedicated self-hosted runner
• The runner needs a network route to the package registry to retrieve updates
• Environments with limited or no internet connectivity can use a private registry configuration
• The official GHES 3.21 documentation states that Dependabot updates are not supported on GHES instances that use clustering

GitHub Code Security and Secret Protection

GHES supports the major Code Security and Secret Protection capabilities:

• Code scanning and the CodeQL CLI
• Dependency review
• Dependabot custom auto-triage rules
• Secret scanning
• Push protection
• Custom patterns
• Security overview

AI-assisted features and new administration interfaces that first appear on GitHub.com may not arrive on GHES at the same time. During evaluation, do not rely on the product name “GitHub Enterprise” alone. Confirm that the official documentation for the GHES version you plan to use includes a page for the specific feature.

The trade-off between GitHub Connect and complete isolation

When choosing GHES, do not reduce the decision to cloud versus on-premises. For each feature, decide whether you will allow complete isolation, limited outbound connectivity, or combined cloud use.

8. What to confirm before deployment

The following questions can help structure your requirements.

Data and network

• Must only the code remain in your environment, or are telemetry, license information, and AI prompts also prohibited from leaving it?
• Can you allow outbound HTTPS connections to GitHub.com?
• Can you allow connections to package registries, container registries, and LLM endpoints?
• May repositories be mirrored to the cloud?

Identity and licensing

• Will GHES use built-in authentication, LDAP, or SAML?
• Will SAML + SCIM manage users and groups from the IdP?
• Will cloud-side Copilot accounts be personal accounts or EMU?
• How will you map GHES users to Copilot users, such as by email address or employee ID?
• How will you manage the email addresses and verified domains used by GitHub Connect for license deduplication?
• Will you assign Copilot licenses to teams directly under the enterprise or delegate assignment to organizations?

Copilot

• Which capabilities will you allow: inline suggestions, Chat, Edit Mode, Agent Mode, CLI, and the Copilot cloud agent?
• Can you allow features to which content exclusion does not apply?
• At what level will you enforce model selection, public code matching, MCP, and web search?
• How will you design allowlists, proxies, and TLS inspection for Copilot traffic?
• Can your legal and security teams approve the data processing terms for prompts, responses, and telemetry?

Operations

• Who will operate GHES upgrades, backups, high availability, disaster recovery, capacity, and certificates?
• Who will patch, monitor, and retire self-hosted runners?
• How will you mirror Actions, tool caches, packages, and container images?
• Which identity will you use to correlate GHES audit logs with cloud-side Copilot audit logs and usage metrics?
• Will existing GitHub Apps, OAuth Apps, webhooks, and Marketplace integrations work with the GHES hostname and network architecture?
• How will you evaluate and roll out features that arrive on GHES later than on GitHub.com?

Summary

This research reminded me that the difference between GitHub Enterprise Cloud and GitHub Enterprise Server is about much more than where the code is stored.

GHES lets an organization keep repositories, issues, pull requests, and user accounts in an environment it manages. SAML + SCIM is not EMU, but it can still manage GHES account creation, suspension, and team membership from an IdP.

Copilot, on the other hand, is a cloud service. GHES users need a separate cloud-side account and license to use Copilot, and Copilot policies are managed through the cloud-side enterprise or organization.

Organizations can separate policies, but a dedicated Copilot enterprise also allows direct license assignment without an organization. For users who belong to multiple organizations, most policies apply the least restrictive setting. Policies that require strict governance are therefore better enforced at the enterprise level.

Agent Mode in an IDE and the Copilot cloud agent are also different capabilities. Agent Mode can work with a locally cloned GHES repository, while the Copilot cloud agent assumes a cloud-side organization, repository, and GitHub Actions environment. Copying code to the cloud to use the Copilot cloud agent conflicts with the original requirement to keep code on-premises.

When evaluating GHES, it may help to consider three questions:

1. Which data must never leave your environment?
2. Which features can use limited outbound connectivity?
3. Which development experiences are worth allowing combined cloud use?

Choosing GHES does not simply mean “not using the cloud.” It means explicitly deciding, feature by feature, which boundaries your organization will own and which it will entrust to cloud services.

Official sources

GitHub Enterprise Server and identity management

• GitHub’s plans
• Identity and access management fundamentals
• About user provisioning with SCIM on GitHub Enterprise Server
• Configuring SCIM provisioning to manage users
• About GitHub Connect
• Enabling automatic user license sync for your enterprise

GitHub Copilot

• About enterprise accounts for Copilot Business
• Setting up a dedicated enterprise for GitHub Copilot Business
• Setting up GitHub Copilot for your enterprise
• GitHub Copilot policies for enterprises and organizations
• Feature availability when GitHub Copilot policies conflict in organizations
• Supported surfaces for GitHub Copilot policies
• Content exclusion for GitHub Copilot
• About GitHub Copilot cloud agent

Actions and Security

• Getting started with GitHub Actions for GitHub Enterprise Server
• About using actions in your enterprise
• Manually syncing actions from GitHub.com
• Enabling Dependabot for your enterprise
• GitHub security features