July 29, 2025
Warning: We have received a few reports of performance issues with GitHub Enterprise Server versions 3.15, 3.16, and 3.17. Out of an abundance of caution, we recommend holding off on upgrading to these versions until further notice. [Updated: 2025-08-01]
3.17.4: Security fixesThe maintenance page in the Management Console did not include cross-site request forgery (CSRF) protection.
Packages have been updated to the latest security versions.
When generating a support bundle, site administrators could encounter errors if character escaping caused the bundle script to omit the URL parameter for curl.
Administrators would occasionally encounter timeouts when downloading diagnostics via the Management Console.
In full cluster topologies, some expensive stats queries are skipped during ghe-cluster-support-bundle to prevent overloading the nodes with identical requests.
Unsuccessful attempts to sign in to the Management Console were reported in the audit log and were indistinguishable from successful attempts.
Taking a backup snapshot would sometimes fail because of a permissions error when the backup process attempted to create log files.
Enterprise Managed Users (EMUs) who were restricted from creating user namespace repositories could still create repositories in organizations and transfer them to their user namespace.
SCIM provisioning requests failed when a user’s non-primary email was sent by the identity provider.
SCIM managed enterprise users were able to edit email addresses.
Administrators and users could experience delays due to performance regressions affecting the background processing of notification jobs.
For administrators performing a live upgrade, a new entry point has been added to the upgrade container to clean up database tables. This utility can be run manually via ghe-live-migrations -cleanup, and is also executed automatically via ghe-config-apply after a complete upgrade.
During pre-upgrade operations of a live upgrade, tables are now renamed instead of being dropped immediately. The tables are then dropped at a later stage via ghe-config-apply.
Events for adding or removing issues and pull requests from a project, or changing their status within a project, are now included in the items timeline alongside existing events. This update helps administrators and users more comprehensively track project-related activity.
Custom firewall rules are removed during the upgrade process.
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 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.
Admins setting up cluster high availability (HA) may encounter a spokes error when running ghe-cluster-repl-status if a new organization and repositories are created before using the ghe-cluster-repl-bootstrap command. To avoid this issue, complete the cluster HA setup with ghe-cluster-repl-bootstrap before creating new organizations and repositories.
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.
Customers operating at high scale or near capacity may experience unexpected performance degradation, such as slow response times, background job queue spikes, elevated CPU usage, and increased MySQL load. Consider upgrading to 3.17 with caution.
The autolink references feature is missing from the repository settings page.
When attempting to open a pull request as a draft in a private or internal repository, users are incorrectly prompted to upgrade their plan.[Updated: 2025-08-11]
July 15, 2025
📣 This is not the latest patch release of Enterprise Server. Please use the latest release for the latest security, performance, and bug fixes.
Warning: We have received a few reports of performance issues with GitHub Enterprise Server versions 3.15, 3.16, and 3.17. Out of an abundance of caution, we recommend holding off on upgrading to these versions until further notice. [Updated: 2025-08-01]
3.17.3: Security fixesHIGH: An incorrect authorization vulnerability allowed unauthorized read access to the contents of internal repositories for contractor accounts when the Contractors API feature was enabled. The Contractors API is a rarely-enabled feature in private preview. Following this fix, contractor account access to internal repositories via the API will be correctly blocked unless they have an alternate grant. GitHub has requested CVE ID CVE-2025-6981 for this vulnerability.
Packages have been updated to the latest security versions.
Applying a new GitHub Enterprise Server license using the Management Console would sometimes fail with a HTTP 500 error.
Users saw outdated references to delegated bypass for push protection being in beta in the documentation for webhooks. Users may also have noticed unexpected behavior related to filtering newly approved push protection bypass requests on repository and organization request list pages.
Site administrators can now set innodb_buffer_pool_size in megabytes for MySQL using ghe-config mysql.innodb-buffer-pool-size VALUE.
Site administrators running migrations on GitHub Enterprise Server benefit from optimized performance for code scanning, as garbage collection-related ts_analyses migrations are combined into a single step. This reduces migration time and minimizes operational disruption during upgrades.
Customers operating at high scale or near capacity may experience unexpected performance degradation, such as slow response times, background job queue spikes, elevated CPU usage, and increased MySQL load. Consider upgrading to 3.17 with caution. [Updated: 2025-07-23]
Custom firewall rules are removed during the upgrade process.
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 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.
Admins setting up cluster high availability (HA) may encounter a spokes error when running ghe-cluster-repl-status if a new organization and repositories are created before using the ghe-cluster-repl-bootstrap command. To avoid this issue, complete the cluster HA setup with ghe-cluster-repl-bootstrap before creating new organizations and repositories.
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.
July 01, 2025
📣 This is not the latest patch release of Enterprise Server. Please use the latest release for the latest security, performance, and bug fixes.
Warning: We have received a few reports of performance issues with GitHub Enterprise Server versions 3.15, 3.16, and 3.17. Out of an abundance of caution, we recommend holding off on upgrading to these versions until further notice. [Updated: 2025-08-01]
3.17.2: Security fixesMEDIUM: An incorrect authorization vulnerability was identified in GitHub Enterprise Server that allowed a user-to-server token with no scopes to disclose private repository names within an organization via Search API endpoint. This requires an organization admin to install a malicious GitHub App in the organizations repositories. GitHub has requested CVE ID CVE-2025-6600 for this vulnerability, which was reported via the GitHub Bug Bounty program.
Packages have been updated to the latest security versions.
The Management Console would become unresponsive when saving settings after a failed config apply run.
Users sometimes received a JSON response instead of a web page when clicking "Back" after viewing files in raw format.
Repositories belonging to organizations with unbundled GitHub Advanced Security licenses did not receive webhooks for scan complete events.
The secret scanning metrics page displayed data for expired delegated bypass requests.
When users added a team with a repository role to the CODEOWNERS file, an unknown error was displayed. Teams with repository roles are now correctly recognized as valid owners of files.
Users could not create or view secret scanning push protection bypass requests for forked repositories because bypass requests were incorrectly associated with the root repository rather than the fork. Forked repositories now support their own bypass requests.
In some cases, uploading a new license with unbundled GitHub Advanced Security did not fully unbundle all security configurations on the instance. Users saw errors such as "Advanced Security is not purchased" or "Validation failed: Secret scanning non provider patterns" when they tried to apply configurations to new repositories.
The babeld service no longer reports log messages about some common client-induced networking errors, reducing noise in the logs.
Customers operating at high scale or near capacity may experience unexpected performance degradation, such as slow response times, background job queue spikes, elevated CPU usage, and increased MySQL load. Consider upgrading to 3.17 with caution. [Updated: 2025-07-28]
Applying a new GitHub Enterprise Server license using the Management Console can sometimes fail with an HTTP 500 error.
Custom firewall rules are removed during the upgrade process.
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 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.
Admins setting up cluster high availability (HA) may encounter a spokes error when running ghe-cluster-repl-status if a new organization and repositories are created before using the ghe-cluster-repl-bootstrap command. To avoid this issue, complete the cluster HA setup with ghe-cluster-repl-bootstrap before creating new organizations and repositories.
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.
June 18, 2025
📣 This is not the latest patch release of Enterprise Server. Please use the latest release for the latest security, performance, and bug fixes.
Warning: We have received a few reports of performance issues with GitHub Enterprise Server versions 3.15, 3.16, and 3.17. Out of an abundance of caution, we recommend holding off on upgrading to these versions until further notice. [Updated: 2025-08-01]
3.17.1: Security fixesHIGH: An attacker could execute arbitrary code, potentially leading to privilege escalation and system compromise, by exploiting the pre-receive hook functionality to bind to dynamically allocated ports that become temporarily available (for example, during a hot patch upgrade). This vulnerability is only exploitable under specific operational conditions, such as during the hot patching process, and requires either site administrator permissions or a user with privileges to modify repositories containing pre-receive hooks. The initial fix for this issue was found to be incomplete, leaving the vulnerability exploitable in some cases. GitHub has requested CVE ID: CVE-2025-3509 for this vulnerability, which was reported via the GitHub Bug Bounty program.
Packages have been updated to the latest security versions.
The Management Console maintenance page would not load correctly if the underlying API call fails to load the connection services data.
On an instance with GitHub Actions configured to connect to Azure OIDC storage through a proxy, Actions logs and artifacts would not be properly stored.
Site administrators and auditors reviewing audit logs saw the mc_actor field was empty when a user signed out, because audit logging occurred after the user was removed from session state.
On instances with a large number of code scanning users, running ghe-config-apply previously resulted in slow performance.
During hotpatching, site administrators could encounter issues with the kernel partition table not updating correctly when running ghe-partition-setup. These users had to manually intervene in order to complete the upgrade process.
Users of GitHub Actions could not view or manage Actions artifacts and logs if the global AWS STS endpoint was unavailable, because Actions did not use the configured regional STS endpoint.
Fixed an edge case for certain Security Configurations that would not automatically work when transitioning to unbundled GitHub Advanced Security SKUs.
When users clicked and held on search suggestions in the search bar, they were not taken to the correct location.
Organization owners had no audit log events to track organization announcements displayed on banners in the UI.
If an Enterprise Managed User (EMU) pushed to their personal repository with both secret scanning and push protection enabled, the custom patterns defined at enterprise level were not being applied during the push protection scan.
On instances with dangling commit graph lock files, recompute checksum operations were unexpectedly triggered.
After an appliance reboot, code scanning did not always trigger or process analyses.
In some situations, the kafka-lite service could cause client timeouts when processing consumer group membership sessions and expirations. [Updated: 2025-07-14]
Site administrators who test the Prometheus endpoint can now use 127.0.0.1 as a trusted IP address. Previously, only specific IPs were allowed for testing.
To ensure critical integrations and automated systems have uninterrupted access, the /repositories/:repository_id/collaborators endpoints now honor the higher rate limits for exempt users set with ghe-config app.github.rate-limiting-exempt-users "<USER>".
Site administrators can now set rate limits for the WebSockets controller used for live updates, with ghe-config app.github.web-sockets-rate-limit. For more information, see Controlling the rate for the live update service.
Site administrators who manage dependencies with the base-pinned image should no longer rely on the vulcanizer CLI, as it is in the process of being retired and replaced with vulcancli. Transition to vulcancli to ensure continued support and compatibility.
Customers operating at high scale or near capacity may experience unexpected performance degradation, such as slow response times, background job queue spikes, elevated CPU usage, and increased MySQL load. Consider upgrading to 3.17 with caution. [Updated: 2025-07-28]
Custom firewall rules are removed during the upgrade process.
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 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.
Admins setting up cluster high availability (HA) may encounter a spokes error when running ghe-cluster-repl-status if a new organization and repositories are created before using the ghe-cluster-repl-bootstrap command. To avoid this issue, complete the cluster HA setup with ghe-cluster-repl-bootstrap before creating new organizations and repositories.
In a cluster, the host running restore requires to access the storage nodes via their private IP addresses.
On an instance hosted on Azure, comments made on an issue via email are 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.
Uploading a new license with unbundled GitHub Advanced Security may not fully unbundle all the Security Configurations on the instance in certain cases. Any active Security Configurations will continue to function, but when attempting to apply the configurations to new repositories you may see errors like "Advanced Security is not purchased" or Validation failed: Secret scanning non provider patterns. Non-provider patterns must be disabled when secret scanning is disabled. Contact GitHub Support for assistance clearing this state in version 3.17.1. This issue will be resolved in version 3.17.2.
June 03, 2025
📣 This is not the latest patch release of Enterprise Server. Please use the latest release for the latest security, performance, and bug fixes.
Warning: We have received a few reports of performance issues with GitHub Enterprise Server versions 3.15, 3.16, and 3.17. Out of an abundance of caution, we recommend holding off on upgrading to these versions until further notice. [Updated: 2025-08-01]
3.17.0: FeaturesDuring the upgrade to 3.17, the database transitions will be run concurrently. You may notice the upgrade taking less time.
GitHub Enterprise Server Backup Service is a managed backup solution built directly into the appliance. It provides simplified alternative to the backup-utils. The backup service is in public preview. See About the backup service for GitHub Enterprise Server.
Users can secure code in their organizations and enterprises in an easier, more affordable, and scalable way to secure their code with the new standalone GitHub Advanced Security (GHAS) products: Secret Protection and Code Security. See Introducing GitHub Secret Protection and GitHub Code Security and GitHub Secret Protection and GitHub Code Security for GitHub Enterprise on the GitHub Blog.
Organization owners can establish an approval process to control sensitive actions, such as restricting dismissal privileges of secret scanning alerts to designated individuals. This mitigates the risk of unauthorized changes and provides a documented record of bypass usage. See Delegated alert dismissal for code scanning and secret scanning now available in public preview on the GitHub Blog, and Establishing a governance framework for your enterprise.
Users can now access secret scanning scan events via the audit log and webhooks. Providing scan status visibility and reporting aims to enable users to independently diagnose unexpected scan behavior, as well as meet the auditing and compliance requirements of large enterprises by demonstrating scan activity. See Audit log and webhook events for secret scan completions on the GitHub Blog.
The detection of Base64-encoded GitHub tokens is now generally available, which means that users have better visibility into any leaked PATs. See Secret scanning detects Base64-encoded GitHub tokens on the GitHub Blog.
The "Experimental" tab name for alerts, which caused confusion by leading certain users to underestimate the importance of its alerts, has been renamed "Generic". This tab includes alerts for non-provider patterns, which are not necessarily low confidence alerts. See Renaming secret scanning experimental alerts to generic alerts.
Enterprises can manage push protection bypass requests for secret scanning via the REST API, enabling integration with existing workflows for reviewing and triaging. Reviewers can retrieve and act on bypass requests at the organization or repository level using new endpoints. This functionality supports delegated bypass controls, allowing only authorized users to bypass push protection, while others must submit requests for approval. See the GitHub Blog post.
Organization owners can establish an approval process to control sensitive actions, such as restricting dismissal privileges of code scanning alerts to designated individuals This mitigates the risk of unauthorized changes and provides a documented record of bypass usage. See Delegated alert dismissal for code scanning and secret scanning now available in public preview on the GitHub Blog, and Establishing a governance framework for your enterprise.
Users can access and search audit logs for code scanning-related events. These logs capture events impacting enterprises or organizations, including code scanning activities such as alert creation, resolution, reopening, or appearance in a new branch. See Code scanning now creates alert-related events in audit log on the GitHub Blog.
This release comes installed with version 2.20.7 of the CodeQL CLI, used in the CodeQL action for code scanning. Significant updates since the default version installed on GitHub Enterprise Server 3.16 include:
cpp/static-buffer-overflow.Users can automatically keep their bun, Docker Compose, and uv dependencies up to date with Dependabot version updates. See Supported ecosystems and repositories.
Users can use EPSS scores to help prioritize dependency vulnerabilities based on exploit likelihood. Using EPSS scores allows users to address vulnerabilities that are more likely to be exploited, reducing the risk of actual attacks. See Dependabot helps users focus on the most important alerts by including EPSS scores that indicate likelihood of exploitation, now generally available.
Developers using pnpm workspaces can ensure more reliable dependency updates with full Dependabot support for pnpm workspace catalogs. Dependabot prevents lockfile inconsistencies, avoids broken dependency trees, and improves update reliability in monorepos. See the GitHub blog post.
Automated user provisioning with the System for Cross-domain Identity Management (SCIM) standard is generally available. SCIM is a leading standard for user lifecycle management in SaaS applications. GitHub Enterprise Server instances using SAML authentication can enable SCIM to provision and manage user accounts from an identity provider (IdP). GitHub supports common integrations such as Entra ID and Okta, or you can use a custom SAML IdP and SCIM implementation to meet your organization's needs. You can configure SCIM using a supported IdP application or the SCIM REST API. See About user provisioning with SCIM on GitHub Enterprise Server.
Fine-grained personal access tokens (PATs) and PAT lifetime policies are now generally available. These tokens offer improved security with per-organization access, token approval workflows, and better auditability through token ID tracking in audit logs. With lifetime policies you can also force the rotation of tokens on a configurable basis, helping drive down the use of long-lived PATs in your environment. See Fine-grained PATs are now generally available on the GitHub Blog.
Administrators can use the GHES Management Console to configure repository exports with local storage, reducing reliance on external blob storage and simplifying the migration process. Exports are stored on the GHES disk, and customers can choose how to provide the archive to GitHub Enterprise Importer, including using GitHub-owned blob storage.
Audit log streaming of API requests targeting your enterprise's private assets is generally available.
Push rulesets are generally available. Users can block pushes to private and internal repositories, and their forks, based on file type, path, or size. Unlike pre-receive hooks, push rules are built-in, configurable via the UI or API, and support audit logs, evaluate mode, and bypass lists. See About rulesets.
Enterprise administrators can manage rules more efficiently with the general availability of ruleset history, import, and export. Ruleset history allows tracking and rolling back changes, while import and export simplify sharing and reusing rulesets, including GitHub's ruleset-recipes. See github/ruleset-recipes.
Repository administrators can easily convert a fork into a standalone repository by leaving the fork network, which stops automatic syncing with the upstream repository. This is useful for taking a project in a new direction or maintaining separate versions.
Users can more easily explore contributors and code frequency insights with improved navigation, interactive chart legends for hiding data series, and options to view or download the data as a CSV or PNG. See Repositories - Updated insight views (General Availability) on the GitHub Blog.
The refreshed pull request commits page is generally available. The updated page improves performance, aligns with GitHub's design system, and offers better accessibility.
Users can moderate comments on gists by turning them off or deleting unwanted entries. See Moderating gist comments.
Verified commits are attached to persistent verification records, allowing users to identify the first actor to introduce a commit to a repository. Users can rotate, expire, or revoke their signing key without impacting existing verifications.
Verification records consume approximately 80 bytes on disk per signed commit. To limit data growth on large instances, site administrators can run ghe-config app.persist-commit-signature-verification.enabled false to disable persistent records.
GitHub Mobile users can quickly view their recent projects by clicking the Projects view from the Home screen.
GitHub Mobile supports additional functionality when connected to instances running GitHub Enterprise Server 3.17:
GitHub App developers can improve security with a 25-key limit per app, encouraging safer key management practices. Apps exceeding the limit must delete excess keys before adding new ones. Additionally, scoped tokens can access more repositories. See Managing private keys for GitHub Apps.
Enterprise owners can centrally manage and share GitHub Apps across all organizations in their enterprise by creating enterprise-owned GitHub Apps. This eliminates the need to duplicate apps or make them public, reducing management overhead and improving security. Private and internal apps can be transferred to the enterprise level, with permission updates automatically applied across all organizations. Only internal visibility is supported, meaning only users and organizations within the enterprise can install and authorize these Apps. See Creating GitHub Apps for your enterprise.
Fetches from repository caches returned a "Repository not found" error when the cache is out of sync. [Updated: 2025-06-19]
SAML response processing includes additional validation and schema checks. We recommend testing your SAML configuration on an upgraded staging appliance before upgrading your production appliance. See the SAML configuration guide for details on the required pieces of data, SAML configuration reference.
Users see a horizontal navigation bar at the top of their enterprise account. This update is designed to improve the user experience by providing a consistent, intuitive navigation structure that mirrors the rest of the GitHub experience.
Customers operating at high scale or near capacity may experience unexpected performance degradation, such as slow response times, background job queue spikes, elevated CPU usage, and increased MySQL load. Consider upgrading to 3.17 with caution. [Updated: 2025-07-28]
Custom firewall rules are removed during the upgrade process.
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. 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 an appliance with version 3.13 or greater, the Elasticsearch indices must be reindexed before the data will display. 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.
Admins setting up cluster high availability (HA) may encounter a spokes error when running ghe-cluster-repl-status if a new organization and repositories are created before using the ghe-cluster-repl-bootstrap command. To avoid this issue, complete the cluster HA setup with ghe-cluster-repl-bootstrap before creating new organizations and repositories.
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 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.
Uploading a new license with unbundled GitHub Advanced Security may not fully unbundle all the Security Configurations on the instance in certain cases. Any active Security Configurations will continue to function, but when attempting to apply the configurations to new repositories you may see errors like "Advanced Security is not purchased" or Validation failed: Secret scanning non provider patterns Non-provider patterns must be disabled when secret scanning is disabled. Contact GitHub Support for assistance clearing this state in version 3.17.0. This issue will be resolved in version 3.17.2.
In GitHub Enterprise Server 3.20, GitHub will retire the security manager API in favor of the organization roles API. See the GitHub Blog.
Microsoft Exchange Online is retiring SMTP basic authentication in September 2025. If your GitHub Enterprise Server instance uses this method to send email, delivery may fail after the retirement date. Microsoft recommends switching to a supported alternative. As another option, you may consider using an SMTP OAuth proxy such as email-oauth2-proxy, though this is not officially supported. For details and configuration guidance, see the Microsoft announcement and the proxy’s documentation.
Real-time job status updates for GitHub Actions workflow notifications in Slack and Microsoft Teams are no longer available. Users still receive notifications when a workflow starts and completes, but intermediate job progress updates have been removed to improve system efficiency.
In GitHub Enterprise Server 3.17, tag protection rules will be migrated to a ruleset, and the tag protection rule feature will no longer be available.
Dependabot is no longer supporting Python 3.8, which has reached its end-of-life. If you continue to use Python 3.8, Dependabot will not be able to create pull requests to update dependencies. If this affects you, we recommend updating to a supported release of Python. As of February 2025, Python 3.13 is the newest supported release.
Dependabot is no longer supporting NPM version 6, which has reached its end-of-life. If you continue to use NPM version 6, Dependabot will be unable to create pull requests to update dependencies. If this affects you, we recommend updating to a supported release of NPM. As of December 2024, NPM 9 is the newest supported release.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4