Enterprise Server 3.22 release notes

Instance administration

• Phased upgrade execution gives you better control over downtime-inducing actions by isolating those actions to their own phase. You can now run the pre-upgrade stage of an upgrade outside the maintenance window using ghe-upgrade --phase pre-upgrade -y UPGRADE-PACKAGE-FILENAME. Running the pre-upgrade stage in advance can reduce in-maintenance upgrade time by up to 20 minutes. For more information, see Обновление с помощью пакета обновления.

• Replication operations such as starting and stopping replication and Config Apply are less dependent on each other, reducing runtime and the risk of unrelated component failures. A new replication controller service is introduced, and it manages data replication by monitoring the desired state of the system and reconciling replication configuration for Git, Pages, storage, MySQL, Elasticsearch, GitHooks, and Redis.

Copilot

• Copilot CLI can be configured to work with GitHub Enterprise Server for enterprises that operate in disconnected or air-gapped environments without connectivity to GitHub Enterprise Cloud. An administrator can configure a model provider once in GitHub Enterprise Server, and end users across the enterprise can use Copilot CLI with their GitHub Enterprise Server credentials. This capability is in technical preview and subject to change. We recommend waiting until GitHub Enterprise Server 3.22 reaches general availability (GA) before validating and using this capability. We are publishing the note early to provide visibility into what is coming.

Identity and access management

• Enterprise Teams, previously in public preview, is now generally available. Enterprise owners can use Enterprise Teams to manage users and their access across the entire enterprise, including organizations and repositories, from a single, centralized team structure. This reduces the operational overhead of managing user access across multiple organizations within an enterprise.

GitHub Advanced Security

• Security analysts can now sort secret scanning push protection bypass requests and secret scanning alert dismissal requests by date, in ascending or descending order, using the filter bar at the repository, organization, and enterprise levels. Previously, sort order for these requests could not be adjusted, which made it difficult for teams managing high volumes of requests to prioritize their review. For more information, see Управление оповещениями проверки секретов.

• Organization owners can now enable periodic code scanning of repositories that have been inactive (no commits) for 180 days or more. Previously, code scanning with its default setup stopped scanning repositories after 180 days of inactivity. This option helps organizations that need to scan all repositories periodically for compliance reasons. For details, see the changelog.

• This release comes installed with CodeQL 2.25.6. Significant updates since the previous version include:

  • CodeQL can analyze projects using Swift up to 6.3.2.

  • Users working with Kotlin can analyze projects using Kotlin up to 2.3.20.

  • CodeQL now has full support for C# 14 and .NET 10, including partial constructors, user-defined compound assignment operators, and generated data flow models for the .NET 10 runtime. Expanded ASP.NET remote source modeling improves detection of taint flows in ASP.NET applications.

  • The Python extractor supports the new lazy import syntax defined in PEP-810 (Python 3.15).

  • The Java control flow graph has been completely rewritten for improved analysis precision, and false positives have been reduced across multiple queries including path injection, sensitive logging, and trust boundary violation.

  • Five C/C++ queries have been promoted to the default code scanning query suite, and taint flow models have been added for the Windows SDK (Strsafe.h and scanf_s).

  • Security queries for JavaScript/TypeScript now detect vulnerabilities in Vercel serverless functions, and new browser-specific source kinds are available for data extensions.

  • GitHub Actions analysis has been expanded to cover composite action metadata files, with improved detection for artifact poisoning and untrusted checkout scenarios.

  • Users can now add custom data flow barriers and sanitizer models using data extensions across all supported languages, making it easier to suppress false positives without modifying queries directly.

  • Security severity scores have been realigned across multiple languages, increasing XSS query scores and reducing log injection scores to better reflect actual impact.

  • Read more in the changelogs for the CodeQL versions included in this release:

    • CodeQL 2.25.0
    • CodeQL 2.25.2
    • CodeQL 2.25.3
    • CodeQL 2.25.4
    • CodeQL 2.25.5
    • CodeQL 2.25.6

