VMware ESXi 8.0 hypervisor support is now available for GitHub Enterprise Server (GHES) 3.16.0, 3.15.4, 3.14.9, 3.13.12, and later. Until now, GHES was supported on ESXi versions 5.5 to 7.0. However, ESXi 7.0 is reaching the end of general support by October 2025.
If your GHES installation is on VMware ESXi 7.x or an earlier version, you can now use the ESXi 8.0 hypervisor. For more information about installing GHES on VMware, see install on VMware.
We’re rolling out two exciting new features in the latest GitHub Desktop Beta to make your workflow even smoother:
Filterable changes: Do you find yourself endlessly scrolling through a long list of changed files? Now, you can filter by filename to review your changes faster. This makes it easier to locate and select exactly what you need for your next commit!
Download GitHub Desktop v3.4.19-beta1 today to try out the new features.
Enterprise Cloud Importer (ECI) and the GraphQL endpoints for importing migration data to GitHub Enterprise Cloud (GHEC) from an archive will be closing down today, March 31, 2025. These tools can no longer be used to import repository data into GitHub’s cloud-based products.
Moving forward, we recommend using GitHub Enterprise Importer (GEI) to migrate repositories to GitHub’s cloud-based products. If you are interested in migrating GitLab repositories to GitHub using GEI, please contact our Expert Services team.
For questions and feedback, please join the Community Discussion.
Enterprise custom properties and enterprise rulesets are now generally available, further improving the governance features for GitHub Enterprise customers.
With enterprise-level custom properties, you can now enrich your repositories with metadata across your entire enterprise. This ensures consistent properties across organizations without the need for manual synchronization. By sharing a common namespace, enterprise and organization properties prevent confusion when searching or targeting rulesets with properties. If you’re already using custom properties in your organizations, you can also promote those properties to the enterprise.
Learn more about enterprise custom properties in our documentation.
Enterprise-level rulesets enforce consistent code governance rules, helping ensure thorough reviews of critical repositories with pull requests, requiring actions workflows, protecting important locations from unauthorized pushes, and more. Rule insights and push rule bypasses are also available at the enterprise level, providing complete visibility into the rulesets.
Learn more about enterprise rulesets in our documentation.
We look forward to seeing how you leverage these new capabilities to streamline your workflows and maintain high standards of code governance.
The new pull request merge method rule is now generally available using whatever method is suitable for your branches, such as ensuring that all changes are squashed when merging to the default branch while rebasing into feature branches. This simplifies your workflows, ensuring consistency across your branches.
The merge method rule is available for rulesets at the repository and organization level. You can use this rule to choose what merge methods are allowed on the targeted branches when merging pull requests from the user interface or APIs. You can choose between merge commit, squash, or rebase.
Learn more in our documentation and join the discussion within the GitHub Community.
Fine-grained Personal Access Tokens (PATs) have been used by millions of users to make tens of billions of API calls over the last two years in public preview. In that time, we’ve added requested features such as management APIs and webhooks, mandatory expiration policies, and usability improvements.
However, feedback has been clear on one item in particular – while fine-grained PATs solve a significant set of challenges in their current state, many organizations cannot fully adopt them due to the lack of support statements and the risk of breaking changes while they’re in public preview. Our goal at GitHub is to ensure that everyone can secure their workflows as best they can, which is why we’re graduating fine-grained PATs to a generally available (GA) state.
This update brings two major changes to PATs at GitHub. Most notably, fine-grained PATs are now enabled by default for all organizations on GitHub, unless that organization or enterprise explicitly disabled them during the preview. The PAT approval flow is also enabled by default, so developers must request organization owner approval in order to successfully use their fine-grained PAT against their organizations.
We’re also updating the release state for both fine-grained PATs and PAT expiration policies. These features are now fully supported by GitHub and adhere to the same breaking change policies as the rest of the product. While there are some scenarios where fine-grained PATs are not yet supported, your organization should be confident in suggesting, or even requiring, the use of these more secure tokens.
Administrators, auditors, and security teams can also look for improved auditability of PATs – the token_id is now included in all API calls and supported as a built-in filter in the audit logs. With this filter, you can now easily track the use of a token throughout your enterprise or organization.
Customers on GHES should expect these changes to arrive in version 3.17.
There are several scenarios where fine-grained PATs are not a suitable solution at this time. GitHub continues to invest in building more secure access patterns and will implement these capabilities over time. You can track our progress and goals on our public roadmap. The most notable scenarios are:
internal repositories in your enterprise, outside of a targeted organizationPackages and Checks APIsWe’re currently focused on implementing enterprise access for GitHub Apps and fine-grained PATs so that enterprise owners can reduce the over-permissioning of their current automation solutions. After that, we’ll continue to invest in this area with a goal of enabling organizations to eventually disable the use of PATs (Classic) for their resources.
To learn more about fine-grained PATs and how your organization can control them, see our documentation on managing your personal access tokens, and enforcing policies for PATs in your enterprise.
GitHub’s Payment Card Industry Data Security Standard (PCI DSS) v4.0 service provider Attestation of Compliance (AoC) as well as the corresponding shared responsibility matrix has been completed. This report is the first time GitHub has provided a PCI DSS service provider report for our customers. This enables customers to meet their own PCI DSS compliance needs using GitHub as part of their development environment.
Going forward, GitHub intends to provide this attestation of compliance each year.
If you’re an Enterprise customer and need to obtain copies of GitHub’s AoC or Shared Responsibility Matrix, please reach out to your account manager.
GitHub Enterprise users will now 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.
These changes are expected to come to GitHub Enterprise Server customers in release version 3.17.
To learn more about enterprise accounts, read our documentation.
GitHub Enterprise Server 3.16 enhances deployment efficiency, monitoring capabilities, code security, and policy management. Here are a few highlights in the 3.16 release:
ghe-config-apply have been improved. As a result, you may experience reduced downtime when ghe-config-apply is run.
When reviewing code security configurations, you can now filter repositories more easily with new options that sort by the status of specific GHAS features. For more details, see new advanced filters for code security configurations.
You can now apply code security configurations to archived repositories, simplifying rollouts and ensuring features like Dependabot, code scanning, and secret scanning are automatically reapplied if a repository is unarchived. Additionally, you can now create and manage code security settings at the enterprise level, reducing repetitive setup at the organization level. For more details, see enterprise-level code security configurations.
Monitor prevention metrics alongside detection and remediation metrics for Dependabot and GitHub Advanced Security features, including secret scanning and code scanning. This expanded visibility is now available in the enhanced security overview dashboard at both the organization and enterprise levels. For more information, see enhanced security overview dashboard.
Organization owners can now allow their users to set custom properties during repository creation. This ensures appropriate rules are enforced from the moment of creation and improves discoverability of new repositories. For more information, see custom properties.
Organization owners can now configure policies to restrict the usage of deploy keys across all the repositories of your organizations, giving you more control and greater security over your deploy keys. For more information, see enforcing a policy for deploy keys.
To learn more about GHES 3.16, check out the release notes or download it now. If you have any issues upgrading to version 3.16 or experience any issues using these new features, please contact our support team.
Join the community discussion to share your feedback and ask questions.
The general availability of enterprise-owned GitHub Apps brings several updates based on feedback from the public preview.
Most significantly, organizations and users can now transfer private visibility Apps to their enterprise, where they will become usable by the entire enterprise.
In addition, permission updates made to an enterprise-owned App are now automatically accepted by all of the organizations in the enterprise.
These updates allow enterprise owners to consolidate multiple per-organization Apps into a single registration that is managed efficiently at the enterprise level.
For enterprise-managed (EMU) users and organizations, both private and internal Apps can be transferred to the enterprise. Private Apps are those that only the owning account can use, while internal Apps are those that any organization and user in the enterprise can use. However, Enterprise Classic organizations and standard user accounts can only transfer private Apps, as internal Apps are not supported in Enterprise Classic.
At this time, internal is the only visibility setting allowed for enterprise-owned Apps, which means that only organizations in that enterprise can install it, and only users in the enterprise can authorize it. Any App that is transferred to an enterprise will be updated to be internal and uninstalled from the user account that owned it, if applicable.
To reduce abuse vectors, enterprises cannot transfer Apps to another enterprise, and organizations and users cannot transfer an App to an enterprise that they are not part of.
As in the preview, only an enterprise owner can manage Apps owned by the enterprise. However, we are actively working on App manager roles and permissions that will allow users and teams to manage specific Apps, as well as manage all of the Apps in an enterprise. These new fine-grained permissions will be introduced for both the enterprise and the organization—keep an eye out for these in the middle of the year.
For more information about enterprise-owned Apps, see our docs page. These updates will be available in GHES 3.17.
To share feedback, ask questions, and more, please join our discussion in the GitHub Community.
At GitHub, we believe that investing in the security of your codebases should be straightforward, cost-effective, and accessible for everyone. Today, we’re announcing changes to pricing plans and availability of GitHub Advanced Security (GHAS), aligning with our ongoing mission to help organizations of all sizes secure their code with the flexibility they seek.
Starting April 1, 2025, GitHub Advanced Security will be available as two standalone security products: GitHub Secret Protection and GitHub Code Security. In addition, these products will become available to GitHub Team plan customers for the first time.
New customers can purchase GitHub Secret Protection, which includes features that help detect and prevent secret leaks (e.g. secret scanning, AI-detected passwords, and push protection for secrets). Secret Protection will be available for $19 per month per active committer, with features including:
In addition, we’re launching a new scanning feature to help organizations understand their secret leak footprint across their GitHub perimeter. This feature will be free for GitHub Team and Enterprise organizations.
New customers will also be able to purchase Code Security, which detects and fixes vulnerabilities in your code before it reaches production. Code Security will be available for $30 per month per active committer with features including:
Starting April 1, 2025, customers on the GitHub Team plan can purchase Secret Protection and Code Security. These products will be available through a consumption-based, pay-as-you-go model (i.e., metered billing) to ensure security remains affordable, scalable, and accessible for all customers on GitHub.
Existing customers with plans managed with a GitHub or Microsoft sales account team can transition to the new GitHub Advanced Security plans at start time of renewal for renewal dates after April 1, 2025. Please contact your account team for further details. For existing self-serve customers, instructions on how to transition to the new GitHub Advanced Security plans will be announced over the coming months through GitHub’s roadmap and changelog.
GitHub Team customers can choose to purchase Secret Protection or Code Security from their organization settings pages starting April 1, 2025.
If you have any feedback, join the discussion in GitHub Community.
Scaling your GitHub usage just got easier! We are expanding our pay-as-you-go usage-based billing and licensing reporting interface to include GitHub Enterprise (GHE) and GitHub Advanced Security (GHAS) Server-only usage.
We announced pay-as-you-go billing for GHE and GHAS on August 1, 2024 to give customers flexible self-provisioning and pricing. Since then, enterprise accounts on github.com created on or after that date could generate a GitHub Enterprise Server key for the appropriate license count when license adjustments were needed. This required all users, including Server-only users, to be represented in the enterprise account’s user list on GitHub Enterprise Cloud.
Now, you can track and monitor your Server-only license usage for both Enterprise and Advanced Security as a separate line item on the Billing & Licensing > Licensing page.
Note that it will still be required to add all Server-only users to your GitHub Enterprise Cloud enterprise user list to account for their license usage and generate a license key with the appropriate license count. This update does not change this compliance requirement.
For existing customers who already have GHE or GHAS, your plan and existing billing method will remain as-is.
If you are interested in pay-as-you-go usage-based billing and have a GitHub account team, please connect with them to discuss whether switching to this model is an option for you.
Check out our documentation to learn more about usage-based billing for licenses.
Now it is easier to see how many of your historical CodeQL alerts received autofix suggestions and how many of those alerts were resolved across all the repositories in your organization.
Historical alerts are those found in your default and protected branches, indicating potential existing security issues in your code. You can stay informed about the progress of historical alert resolution and expediting this process as it is essential for accurately assessing your security risks.
The new “Alerts fixed with autofix suggestions” tile on the Security Overview provides you with the total number of fixed vulnerabilities compared to the total suggested autofixes for existing alerts. This will help you stay informed about the security trends in your organization.
Learn more about Copilot Autofix for CodeQL code scanning and security overview.
To leave feedback for Copilot Autofix for code scanning, join the discussion.
GitHub Enterprise Server 3.16 enhances deployment efficiency, monitoring capabilities, code security, and policy management. Here are a few highlights in the 3.16 release:
When reviewing code security configurations, you can now filter repositories more easily with new options that sort by the status of specific GHAS features. For more details, see new advanced filters for code security configurations.
You can now apply code security configurations to archived repositories, simplifying rollouts and ensuring features like Dependabot, code scanning, and secret scanning are automatically reapplied if a repository is unarchived. Additionally, you can now create and manage code security settings at the enterprise level, reducing repetitive setup at the organization level. For more details, see enterprise-level code security configurations.
Monitor prevention metrics alongside detection and remediation metrics for Dependabot and GitHub Advanced Security features, including secret scanning and code scanning. This expanded visibility is now available in the enhanced security overview dashboard at both organization and enterprise levels. For more information, see enhanced security overview dashboard.
Organization owners can now allow their users to set custom properties during repository creation. This ensures appropriate rules are enforced from the moment of creation and improves discoverability of new repositories. For more information, see custom properties.
Organization owners can now configure policies to restrict the usage of deploy keys across all the repositories of your organizations, giving you more control and greater security over your deploy keys. For more information, see enforcing a policy for deploy keys.
Release candidates are a way for you to try the latest features early, and they help us gather feedback to ensure the release works in your environment. They should be tested on non-production environments. Read more about the release candidate process.
To learn more about GHES 3.16, check out release notes, or download the 3.16 release candidate now.
If you have any feedback or questions about the release candidate, please contact our support team.
As previously announced, Enterprise Managed Users (EMUs) no longer have their emails automatically verified. This helps prevent any accidental data leaks by third party GitHub Apps and OAuth applications that may have taken a dependency on the email as the primary identifier. In January 2025, we also updated the /user/emails REST endpoint to return a placeholder email address with the enterprise’s shortcode appended (e.g. email+shortcode@domain.com) until the EMU user has verified their email address.
While unverified emails may not affect most of your actions on GitHub, some GitHub Apps and OAuth apps may not handle this placeholder email properly. This may prevent you from accessing those apps or result in incomplete data being displayed. These apps may also prompt you to verify your email on GitHub before proceeding.
For example, GitHub Desktop might incorrectly prompt users to update their email in their Git config to their placeholder email. However, updating your Git config email could lead to commit misattribution as opposed to fixing it. While this experience is updated in GitHub Desktop v3.4.17-beta3, we recommend users verify their email address in response to such prompts.
Learn more about how to verify your email address.
App developers should also review our best practices for OAuth and GitHub App implementation to avoid disrupting the user experience in your apps.
Copilot Autofix suggestions for code scanning alerts can now be edited and validated using Copilot Workspace for pull requests.
With this, GitHub Advanced Security users can:
All GitHub Advanced Security users can use this feature in private repositories on GitHub.com. A Copilot license is not required.
To learn more about code scanning alerts and Copilot Autofix, see About Copilot Autofix for CodeQL code scanning. If you have feedback regarding Copilot Autofix for code scanning, please join the discussion here.