From 01f98151555d524debaee55c6c0256cf454087db Mon Sep 17 00:00:00 2001 From: docs-bot <77750099+docs-bot@users.noreply.github.com> Date: Fri, 16 Jan 2026 02:24:25 -0800 Subject: [PATCH 1/4] Update docs changelog (for PR #59040) (#59133) Co-authored-by: github-actions[bot] Co-authored-by: hubwriter Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> --- CHANGELOG.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index ae6b8f338908..3e1eb2d59c55 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1,5 +1,13 @@ # Docs changelog +**13 January 2026** + +We've added a new reference article to clarify which of the various types of custom instructions for Copilot are supported by Copilot Chat, Copilot coding agent, and Copilot code review in GitHub.com, Visual Studio Code, Visual Studio, JetBrains IDEs, Eclipse, Xcode, and Copilot CLI. + +[Support for different types of custom instructions](https://docs.github.com/copilot/reference/custom-instructions-support) + +
+ **8 January 2026** We've added information about permissions to the article [Using GitHub Copilot CLI](https://docs.github.com/copilot/how-tos/use-copilot-agents/use-copilot-cli#permissions). From 8cdb0aa17af9e5173ce7ec30341537130ba3280f Mon Sep 17 00:00:00 2001 From: Isaac Brown <101839405+isaacmbrown@users.noreply.github.com> Date: Fri, 16 Jan 2026 10:38:49 +0000 Subject: [PATCH 2/4] New and revised content for offboarding users in an enterprise (#58625) Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Co-authored-by: Laura Coursen Co-authored-by: Stacy Carter --- .../identity-and-access-management/index.md | 1 + .../user-offboarding.md | 62 +++++++++++++++++++ .../removing-a-member-from-your-enterprise.md | 41 ++++++++---- ...emoving-a-member-from-your-organization.md | 50 ++++++++++----- 4 files changed, 125 insertions(+), 29 deletions(-) create mode 100644 content/admin/concepts/identity-and-access-management/user-offboarding.md diff --git a/content/admin/concepts/identity-and-access-management/index.md b/content/admin/concepts/identity-and-access-management/index.md index d1d256ee3715..75e8de8abc1c 100644 --- a/content/admin/concepts/identity-and-access-management/index.md +++ b/content/admin/concepts/identity-and-access-management/index.md @@ -10,6 +10,7 @@ topics: children: - /identity-and-access-management-fundamentals - /enterprise-managed-users + - /user-offboarding contentType: concepts --- diff --git a/content/admin/concepts/identity-and-access-management/user-offboarding.md b/content/admin/concepts/identity-and-access-management/user-offboarding.md new file mode 100644 index 000000000000..8192af5e610f --- /dev/null +++ b/content/admin/concepts/identity-and-access-management/user-offboarding.md @@ -0,0 +1,62 @@ +--- +title: About user offboarding on {% data variables.product.prodname_ghe_cloud %} +shortTitle: User offboarding +intro: 'Manage access with confidence by understanding the recommended approach for offboarding users.' +versions: + ghec: '*' +contentType: concepts +topics: + - Accounts + - Authentication + - Enterprise + - Identity + - SSO +--- + +## How should I offboard users? + +The method for offboarding a user depends on your enterprise type: + +* **Personal accounts**: Remove the user from the enterprise account using the {% data variables.product.github %} UI or API. + * Outside collaborators are an exception to this process. They cannot be removed in the enterprise settings, and must be removed from each repository instead. +* **{% data variables.product.prodname_emus %}**: Suspend the user's account by removing the user from the {% data variables.product.github %} application in your identity provider. + * The user will show as suspended on your enterprise's "People" page. + * It is **not** possible to remove a {% data variables.enterprise.prodname_managed_user %} from the enterprise completely. + +For instructions, see [AUTOTITLE](/admin/managing-accounts-and-repositories/managing-users-in-your-enterprise/removing-a-member-from-your-enterprise). + +## What happens when a user is offboarded? + +When you offboard a user by following the instructions linked above: + +* The offboarded user loses access to private and internal resources in your enterprise and organizations. +* The user's {% data variables.product.pat_generic_plural %}, SSH keys, and app authorizations can no longer be used to access your enterprise's and organizations' resources. Access to your resources is restored if the user is added back to the enterprise and relevant organizations. +* The user stops consuming licenses granted from your enterprise, including {% data variables.product.prodname_enterprise %} and {% data variables.product.prodname_copilot %} licenses. This change may not be reflected on your bill until the next billing cycle. +* If you use {% data variables.product.prodname_emus %}, the user will no longer be able to sign in to their {% data variables.enterprise.prodname_managed_user %}. +* If you use an enterprise with personal accounts, the user will still be able to sign in to their account and access other resources on {% data variables.product.github %}, even if you have enabled SAML SSO for your enterprise or organizations. This is because SSO only applies to your enterprise- or organization-owned resources. +* The user's commits, issues, pull requests, comments, and so on are retained in organization-owned repositories. However, the user's username is obfuscated if you use {% data variables.product.prodname_emus %}. + +For {% data variables.product.prodname_emus %}, you will find a more exhaustive list of effects of offboarding in [AUTOTITLE](/admin/managing-iam/provisioning-user-accounts-with-scim/deprovisioning-and-reinstating-users). + +## What about removing a user from all organizations? + +Historically, some enterprises' offboarding processes have relied on removing a user from all organizations in the enterprise. However, in many cases, this approach is **not** sufficient for fully offboarding a user. + +### When is a user removed from the enterprise? + +If a user loses access to all organizations in an enterprise, the user is also removed from the enterprise account if **all** of the following things are true: + +* You use an enterprise with **personal accounts**. +* Your enterprise has **disabled** the policy described in [AUTOTITLE](/admin/enforcing-policies/enforcing-policies-for-your-enterprise/control-offboarding). +* The user does **not** have the enterprise owner or enterprise billing manager role. + +### What happens if a user remains in the enterprise? + +In **any** other situation, a user who loses access to all organizations remains in the enterprise. + +* If the user has the enterprise owner or enterprise billing manager role, they remain in the enterprise with this role. +* If the user doesn't have one of those roles, the user becomes an unaffiliated user. + +Users without organization membership cannot access internal repositories in the enterprise. They also do not consume a {% data variables.product.prodname_enterprise %} license, unless they meet another criterion listed in [AUTOTITLE](/billing/reference/github-license-users#organizations-on-github-enterprise-cloud). However, they keep other privileges including enterprise roles and {% data variables.product.prodname_copilot %} licenses granted directly from the enterprise. + +For more information, see [AUTOTITLE](/admin/managing-accounts-and-repositories/managing-roles-in-your-enterprise/abilities-of-roles). diff --git a/content/admin/managing-accounts-and-repositories/managing-users-in-your-enterprise/removing-a-member-from-your-enterprise.md b/content/admin/managing-accounts-and-repositories/managing-users-in-your-enterprise/removing-a-member-from-your-enterprise.md index d635e25cf7cb..122e8300ff52 100644 --- a/content/admin/managing-accounts-and-repositories/managing-users-in-your-enterprise/removing-a-member-from-your-enterprise.md +++ b/content/admin/managing-accounts-and-repositories/managing-users-in-your-enterprise/removing-a-member-from-your-enterprise.md @@ -1,7 +1,7 @@ --- title: Removing a member from your enterprise -intro: You can remove an enterprise member from an enterprise. -permissions: Enterprise owners can remove an enterprise member from an enterprise. +intro: Offboard users from an enterprise by following the recommended approach for your enterprise type. +permissions: Enterprise owners or IdP administrators versions: feature: remove-enterprise-members type: how_to @@ -12,23 +12,38 @@ redirect_from: - /admin/user-management/managing-users-in-your-enterprise/removing-a-member-from-your-enterprise --- -## About removal of enterprise members +The recommended offboarding approach for your enterprise depends on whether you use personal accounts or {% data variables.product.prodname_emus %}. To learn more about the effects of offboarding users, see [AUTOTITLE](/admin/concepts/identity-and-access-management/user-offboarding). -If your enterprise does not use {% data variables.product.prodname_emus %}, you can remove an enterprise member from your enterprise on {% data variables.product.prodname_dotcom_the_website %}. When you remove a member from your enterprise, the member is removed from all organizations owned by your enterprise and loses access to any {% data variables.copilot.copilot_business_short %} licenses assigned through those organizations. Removing a member from your enterprise also removes any of the member's administrative roles, such as the owner or billing manager roles. See [AUTOTITLE](/admin/user-management/managing-users-in-your-enterprise/roles-in-an-enterprise). +## Removing a member from an enterprise with personal accounts -If the enterprise member you're removing is the last owner of an organization owned by your enterprise, you will become an owner of that organization. - -If your enterprise or any of the organizations owned by your enterprise uses an identity provider (IdP) to manage organization membership, the member may be added back to the organization by the IdP. Make sure to also make any necessary changes in your IdP. +When you remove a member from your enterprise, the member is removed from all organizations owned by your enterprise and loses privileges granted through the enterprise, such as roles or licenses. -If your enterprise does use {% data variables.product.prodname_emus %}, you must remove the enterprise members through your identity provider (IdP) and the SCIM integration instead. See [AUTOTITLE](/admin/identity-and-access-management/using-enterprise-managed-users-for-iam/about-enterprise-managed-users#about-organization-membership-management). - -## Removing a member from your enterprise +If the enterprise member you're removing is the last owner of an organization owned by your enterprise, you will become an owner of that organization. -> [!NOTE] -> If an enterprise member uses only {% data variables.product.prodname_ghe_server %}, and not {% data variables.product.prodname_ghe_cloud %}, you cannot remove the enterprise member this way. +>[!TIP] For automated offboarding, you can also remove users with the GraphQL API. See [AUTOTITLE](/graphql/reference/mutations#removeenterprisemember). -{% data reusables.enterprise-accounts.access-enterprise %} +{% data reusables.enterprise-accounts.access-enterprise-personal-accounts %} {% data reusables.enterprise-accounts.people-tab %} 1. To the right of the person you want to remove, select the {% octicon "kebab-horizontal" aria-label="Member settings" %} dropdown menu and click **Remove from enterprise**. ![Screenshot of a user in the list of enterprise members. A dropdown menu, labeled with a kebab icon, is highlighted with an orange outline.](/assets/images/help/business-accounts/remove-member.png) + +1. If your enterprise uses SAML SSO, or if any of your organizations use SAML and SCIM provisioning, **remove the user's access to {% data variables.product.github %} apps on your identity provider**. A user may be assigned access directly or via an IdP group assigned to the app: make sure to remove the user from both. For organizations with SCIM provisioning enabled, this should trigger a SCIM deprovisioning call, which ensures that the user's associated SAML and SCIM identities are fully removed from the organization. + + This is a good practice for security, and it also helps ensure that users cannot rejoin the organization using the SAML endpoint when SAML is configured at the organization level (see [AUTOTITLE](/organizations/managing-saml-single-sign-on-for-your-organization/about-identity-and-access-management-with-saml-single-sign-on#adding-members-to-an-organization-using-saml-sso)). + +If the user is still listed as an enterprise member, this may be because the user is a member of a {% data variables.product.prodname_ghe_server %} instance that is linked to your enterprise via {% data variables.product.prodname_github_connect %}. You will need to remove this user from the {% data variables.product.prodname_ghe_server %} settings. + +## Suspending a user with {% data variables.product.prodname_emus %} + +With {% data variables.product.prodname_emus %}, including all enterprises on {% data variables.enterprise.data_residency_site %}, you manage user access from your identity provider (IdP). + +To offboard a user, you will suspend their account rather than removing them from the enterprise completely. + +1. Trigger a deprovisioning call for the user. For more information about the types of deprovisioning and the actions that trigger it for different integrations, see [AUTOTITLE](/admin/managing-iam/provisioning-user-accounts-with-scim/deprovisioning-and-reinstating-users#triggers-of-soft-deprovisioning). +1. Check if the user's organization membership is managed directly or managed by IdP groups. See [AUTOTITLE](/admin/managing-accounts-and-repositories/managing-users-in-your-enterprise/viewing-people-in-your-enterprise#filtering-by-member-type-in-an-enterprise-with-managed-users). +1. If the user's organization membership is managed directly, remove the user manually from all organizations. See [AUTOTITLE](/organizations/managing-membership-in-your-organization/removing-a-member-from-your-organization). + +## Removing an outside collaborator + +In enterprises that use personal accounts, you cannot remove outside collaborators using the enterprise settings. However, an organization owner can remove an outside collaborator from all repositories in an organization. See [AUTOTITLE](/organizations/managing-user-access-to-your-organizations-repositories/managing-outside-collaborators/removing-an-outside-collaborator-from-an-organization-repository). diff --git a/content/organizations/managing-membership-in-your-organization/removing-a-member-from-your-organization.md b/content/organizations/managing-membership-in-your-organization/removing-a-member-from-your-organization.md index 1b84013b47ac..245e23882f32 100644 --- a/content/organizations/managing-membership-in-your-organization/removing-a-member-from-your-organization.md +++ b/content/organizations/managing-membership-in-your-organization/removing-a-member-from-your-organization.md @@ -18,37 +18,55 @@ shortTitle: Remove a member permissions: Organization owners can remove members from an organization. --- +## 1. Understand the effects of removing a member + +When you remove members from an organization: + {% ifversion fpt or ghec %} -> [!WARNING] -> When you remove members from an organization: -> * The paid license count does not automatically downgrade. To pay for fewer licenses after removing users from your organization, follow the steps in [AUTOTITLE](/billing/managing-the-plan-for-your-github-account/downgrading-your-accounts-plan). -> * Removed members will lose access to private forks of your organization's private repositories, but they may still have local copies. However, they cannot sync local copies with your organization's repositories. Their private forks can be restored if the user is [reinstated as an organization member](/organizations/managing-membership-in-your-organization/reinstating-a-former-member-of-your-organization) within three months of being removed from the organization. Ultimately, you are responsible for ensuring that people who have lost access to a repository delete any confidential information or intellectual property. -> * When private repositories are forked to other organizations, those organizations are able to control access to the fork network. This means users may retain access to the forks even after losing access to the original organization because they will still have explicit access via a fork. -{%- ifversion ghec %} -> * Removed members will also lose access to private forks of your organization's internal repositories, if the removed member is not a member of any other organization owned by the same enterprise account. For more information, see [AUTOTITLE](/admin/overview/about-enterprise-accounts). -{%- endif %} -> * Any organization invitations sent by a removed member, that have not been accepted, are canceled and will not be accessible. +* If you use volume license billing, the paid license count does not automatically downgrade. To pay for fewer licenses after removing users from your organization, follow the steps in [AUTOTITLE](/billing/managing-the-plan-for-your-github-account/downgrading-your-accounts-plan). +* Removed members will lose access to private forks of your organization's private repositories, but they may still have local copies. However, they cannot sync local copies with your organization's repositories. Ultimately, you are responsible for ensuring that people who have lost access to a repository delete any confidential information or intellectual property. +* When private repositories are forked to other organizations, those organizations are able to control access to the fork network. This means users may retain access to the forks even after losing access to the original organization because they will still have explicit access via a fork. +* Removed members will also lose access to private forks of your organization's internal repositories, if the removed member is not a member of any other organization owned by the same enterprise account. +* Any organization invitations sent by a removed member, that have not been accepted, are canceled and will not be accessible. +* If the organization is part of an enterprise on {% data variables.product.prodname_ghe_cloud %} and the user is still a member of at least one other organization in the enterprise, the user will retain access to repositories with internal visibility in the organization that they are removed from. +* If the organization is part of an enterprise on {% data variables.product.prodname_ghe_cloud %} and the user is no longer a member of any organizations in it, the user will either become an enterprise unaffiliated member or be removed from the enterprise, depending on your settings. See [AUTOTITLE](/enterprise-cloud@latest/admin/concepts/identity-and-access-management/user-offboarding). +* When you remove a user from your organization, their membership data is saved for three months. You can restore their data, or any private forks they owned of your organization's repositories, if you invite the user to rejoin the organization within that time frame. For more information, see [AUTOTITLE](/organizations/managing-membership-in-your-organization/reinstating-a-former-member-of-your-organization). {% else %} -> [!WARNING] -> When you remove members from an organization: -> * Removed members will lose access to private forks of your organization's private repositories, but may still have local copies. However, they cannot sync local copies with your organization's repositories. Their private forks can be restored if the user is [reinstated as an organization member](/organizations/managing-membership-in-your-organization/reinstating-a-former-member-of-your-organization) within three months of being removed from the organization. Ultimately, you are responsible for ensuring that people who have lost access to a repository delete any confidential information or intellectual property. -> * Removed members will also lose access to private forks of your organization's internal repositories, if the removed member is not a member of any other organization in your enterprise. -> * Any organization invitations sent by the removed user, that have not been accepted, are canceled and will not be accessible. +* Removed members will lose access to private forks of your organization's private repositories, but may still have local copies. However, they cannot sync local copies with your organization's repositories. Their private forks can be restored if the user is [reinstated as an organization member](/organizations/managing-membership-in-your-organization/reinstating-a-former-member-of-your-organization) within three months of being removed from the organization. Ultimately, you are responsible for ensuring that people who have lost access to a repository delete any confidential information or intellectual property. +* Removed members will also lose access to private forks of your organization's internal repositories, if the removed member is not a member of any other organization in your enterprise. +* Any organization invitations sent by the removed user, that have not been accepted, are canceled and will not be accessible. +* When you remove a user from your organization, their membership data is saved for three months. You can restore their data, or any private forks they owned of your organization's repositories, if you invite the user to rejoin the organization within that time frame. For more information, see [AUTOTITLE](/organizations/managing-membership-in-your-organization/reinstating-a-former-member-of-your-organization). {% endif %} {% ifversion fpt or ghec %} +## 2. Share best practices + To help the person you're removing from your organization transition and help ensure they delete confidential information or intellectual property, we recommend sharing a checklist of best practices for leaving your organization. For an example, see [AUTOTITLE](/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-your-personal-account/best-practices-for-leaving-your-company). +## 3. Understand how you manage organization membership (enterprises only) + +If the organization is on {% data variables.product.prodname_ghe_cloud %}, you may manage organization membership from an identity provider. + +If you have an enterprise with personal accounts, check if you are using SCIM provisioning in the organization to manage membership. If you are, remove the user from the {% data variables.product.github %} application in your IdP and from any IdP groups that are linked to teams with access to the organization. See [AUTOTITLE](/enterprise-cloud@latest/organizations/managing-saml-single-sign-on-for-your-organization/about-scim-for-organizations). + +If you use {% data variables.product.prodname_emus %}, check the "member type" of the user to see if their membership is managed manually or by IdP groups. If the user is "Managed by IdP groups", remove the user from any IdP groups that are linked to teams with access to the organization. See [AUTOTITLE](/enterprise-cloud@latest/admin/managing-accounts-and-repositories/managing-users-in-your-enterprise/viewing-people-in-your-enterprise#filtering-by-member-type-in-an-enterprise-with-managed-users). + +{% else %} + +## 2. Understand how you manage membership + +If you have enabled user provisioning with SCIM on your {% data variables.product.prodname_ghe_server %} instance, check the member type of the user. If the user is "Managed by IdP groups", remove the user from any IdP groups that are linked to teams with access to the organization. See [AUTOTITLE](/admin/managing-accounts-and-repositories/managing-users-in-your-enterprise/viewing-people-in-your-enterprise#filtering-by-account-type-saml-and-scim). + {% endif %} -{% data reusables.organizations.data_saved_for_reinstating_a_former_org_member %} +## {% ifversion fpt or ghec %}4.{% else %}3.{% endif %} Remove the user manually -## Revoking the user's membership +If the user's organization membership is **not** managed with by a SCIM integration, you can remove the user from an organization manually. {% data reusables.profile.access_org %} {% data reusables.user-settings.access_org %} From 5bc3533e93515313d5bd20bcbc6aa568381ee298 Mon Sep 17 00:00:00 2001 From: Pallavi <96553709+pallsama@users.noreply.github.com> Date: Fri, 16 Jan 2026 03:05:24 -0800 Subject: [PATCH 3/4] Add documentation for multiple data disks (#59023) Co-authored-by: Benedict Ng Co-authored-by: Isaac Brown <101839405+isaacmbrown@users.noreply.github.com> Co-authored-by: isaacmbrown --- .../index.md | 1 + .../configuring-multiple-data-disks.md | 222 ++++++++++++++++++ .../multiple-data-disks/index.md | 10 + 3 files changed, 233 insertions(+) create mode 100644 content/admin/monitoring-and-managing-your-instance/multiple-data-disks/configuring-multiple-data-disks.md create mode 100644 content/admin/monitoring-and-managing-your-instance/multiple-data-disks/index.md diff --git a/content/admin/monitoring-and-managing-your-instance/index.md b/content/admin/monitoring-and-managing-your-instance/index.md index 0bafdd26d4b8..59d00719c48a 100644 --- a/content/admin/monitoring-and-managing-your-instance/index.md +++ b/content/admin/monitoring-and-managing-your-instance/index.md @@ -15,5 +15,6 @@ children: - /configuring-clustering - /configuring-high-availability - /caching-repositories + - /multiple-data-disks shortTitle: 'Monitor and manage your instance' --- diff --git a/content/admin/monitoring-and-managing-your-instance/multiple-data-disks/configuring-multiple-data-disks.md b/content/admin/monitoring-and-managing-your-instance/multiple-data-disks/configuring-multiple-data-disks.md new file mode 100644 index 000000000000..b15f3bccd687 --- /dev/null +++ b/content/admin/monitoring-and-managing-your-instance/multiple-data-disks/configuring-multiple-data-disks.md @@ -0,0 +1,222 @@ +--- +title: Configuring multiple data disks +product: '{% data variables.product.prodname_ghe_server %}' +intro: 'You can configure additional data disks and use them to host MySQL and repositories data.' +versions: + ghes: '>= 3.19' +type: overview +topics: + - Enterprise +--- + +> [!NOTE] +> The ability to configure and use multiple data disks is in {% data variables.release-phases.public_preview %} and subject to change. We would love to hear your feedback on the preview. You can share it with your customer success team, or leave a comment in the [community discussion post](https://github.com/orgs/community/discussions/181173). Our preferred option is sharing your feedback with your customer success team. + +## Why introduce more disks to the GHES instance? + +* Improved resource distribution: + * Different services have unique disk requirements. + * MySQL is mostly latency and IOPS sensitive. + * Some resources (such as repositories) don't benefit as much from expensive block storage. +* Maximized VM limits: + * A single disk is often not able to max out the limitations of an instance. + * From a cost perspective, it is usually not feasible or worthwhile to run everything on the most expensive or fastest storage. +* Clearer separation between resource allocation and services: + * Resources can be allocated in a targeted way, preventing critical services from being starved. +* Scaling: + * Customers on both standalone and high-availability topologies can scale out as needed. + +## Constraints + +* Multi-data disks are only supported on Standalone and High Availability (HA) topologies. +* Once multiple data disks are configured in a deployment, this change cannot be undone for that deployment. +* Setting up multi-data disks and migrating data typically requires some downtime. + * You can minimize this by configuring a replica with multi-data disks, replicating data from the primary, and then failing over to the replica. + * If you are adding multi-data disks directly to the primary, expect a much longer downtime. +* During the public preview, multi-data disks should be used only in non-production environments. +* It is not recommended to migrate MySQL and repositories to the same disk. +* Currently, only MySQL and repositories can be migrated to additional disks. + +## Resource recommendations + +If you add disks that are as fast or faster than your current ones, you should see improved performance. Storage devices are typically measured by IOPS (Input/Output Operations Per Second), throughput, and latency. For MySQL, we recommend using a disk with lower latency and higher IOPS than your existing data disk. For repositories, choose a disk with higher IOPS and throughput than your current data disk. + +In high availability setups, it is best to use multi-data disks on both the primary and all replicas. Mixing configurations, where the primary has multi-data disks but the replica does not, is not recommended. + +## Setting up multiple data disks and data paths + +### Prerequisites + +* We recommend taking a recent backup of your data before getting started. +* Create a test environment to try the feature. + * During the public preview, we recommend **only** using the feature in a test environment. + * Once the feature becomes generally available, we recommend testing the feature in a non-production environment before using it in production. + +### Instructions + +1. You can perform fresh installation of GHES or use an existing GHES instance. It should have the data disk configured at `/data/user`. + +1. Once `/data/user` is set up, add additional block storage devices to the instance. + + Currently, `ghe-storage-find` chooses the first block storage for setting up `/data/user` based on the alphabetical order of the block storage path. This happens on the first boot of the GHES appliance. + + To have more control over which disk is used for `/data/user`, it is better to complete the initialization process with only one disk attached initially. + +1. Initialize the multi-disk setup using the new block storage devices. To initialize multi-disk support, run `ghe-storage-multi-disk init`. On every reboot, the `ghe-multi-disk.service` will automatically remount the existing data disks at the correct paths. + + ``` shell copy + /usr/local/share/enterprise/ghe-storage-multi-disk init /dev/nvme2n1 db + ``` + + ``` shell copy + /usr/local/share/enterprise/ghe-storage-multi-disk init /dev/nvme3n1 git + ``` + + Please note that `/dev/nvme2n1` and `/dev/nvme3n1` are example paths only. They might not match the paths on your system. Similarly, `db` and `git` are examples. You may choose different names. + +1. Switch to maintenance mode. + + ``` shell copy + gh es maintenance set --enabled true + ``` + +1. Migrate your desired data paths. + + To migrate MySQL: + + ``` shell copy + /usr/local/share/enterprise/ghe-storage-migrate-mysql db + ``` + + To migrate repositories: + + ``` shell copy + /usr/local/share/enterprise/ghe-storage-migrate-repositories git + ``` + +1. Exit maintenance mode. + + ``` shell copy + gh es maintenance set --enabled false + ``` + +1. Test the instance for a period of time to make sure everything works as expected. +1. **Only after sufficient testing**, remove `/data/user/mysql-backup` and `/data/user/repositories-backup`. + + Keeping these folders during testing allows you to roll back in an emergency. After sufficient testing, you should remove those backup folders to free up space. + +### Guidance for high availability configurations + +The following guidance helps reduce downtime in high availability (HA) topologies. If you are using a standalone topology, we do not have similar additional guidance at this time. + +For HA topologies, the best approach is to stand up a new replica with multiple data disks configured, replicate data from the primary, and then promote the replica to primary. Migrating data to additional disks on the current primary is not recommended, as this process can lead to significant downtime. + +1. Set up a new HA replica with better disks. + + To plan for the data migration, use `du -sh /data/user/mysql` and `du -sh /data/user/repositories` on the primary to calculate disk space requirements for the new replica. + +1. Set up multi-disk on the new HA replica. +1. Allow the HA primary to replicate to the replica. +1. Follow the failover sequence as documented in [AUTOTITLE](/admin/monitoring-and-managing-your-instance/configuring-high-availability/initiating-a-failover-to-your-replica-appliance). + +While the replication process can take a long time, the advantage is that it runs in the background, so the actual disruption from maintenance mode is dramatically reduced. + +## Example: configuring two additional disks + +This example demonstrates the required commands and outputs for disk initialization and data migration. Specifically, `/data/user/mysql` is migrated to `/data/multi-disk/db/mysql`, and `/data/user/repositories` is migrated to `/data/multi-disk/git/repositories`. + +```shell +admin@ghe-test-primary:~$ /usr/local/share/enterprise/ghe-storage-multi-disk status +Checking system status... + +admin@ghe-test-primary:~$ /usr/local/share/enterprise/ghe-storage-multi-disk info +Dumping disk status and information... + +admin@ghe-test-primary:~$ /usr/local/share/enterprise/ghe-storage-multi-disk init /dev/nvme2n1 db +Starting initialization sequence for /dev/nvme2n1 at /data/multi-disk/db... + +admin@ghe-test-primary:~$ /usr/local/share/enterprise/ghe-storage-multi-disk init /dev/nvme3n1 git +Starting initialization sequence for /dev/nvme3n1 at /data/multi-disk/git... + +admin@ghe-test-primary:~$ /usr/local/share/enterprise/ghe-storage-migrate-mysql db +Start mysql migration to /data/multi-disk/db... +Running checks.. +Error: maintenance mode must be enabled before being able to proceed. +ERROR: Last Command: return 1 LINE: 36 ghe-storage-migrate-mysql +Script exited with exit code: 1 + +admin@ghe-test-primary:~$ ghe-maintenance -s + +admin@ghe-test-primary:~$ /usr/local/share/enterprise/ghe-storage-migrate-mysql db +Start repository migration to /data/multi-disk/db... +Success: /data/user/mysql moved to /data/multi-disk/db/mysql +Script exited with exit code: 0 + +admin@ghe-test-primary:~$ /usr/local/share/enterprise/ghe-storage-migrate-repositories git +Start repository migration to /data/multi-disk/git... +Success: /data/user/repositories moved to /data/multi-disk/git +Script exited with exit code: 0 + +admin@ghe-test-primary:~$ ghe-maintenance -u + +admin@ghe-test-primary:~$ /usr/local/share/enterprise/ghe-storage-multi-disk status +Checking system status... +/data/user/mysql -> /data/multi-disk/db/mysql is correctly symlinked. +Repositories migration was detected... +/data/user/repositories -> /data/multi-disk/git/repositories is correctly symlinked. + +admin@ghe-test-primary:~$ /usr/local/share/enterprise/ghe-storage-multi-disk info +Dumping disk status and information... +# Multi disk configuration /data/user/multi-disk-config: +DISK_DB="lvm" +DISK_GIT="lvm" +MYSQL_MIGRATION_PATH="/data/multi-disk/db/mysql" +REPOSITORIES_MIGRATION_PATH="/data/multi-disk/git/repositories" + +admin@ghe-test-primary:~$ ls /var/log/multi-disk/ +ghe-storage-init-db.log ghe-storage-init-git.log ghe-storage-migrate-mysql.log ghe-storage-migrate-repositories.log + +``` + +## Hygiene checks + +Both `/usr/local/share/enterprise/ghe-storage-multi-disk status` and `/usr/local/share/enterprise/ghe-storage-multi-disk info` are helpful for checking your setup. + +To view the current multi-disk configuration, use: + +```shell +$ cat /data/user/multi-disk-config +DISK_DB="lvm" +DISK_GIT="lvm" +MYSQL_MIGRATION_PATH="/data/multi-disk/db/mysql" +REPOSITORIES_MIGRATION_PATH="/data/multi-disk/git/repositories" +``` + +To review multi-disk logs, including disk initialization and migration events, run: + +```shell +$ ls -l /var/log/multi-disk/ +total 56 +-rw-r--r-- 1 root root 2398 Mar 3 13:22 ghe-storage-init-db.log +-rw-r--r-- 1 root root 2497 Mar 3 13:23 ghe-storage-init-git.log +-rw-r--r-- 1 root root 2201 Mar 3 13:28 ghe-storage-migrate-mysql.log +-rw-r--r-- 1 root root 37296 Mar 3 13:30 ghe-storage-migrate-repositories.log +``` + +## Commands for managing multiple disks + +These commands make it possible to add multiple disks and migrate specific services or folder paths to those disks. The original folder paths are maintained and kept static. Other services are unaware that anything has changed. The static folder paths are symlinked to the newly migrated paths. + +The commands include: + +* ghe-storage-multi-disk + * `status` + * `init` + * `info` + * `mount` + * `start-services` (only recommended for debugging) + * `stop-services` (only recommended for debugging) +* ghe-storage-migrate-repositories + * Migrates `/data/user/repositories` to any disk path created using `ghe-storage-multi-disk init`. +* ghe-storage-migrate-mysql + * Migrates `/data/user/mysql` to any disk path created using `ghe-storage-multi-disk init`. diff --git a/content/admin/monitoring-and-managing-your-instance/multiple-data-disks/index.md b/content/admin/monitoring-and-managing-your-instance/multiple-data-disks/index.md new file mode 100644 index 000000000000..f96a3755812c --- /dev/null +++ b/content/admin/monitoring-and-managing-your-instance/multiple-data-disks/index.md @@ -0,0 +1,10 @@ +--- +title: Multiple data disks +intro: 'You can configure additional data disks and use them to host MySQL and repositories data.' +versions: + ghes: '>= 3.19' +topics: + - Enterprise +children: + - /configuring-multiple-data-disks +--- From ca67b2dbc584129d5b2a704de84e17dfa3c8f359 Mon Sep 17 00:00:00 2001 From: docs-bot <77750099+docs-bot@users.noreply.github.com> Date: Fri, 16 Jan 2026 03:52:23 -0800 Subject: [PATCH 4/4] Update docs changelog (for PR #58625) (#59190) Co-authored-by: github-actions[bot] Co-authored-by: Isaac Brown <101839405+isaacmbrown@users.noreply.github.com> Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> --- CHANGELOG.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index 3e1eb2d59c55..b5d45886da75 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1,5 +1,13 @@ # Docs changelog +**16 January 2026** + +We published [About user offboarding on GitHub Enterprise Cloud](https://docs.github.com/en/enterprise-cloud@latest/admin/concepts/identity-and-access-management/user-offboarding) to give enterprise customers clear guidance about offboarding processes. The article covers recommended offboarding methods, the effects of offboarding, and what happens when a user is removed from all organizations in an enterprise. + +We also updated [Removing a member from your enterprise](https://docs.github.com/en/enterprise-cloud@latest/admin/managing-accounts-and-repositories/managing-users-in-your-enterprise/removing-a-member-from-your-enterprise) and [Removing a member from your organization](https://docs.github.com/en/enterprise-cloud@latest/organizations/managing-membership-in-your-organization/removing-a-member-from-your-organization) to include instructions for enterprises that use Enterprise Managed Users or SCIM for organizations. + +
+ **13 January 2026** We've added a new reference article to clarify which of the various types of custom instructions for Copilot are supported by Copilot Chat, Copilot coding agent, and Copilot code review in GitHub.com, Visual Studio Code, Visual Studio, JetBrains IDEs, Eclipse, Xcode, and Copilot CLI.