• Code scanning with CodeQL now performs incremental analysis for pull requests in C/C++, Go, Python, JavaScript, TypeScript, Ruby, and Java repositories. By performing incremental extraction and evaluation, CodeQL analyzes only the code that changed instead of re-scanning the entire codebase, significantly reducing scan duration—with early results showing improvements between 2x and 10x. This gives developers faster feedback on pull requests, helping teams identify and remediate vulnerabilities more quickly without slowing down development. For details, see the changelogs for C/C++ and Go and Ruby and Java.

• Security managers can now use a standardized filter bar to search and filter delegated bypass requests in Security Overview, providing a consistent filtering experience across bypass views. For details, see the changelog.

• Repository administrators can now exempt trusted automation, such as migration bots and service accounts, from secret scanning push protection at the repository level. This allows high-volume automated pushes to proceed without push protection friction, while enforcement remains in place for all other contributors. Exemptions can also be configured at the organization and enterprise level, and exemption status is evaluated at the time of each push. For more information, see Освобождение доверенных участников от защиты от push.

• Enterprise owners can now disable GitHub Advanced Security for all private and internal repositories directly from the Enterprise licensing page. Disabling GitHub Advanced Security this way also sets a policy that prevents future paid adoption of GitHub Advanced Security, helping to avoid unexpected billing or accidental re-enablement.

• Developers and security teams can now set a custom, user-defined validity state for secret scanning alerts created from custom patterns using the REST API. Sending a PATCH request to update an alert now accepts a validity value of active, inactive, or unknown, and sending null clears any existing user-defined override. When a user manually sets validity, the alert's GET response includes a new validity_set_by field identifying who set it.

  This provides teams with more flexibility to prioritize and track secret scanning alerts programmatically, including custom pattern and partner alerts where GitHub cannot automatically determine validity. For more information, see Конечные точки REST API для проверки секретов. For details, see the changelog.

• Organization owners and security managers can enable GitHub Advanced Security features more easily with a new wizard-style setup dialog on the security configurations page. The guided experience lets users choose which security products to enable and where to apply them, and first-time users see a setup splash page that opens the wizard. This makes it simpler for users who are less familiar with GitHub Advanced Security to complete setup. For more information, see Настройка функций безопасности в вашей организации. For details, see the changelog.

• Developers and security teams can now link code scanning alerts to GitHub Issues, making it easier to collaborate on and track remediation work directly within GitHub. This closes the traceability gap that occurs when switching between GitHub and external work tracking tools. This feature is in public preview and subject to change. For details, see the changelog.

• Security Overview now displays code scanning CodeQL alerts from pull request analysis for branches other than the default branch. Previously, Security Overview only reported alerts and autofix statistics for the default branch, which meant alert counts did not reflect the full scope of protected branches. Site administrators and security teams can now see a more complete picture of code scanning coverage across all protected branches.

Dependabot

• Organization owners can now configure OpenID Connect (OIDC) for private registries used by Dependabot and code scanning directly from the organization settings UI, rather than needing to configure OIDC in each repository's dependabot.yml file. This simplifies enabling secure, tokenless authentication to private package registries across all repositories in an organization. For more information, see Настройка доступа к частным реестрам для Dependabot.

• Organizations can now configure multiple private registries per ecosystem for Dependabot, removing the previous limitation of one registry per ecosystem type. This allows organizations with multiple private package sources for the same ecosystem, such as two separate NuGet feeds, to register all of their private feeds and have Dependabot authenticate against each one correctly, including when multiple registries share the same host.

• Developers using Deno can now receive Dependabot version updates for their Deno projects. Dependabot detects Deno dependency manifests and opens pull requests to keep dependencies up to date. For more information, see Поддерживаемые экосистемы и репозитории Dependabot.

• Developers can now receive Dependabot version updates for projects that use sbt as their build tool. This expands Dependabot's version update support to teams working with Scala projects managed by sbt. For details, see the changelog.

