GitHub Enterprise Server 3.22 リリース候補版が公開GitHub Enterprise Server 3.22 release candidate

GitHub has published the release candidate for GitHub Enterprise Server (GHES) 3.22, the self-hosted edition of its development platform that organizations run inside their own infrastructure rather than on GitHub's cloud. The release candidate matters because it gives administrators a near-final build to evaluate in staging environments ahead of general availability, helping teams surface compatibility issues and plan upgrades before the version reaches production systems.

According to the changelog, GHES 3.22 introduces new capabilities across the platform, and one of the highlighted additions is the ability for administrators to configure Copilot CLI. Copilot CLI brings GitHub's AI assistance into the command line, allowing developers to interact with Copilot directly from a terminal rather than only within an editor or the web interface. Putting configuration control in administrators' hands is consistent with how GHES generally handles AI functionality: in self-hosted deployments, enterprise operators typically decide whether and how such features are enabled for their users, which supports governance, compliance, and network requirements that differ from cloud-hosted GitHub.

A release candidate is not the same as a stable, generally available release. It represents a feature-complete build that GitHub considers close to final, published so that customers can test it against their own workflows, integrations, and infrastructure. GitHub's guidance for enterprise administrators has historically cautioned against deploying release candidates on production instances, since additional fixes may land before the final build ships. Organizations that maintain separate test environments are the primary audience for an RC, and the availability of this build appears intended to give them lead time to validate the new configuration options and other platform changes.

For context, GitHub Enterprise Server follows a numbered, periodic release cadence, with each version supported for a defined window before it reaches end of life. Administrators are generally expected to upgrade through supported version paths to remain within that support window and to receive security patches. Because GHES runs on infrastructure the customer controls, upgrades involve considerations that cloud users do not face, including backup and restore validation, high-availability replica handling, and verification that connected services such as GitHub Actions runners, GitHub Advanced Security features, and any packaged integrations continue to function after the update.

The addition of administrator-facing Copilot CLI configuration reflects a broader industry pattern in which AI coding assistance is increasingly being extended beyond the integrated development environment and into command-line and automation contexts. Bringing that capability into a self-hosted product is notable because enterprise customers often operate under stricter data-handling, connectivity, and auditing constraints than teams using the public service. Configuration controls at the administrator level are typically what make such features viable in those settings, since they allow an organization to align tool behavior with internal policies before granting access to developers.

Enterprises evaluating the release candidate should treat the changelog as the authoritative source for the full list of changes, since the initial highlights emphasize the Copilot CLI configuration option while noting additional platform-wide updates that were not detailed in the excerpt. Administrators will likely want to review the complete release notes for any changes to system requirements, deprecations, or breaking changes, as these can affect upgrade planning. It is also common for GHES releases to include updates spanning security, administration, and developer-facing tooling, so the practical impact of 3.22 will depend on which components a given organization relies on.

For self-hosted operators, the recommended approach is to install the release candidate in a non-production environment, exercise the features most relevant to their teams, and confirm that existing automation and authentication systems behave as expected. Doing so before general availability gives organizations time to report issues and adjust internal documentation or rollout plans. As with any pre-release software, the exact feature set and behavior may still change before the final version is published, so teams should plan to re-test against the stable release when it becomes available rather than relying solely on the release candidate for their production upgrade decision.