Enterprise Server 3.22 release notes

Site administrators can configure MySQL temporary table and heap table size limits using ghe-config to work around a known MySQL optimizer issue that can cause queries to use disk-based temporary tables unnecessarily. To adjust the temporary table size, run ghe-config mysql.tmp-table-size <value> followed by ghe-config-apply.

CRITICAL: An attacker with network access to a GitHub Enterprise Server instance could supply a notebook viewer URL specifying an explicit port to reach internal services co-located on the appliance. Although response bodies were not returned, response timing could act as an oracle that allowed instance secrets to be extracted. These secrets could be used to obtain remote code execution on the appliance. Exploitation was unauthenticated when private mode was disabled and required any authenticated user when private mode was enabled. GitHub Enterprise Server now rejects notebook viewer URLs that specify an explicit port. GitHub has requested CVE ID CVE-2026-77987 for this vulnerability. This vulnerability was reported through the GitHub Bug Bounty program.

HIGH: An authenticated attacker could execute malicious scripts in another user's browser by posting crafted Markdown content, such as an issue comment, that injected arbitrary HTML attributes into the rendered page. Successful exploitation could allow the attacker to read data visible to the victim, perform state-changing actions as the victim, exfiltrate data, and propagate the payload using the victim's write access. This was possible because the Markdown rendering pipeline rewrote quote characters in already-sanitized HTML without re-sanitizing the result. GitHub has requested CVE ID CVE-2026-77912 for this vulnerability, which was reported via the GitHub Bug Bounty program.

Server reports under /stafftools/reports/ were accessible using a legacy non-expiring token. If you were accessing these reports programmatically using this legacy approach, you will need to switch to using a personal access token (classic) with the site_admin scope.

An attacker could corrupt an in-progress package upload in GitHub Packages by obtaining the identifiers for that upload, because the registry did not verify the users permissions before continuing or completing an upload. GitHub has addressed this by validating authorization before any changes are made to an upload.

Fixes a bug where Dependabot stopped running scheduled version updates after upgrade

GHES administrators running instances with high-write workloads experienced increased Redis memory use and latency because Redis created periodic RDB snapshots in addition to its configured AOF persistence.

Customers with the OpenTelemetry observability stack enabled experienced a loss of metrics after reboot because some exporter services failed to start due to a dependency on the data disk being mounted.

Upgrade for HA with scale-out nodes could fail with HAProxy exceeding FD limit.

On instances whose user data disk was initialized before the ownership fix in ghe-storage-init, /var/log/github-backup remained owned by root:root, so the admin user could not write to it and ghe-backup failed immediately with a permission-denied error.

Management Console users other than the root site administrator received an HTTP 401 error when they clicked "Backup Now" or attempted to delete (prune) a backup on the Backups page, even though the controls were displayed to them. These authenticated operators can now start and prune backups successfully.

Users experienced slow Git LFS uploads over high-latency network connections, because the instances HAProxy frontend advertised a fixed HTTP/2 initial receive window that throttled each stream to roughly one 64 KiB window per round trip. Administrators can now tune this window with ghe-config core.haproxy-h2-fe-initial-window-size <bytes>, using a value between 65536 and 67108864 (64 KiB-64 MiB) inclusive, to improve throughput for large uploads. The setting is opt-in and disabled by default.

Kafka-lite sessions in Grafana dashboard showed empty panels.

Configured standalone restores could omit storage objects when Replication Controller changed storage topology before the restore completed. Replication Controller is now paused during this restore window.

The ghe-cluster-support-bundle -x short option required an argument to run.

On AWS and Azure, ghe-setup-network now applies explicitly configured IPv6 networking without enabling IPv6 during IPv4-only network updates. The -4 and -6 options now disable the selected address family, and explicit IPv4 and IPv6 network configuration is preserved across feature upgrades.

Administrators running backups with the backup service could see a successful exit code even when rsync failed to back up repositories and gists. The backup service now reports these failures correctly.

On an instance with suspended users, organization member counts on the enterprise organizations page and the organization people page included suspended users. This caused the displayed count to be higher than the number of members visible in the list.

On an instance with security overview enabled, reconciliation could repeatedly retry when background job queues were busy, causing high CPU usage and delays across the appliance.

The first user created via SAML-JIT during first-run bootstrap on a fresh GHES appliance was not added as an Enterprise owner.

Enterprise Managed Users could remain absent from enterprise membership listings and the enterprise.members GraphQL response after being reinstated.

On the secret scanning metrics page for a large enough enterprise, the page could time out.

Enterprise owners would sometimes experience timeouts when loading the "Notifications preferences" section on the "Verified & approved domains" page.

Administrators who deleted a user that belonged to an organization received a 500 error, even though the user was successfully removed. Previously, the deletion attempted to enqueue a job to a Copilot Spaces queue that does not exist on GitHub Enterprise Server, causing the request to fail.

Advanced security configuration pages would not load at all if there was a timeout affecting certain subsections.

The User contributions backfill job would process the full repository set per user, and not just those with contributions, leading to an excessively high user_contributions_backfill queue backlog and contributing to high resource consumption when large batches of user changes occur.