• Dependabot now supports Poetry v2 for version and security updates, allowing users of Poetry v2 to receive Dependabot alerts and pull requests to keep their dependencies up to date and secure.

• Enterprise owners can allow Dependabot to access internal and private repositories across organizations within the same enterprise. This enterprise-level setting lets Dependabot update jobs in one organization resolve dependencies hosted in internal or private repositories of another organization, extending innersource dependency management beyond single-organization boundaries. Cross-organization access events are fully covered in the audit log. For details, see the changelog.

• Dependabot now supports the Nix ecosystem, enabling automated dependency updates for projects that use Nix Flakes for dependency management. Previously, Nix dependencies appeared as an "unknown" ecosystem with a generic icon on the Dependabot settings page. Now, Nix is correctly recognized and visually identifiable, bringing it to parity with other supported ecosystems. For details, see the changelog.

• Developers using Swift packages in Xcode projects can now get automated dependency updates from Dependabot, even when their project doesn't include a standalone Package.swift file. Dependabot now discovers and updates Swift package dependencies in Xcode projects that use .xcodeproj manifests with Package.resolved files. For more information, see Поддерживаемые экосистемы и репозитории Dependabot.

• Dependabot now detects and alerts on known malicious package versions, starting with npm packages and expanding to additional ecosystems over time. Previously, customers had little to no signal from GitHub when a dependency was compromised by a supply chain attack, making it difficult to identify and remediate malware quickly. With this release, repositories that depend on packages identified as malware receive proactive Dependabot alerts, helping administrators and developers respond faster to targeted attacks. For details, see the changelog.

GitHub Actions

• Maintainers can now suppress "Run cancelled" notifications while still receiving "Run failed" notifications for their GitHub Actions workflows. This gives users more control over the notifications they receive when manually cancelling a workflow run.

• Actions Runner Controller (ARC) now supports multiple labels for a single scale set. Previously, ARC supported only one label per scale set, which forced enterprises to create multiple scale sets to cover overlapping configurations, leading to operational complexity and inefficient resource utilization. With multi-label support, administrators can target runners based on combined attributes, such as operating system, hardware tier, compliance zone, and network configuration, within a single scale set. This reduces the number of redundant scale sets, improves utilization, and preserves backward compatibility with existing single-label configurations.

• Actions Runner Controller (ARC) 0.14.0 delivers quality-of-life improvements that reduce operational complexity for customers running self-hosted runners on Kubernetes. This release includes refined Helm charts for easier Docker configuration, improved logging for better troubleshooting, updated metrics aligned with recent platform availability initiatives, and formalized versioning requirements for ARC. For more information, see Контроллер runner действий.

• Developers can now specify a timezone when scheduling workflows with the cron syntax, allowing scheduled workflow runs to be localized to a specific timezone instead of only UTC. This feature is in public preview and subject to change.

Community experience

• Users can sort their notifications from oldest to newest, in addition to the default newest to oldest order, using a new sort dropdown on the notifications page. This helps users who manage large volumes of notifications process their backlog chronologically, making it easier to catch up after vacations, events, or periods of high activity. For more information, see Об уведомлениях.

Organizations

• Organization owners can disable commit comments for all repositories in an organization at once, instead of disabling commit comments repository by repository. This makes it easier for organizations with many repositories to control commenting on commits at scale. For details, see the changelog.

Repositories

• Repository administrators can now rename default branches that are protected by an organization ruleset. Previously, only organization owners could rename these branches. For more information, see Переименование ветви.

• Repository and organization rulesets now support bypassing by individual users, in addition to roles, teams, and apps. This gives administrators more granular control over rule bypass permissions, such as adding a service account to a bypass list without needing to create a dedicated role or team.

• Repository administrators and maintainers can now delete commit comments. Previously, commit comments could not be removed, which allowed spam and abusive comments to persist in repositories. This gives maintainers another tool to reduce spam and unwanted content. For details, see the changelog.

