One general release with features at different maturity levels
GitHub made GitHub Enterprise Server 3.22 generally available on September 8, 2026. The release expands centralized identity, repository governance, security analysis and appliance administration for organizations that run GitHub on infrastructure they control. It also introduces a path for Copilot CLI to work through a GHES instance without connectivity to GitHub Cloud. That AI integration is not generally available in the same sense as the server release. GitHub labels it a technical preview that can change.
The distinction matters because an enterprise can adopt version 3.22 without treating every included capability as equally mature. Enterprise Teams has advanced from public preview to general availability. Enterprise Live Migrations is also generally available. The Copilot CLI connection, by contrast, still carries preview risk. GitHub has documented how to configure it, but the designation does not establish production stability, long-term interface compatibility or independent security certification for the model provider that an administrator selects.
Disconnected Copilot still needs a reachable model
The Copilot CLI design moves the connection boundary but does not place a model inside GitHub Enterprise Server. An administrator uses the GHES administrative shell to configure a model-provider endpoint, its credential, a provider type and a model identifier. GitHub documents support for OpenAI, Azure and Anthropic interfaces, with the OpenAI option also covering compatible endpoints such as Ollama and vLLM. The configured endpoint must remain reachable from the GHES appliance whenever users request inference.
End users connect the CLI to the appliance with the GHES hostname and a personal access token, then enable its offline operating mode. In this context, offline means disconnected from GitHub Cloud. It does not mean that inference happens without a network connection or that GHES supplies model weights. A locally hosted compatible endpoint could keep inference inside an organization’s environment, while a remote commercial endpoint would create a different data path. Administrators must evaluate the endpoint they actually configure, including authentication, logging, retention and network routing.
The arrangement offers a practical benefit for restricted environments. A central GHES configuration can give users one enterprise-managed route to an approved model rather than requiring each workstation to select and configure a provider independently. GHES credentials establish access to the server, while the appliance holds the upstream provider configuration. That separation can simplify administration, but it does not prove that prompts, repository context or generated output remain within a particular jurisdiction. The provider choice and deployment topology determine that boundary.
GitHub also documents narrower capabilities for this configuration than for its cloud-connected service. GitHub-hosted model selection, web search, web fetching and GitHub MCP server tools are not available in the offline GHES arrangement. Repository operations can still be performed through an independently authenticated GitHub CLI. These limits reinforce the distinction between a supported technical preview and generally available functionality: the preview supplies AI-assisted coding and local tool use, but it is not a complete private replica of the GitHub Cloud Copilot environment.
Access policy moves above the organization boundary
Enterprise Teams is one of the more consequential generally available changes. Enterprise owners can create a centralized team structure that governs users and access across multiple organizations and repositories. That can reduce repeated membership management for companies whose organizational boundaries reflect business units rather than separate security domains. Centralization also concentrates authority, so enterprises need clear ownership for team membership and a way to audit changes that propagate across repositories.
Repository rulesets gain a required-reviewers rule that can target branches, files and folders through patterns. Administrators can require a minimum number of approvals from selected teams, such as security review for changes on the default branch or database review for SQL files. The rule operates alongside CODEOWNERS instead of replacing it. This supports review requirements that follow risk or compliance responsibility rather than relying only on the people recorded as code owners.
The release also permits individual users to bypass repository rulesets. GitHub presents this as a granular option for cases such as service accounts, where creating a dedicated role or team would add unnecessary administration. Granularity is not the same as safety. A direct exception can become a durable route around normal controls if it lacks a narrow purpose, expiration and audit review. The useful advance is that administrators can express the exception precisely. They still decide whether the exception is justified.
Faster maintenance and scanning remain vendor-reported outcomes
Version 3.22 separates pre-upgrade work into a phase that administrators can run before the maintenance window. GitHub says this can reduce work performed during the window by as much as 20 minutes. A new replication controller reconciles the desired replication state for Git, Pages, storage, MySQL, Elasticsearch, GitHooks and Redis. These changes address real operational bottlenecks, but the published release notes do not provide an independent comparison across appliance sizes or topologies.
CodeQL now performs incremental pull-request analysis for several major languages, extracting and evaluating changed code rather than repeating a complete scan. GitHub reports early improvements ranging from two to ten times. That is a first-party development result, not a guaranteed acceleration for every repository. Language mix, build behavior, changed-code volume and available resources can affect scan duration. Incremental analysis also changes the amount of work performed; it does not establish that every relevant cross-file flow will be detected in every project.
Other infrastructure changes broaden dependency and runner management. Dependabot can use organization-configured OpenID Connect for private registries and can address multiple registries within one ecosystem. Actions Runner Controller can assign multiple labels to one scale set, reducing the need to duplicate runner pools for overlapping attributes. These controls can simplify large installations, although their value depends on the organization’s package topology, trust boundaries and Kubernetes operations.
The known issues belong in the upgrade decision
The 3.22 release notes identify upgrade hazards that administrators cannot treat as footnotes. Custom firewall rules are removed during an upgrade and must be reapplied. Existing scheduled Dependabot version updates may stop after the upgrade; GitHub’s documented trigger is to save a change to each affected repository’s .github/dependabot.yml file. GitHub also reports that a restore performed while the new replication controller is enabled does not restore the storage directory. These issues touch network policy, supply-chain maintenance and recovery, three areas where silent assumptions can create prolonged failures.
GitHub further warns that enabling an enterprise security configuration across many repositories can create substantial system load because jobs are queued across organizations at once. Its suggested mitigation is to apply the configuration incrementally at the organization level. GitHub began reserving the /repos path in version 3.20, and version 3.22 activates the new repositories dashboard at that path. Existing usernames, organizations, applications, proxies or integrations using that route may therefore conflict with the new functionality.
The release notes also retire high-availability replication for cluster topologies in version 3.22. This restriction applies specifically to cluster-topology replication and should not be broadened into a claim that GitHub retired every form of GHES high availability. GitHub does not document a replacement or workaround for the retired cluster capability in the release record, making topology an additional upgrade-eligibility question for affected operators.
GHES 3.22 advances self-hosted development infrastructure by centralizing access policy, reducing some repeated analysis and offering a controlled route from Copilot CLI to an administrator-selected model. Its strongest contribution is not an included private model. It is a configurable boundary around an external or locally operated model endpoint. Organizations evaluating the release should therefore separate generally available additions from technical previews, treat GitHub’s performance figures as early first-party evidence and account for the documented upgrade defects and topology restriction before moving a production appliance.