Administrators on instances with many organizations experienced security configurations failing to apply to repositories. Fanout processing repeatedly retried without applying repository updates.

GitHub Advanced Security configuration pages would time out too quickly.

On instances using the Noble-based container image, users received errors when using auto-merge because GitHub Enterprise Server could not read the contents of the git and gitro home directories.

On an instance using Redis 7, AOF (append-only file) recovery did not detect or repair corruption in Redis data volumes. This occurred because recovery only checked the legacy single-file AOF path and did not account for Redis 7s multi-part AOF format, which uses a manifest to track data across multiple files.

When an administrator ran a configured restore that changed the appliances identity (UUID), the restore could skip the storage tier and still report success, resulting in an incomplete restore of repository data.

To avoid data processing delays on instances with a large number of internal message topics, administrators can configure the network timeouts used during topic discovery via app.github.topic-checker-connect-timeout-sec and app.github.topic-checker-socket-timeout-sec. The default timeout has been increased from 10 to 30 seconds, and values between 1 and 300 seconds are accepted.

Enterprise Live Migrations skip branch protection rules by default because only part of each rule can be migrated. Partial migration of branch protection rules is opt in with ghe-config app.elm-exporter.migrate-protected-branches true.

Administrators can limit the CPU consumed by MySQL backup dumps by setting a CPU quota with ghe-config backup.cpu-quota. Provide a systemd CPUQuota value, such as 200% to allow up to two cores. The setting is empty by default, which leaves backup behavior unchanged. The cap is applied on the node where each dump runs, including remote cluster and replica nodes.

Upgrade (.pkg) and hotpatch (.hpkg) packages are smaller, reducing the time spent downloading a package and verifying its signature during an upgrade.

Site administrators can ensure that secret scanning uses processor features available on their GHES instance because secret scanning compiles its pattern-matching databases on the instance instead of using prebuilt databases. The first scan of each type after an upgrade or restart can take a few seconds longer while the databases are prepared.

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, shutdown 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 scheduled job that runs on the first Saturday of each month. 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.

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.

After creating a new branch via the New branch button, the /branches page doesn't automatically show the new branch. The page requires a manual refresh before the new branch appears

In some cases, pull requests using auto-merge or merge queue may not merge automatically until mergeability is recalculated.

After upgrading to GHES 3.21, scheduled Dependabot version updates may stop running for pre-existing configurations. If you have already upgraded and want to trigger scheduled version updates, save a change to each affected repository’s .github/dependabot.yml file.

In clustered GitHub Enterprise Server environments, administrators may find that nodes that remain in the cluster but no longer have the git-server, pages-server, or storage-server role remain online and eligible to vote in the corresponding replication tables. Review role-specific replication state and contact GitHub Support if stale rows affect replication.

When restoring an instance with ghe-restore while the replication controller is enabled, the storage directory is not restored.

On a newly booted GitHub Enterprise Server instance, the merge box on a newly created pull request can stay on "Checking for the ability to merge automatically" and not show the merge status. If encountered, refreshing the page shows the correct merge status.

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. This is an internal change, and there is no other documentation.

• The Enterprise Live Migrations (ELM) service is generally available, allowing enterprises to migrate repositories from GitHub Enterprise Server to GHE.com with minimal downtime. A new GitHub CLI extension allows administrators to operate the service from their local machine. See GitHub Enterprise Server から GHE.com へのライブ マイグレーションについて.

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. See GitHub Enterprise Server GitHub Copilot CLI を設定する.

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 信頼されたアクターをプッシュ保護から除外する.

• 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, users 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 users 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 アクション ランナー コントローラー.

• 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" 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.

GitHub Enterprise Server now uses fewer CPU resources when serving REST and GraphQL API requests by skipping unused MySQL query backtrace collection.

On appliances with 84 GB or more of RAM, MySQL could consume most available memory after an upgrade because the default InnoDB buffer pool scales with available RAM. Before adding RAM to increase memory headroom, contact GitHub Support about setting an appropriate mysql.max-memory limit. [Updated: 2026-09-24]

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 time out 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 scheduled job that runs on the first Saturday of each month. 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 to 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.

In some cases, pull requests using auto-merge or merge queue may not merge automatically until mergeability is recalculated.

After upgrading to GitHub Enterprise Server 3.22, scheduled Dependabot version updates may stop running for pre-existing configurations. If you have already upgraded and want to trigger scheduled version updates, save a change to each affected repository's .github/dependabot.yml file.

When restoring an instance with ghe-restore while the replication controller is enabled, the storage directory is not restored.

In clustered GitHub Enterprise Server environments, nodes that remain in the cluster after losing the git-server, pages-server, or storage-server role may stay online and remain eligible to vote in the corresponding replication tables. Review the replication state for each role, and contact GitHub Support if stale rows affect replication.

On a newly booted GitHub Enterprise Server instance, the merge box on a newly created pull request can stay on "Checking for the ability to merge automatically" and not show the merge status. If encountered, refreshing the page shows the correct merge status.

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. Users still running legacy ARC versions should migrate to the latest ARC release to continue receiving critical improvements and observability features. For more information, see アクション ランナー コントローラー.

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 users. 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 ルールセットについて.