• Organization owners and repository administrators can require specific reviewers for pull requests targeting a given branch by adding a required reviewers rule to a repository ruleset. This provides more granular control over code ownership than a single CODEOWNERS file, which is difficult to scale for large organizations or monorepos. For example, administrators can require QA reviewers on a release branch, security team members on the default branch, or product and design reviewers on feature branches, including setting the minimum number of required reviews per team.

• Developers can find and organize their repositories more efficiently using the new repositories dashboard at /repos. The dashboard displays a developer's most active repositories and allows them to create saved views for quick access to the repositories they use most. This gives developers a centralized page for tracking their work and streamlining their workflows. For details, see the changelog.

Issues

• Developers can now see release status directly in the issue sidebar. When a linked pull request has been included in a release, the sidebar displays a "Latest release" or "Pre-release" badge, making it easy to tell whether a fix has shipped without leaving the issue. For details, see the changelog.

Projects

• Project maintainers can set default values for text, number, and single select fields. When an item is added to a project, these fields are automatically populated with the configured default, reducing repetitive manual data entry. For details, see the changelog.

Commits

• Users can now disable commit comments at the user level, in addition to the existing repository and organization level controls. This is especially useful for the small percentage of users who own more than 100 public repositories, allowing them to manage commit comment settings across all of their repositories from a single location.

Pull requests

• Maintainers can now see contributor role labels, such as "First-time contributor," "Contributor," and "Member," directly in the pull request list view for public repositories. This gives maintainers at-a-glance context about each author's relationship to the repository without needing to open individual pull requests to check the comment box for this information. For details, see the changelog.

Starting in version 3.20, we have reserved the /repos path for a forthcoming product feature. If you currently use /repos for a route (for example, a username, organization name, a GitHub App, OAuth app, reverse proxy, or internal integration), you may need to update your configuration to avoid routing conflicts. Starting in 3.22, the /repos path will show new functionality.

During an upgrade of GitHub Enterprise Server, custom firewall rules are removed. If you use custom firewall rules, you must reapply them after upgrading.

During the validation phase of a configuration run, a No such object error may occur for the Notebook and Viewscreen services. This error can be ignored as the services should still correctly start.

If the root site administrator is locked out of the Management Console after failed login attempts, the account does not unlock automatically after the defined lockout time. Someone with administrative SSH access to the instance must unlock the account using the administrative shell. For more information, see Troubleshooting access to the Management Console.

In some situations, large .adoc files stored in a repository do not render properly in the web UI. The raw contents are still available to view as plaintext.

Admin stats REST API endpoints may timeout on appliances with many users or repositories. Retrying the request until data is returned is advised.

When following the steps for Replacing the primary MySQL node, step 14 (running ghe-cluster-config-apply) might fail with errors. If this occurs, re-running ghe-cluster-config-apply is expected to succeed.

Running a config apply as part of the steps for Replacing a node in an emergency may fail with errors if the node being replaced is still reachable. If this occurs, shut down the node and repeat the steps.

When restoring data originally backed up from a 3.13 or greater appliance version, the Elasticsearch indices need to be reindexed before some of the data will show up. This happens via a nightly scheduled job. It can also be forced by running /usr/local/share/enterprise/ghe-es-search-repair.

When initializing a new GHES cluster, nodes with the consul-server role should be added to the cluster before adding additional nodes. Adding all nodes simultaneously creates a race condition between nomad server registration and nomad client registration.

In a cluster, the host running restore requires access the storage nodes via their private IPs.

On an instance hosted on Azure, commenting on an issue via email meant the comment was not added to the issue.

After a restore, existing outside collaborators cannot be added to repositories in a new organization. This issue can be resolved by running /usr/local/share/enterprise/ghe-es-search-repair on the appliance.

After a geo-replica is promoted to be a primary by running ghe-repl-promote, the actions workflow of a repository does not have any suggested workflows.

When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server 3.13.5.gm4 or 3.14.2.gm3, you may encounter a 401 Unauthorized error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages.

When applying an enterprise security configuration to all repositories (for example, enabling Secret scanning or Code scanning across all repositories), the system immediately enqueues enablement jobs for every organization in the enterprise simultaneously. For enterprises with a large number of repositories, this can result in significant system load and potential performance degradation. If you manage a large enterprise with many organizations and repositories, we recommend applying security configurations at the organization level rather than at the enterprise level in the UI. This allows you to enable security features incrementally and monitor system performance as you roll out changes.

On instances with multiple Git storage nodes in a voting configuration, including cluster and geo-replication high availability topologies, upgrading may fail to correctly install Actions that ship with the new version. In some cases, previous versions of these Actions remain on the instance. To resolve this issue, run the following commands on the primary node: ghe-config --unset 'app.actions.actions-repos-sha1sum', ghe-config-apply, and /usr/local/share/enterprise/ghe-run-init-actions-graph.

When booting a cluster in Terraform-based environments, node names may appear unidentifiable in cluster status output.

In cluster HA environments, ghe-cluster-repl-status may report inconsistent Spokes or Storage status after running ghe-cluster-repl-bootstrap or ghe-cluster-repl-teardown.

Node Eligibility Service, introduced for cluster topologies and gated by the app.nes.enabled feature flag, is closing down in GitHub Enterprise Server 3.22 and will be removed in GitHub Enterprise Server 3.23. There is no replacement; cluster administrators do not need to take any action. If you previously enabled the app.nes.enabled flag, you can disable it now with ghe-config app.nes.enabled false && ghe-config-apply. In 3.22, a closing down warning will appear during ghe-config-apply if the flag is set to true. Node Eligibility Service will continue to function in 3.22, but we recommend planning to stop using it before upgrading to 3.23.

With the release of Actions Runner Controller (ARC) 0.14.0, GitHub has officially announced the closing down of legacy ARC. Customers still running legacy ARC versions should migrate to the latest ARC release to continue receiving critical improvements and observability features. For more information, see Контроллер runner действий.

Collectd metrics will be retired starting in version 3.23. There won't be a Collectd metrics stack in 3.23. We will continue to support the Collectd stack in 3.22 and earlier versions during their respective support windows. For more information, see О собираемых метриках.

With the release of 2026-03-10, the 2022-11-28 version has entered its closing down period and will be retired in the next enterprise server release after 2028-03-10. We recommend planning your migration ahead of this date to avoid any disruption. For more information, see Версии API.

The code_scanning_upload field is no longer included in the response from the rate_limit REST API endpoint. This field displayed a separate rate limit value that was actually joined with the core rate limit, which caused confusion for customers. Removing the field simplifies the rate_limit endpoint response and provides a clearer picture of the rate limits that apply.

The *_enabled_for_new_repositories fields are removed from the REST API for organizations, including advanced_security_enabled_for_new_repositories, dependabot_alerts_enabled_for_new_repositories, dependabot_security_updates_enabled_for_new_repositories, dependency_graph_enabled_for_new_repositories, secret_scanning_enabled_for_new_repositories, secret_scanning_push_protection_enabled_for_new_repositories, and secret_scanning_validity_checks_enabled. Use the code scanning configurations API to manage security feature enablement for new repositories instead. For more information, see Конечные точки REST API для диспетчеров безопасности.

Starting in 3.22, high availability replication for cluster topologies has been retired. You will no longer be able to configure or use the feature, and the supporting code will be removed from the product.

Starting in 3.22, networking-related syscalls will be disabled by default in the pre-receive hook environment. For enhanced security, hook environments will be placed in dedicated network namespaces. You will be able to override the default setting by setting pre-receive-hook-networking to enabled. In many cases, push rulesets are an alternative for many pre-receive hooks. For more information, see Сведения о наборе правил.