This version of GitHub Enterprise was discontinued on 2023-03-15. No patch releases will be made, even for critical security issues. For better performance, improved security, and new features, upgrade to the latest version of GitHub Enterprise. For help with the upgrade, contact GitHub Enterprise support.
The cluster topology for GitHub Enterprise Server provides horizontal scaling for environments with tens of thousands of developers.
GitHub determines eligibility for clustering, and must enable the configuration for your instance's license. Clustering requires careful planning and additional administrative overhead. For more information, see "About clustering."
The cluster topology for GitHub Enterprise Server is designed to support tens of thousands of users where other topologies would experience resource exhaustion. In a cluster, the instance's services scale horizontally across multiple nodes.
Differences between clustering and high availability (HA)
Learn about the differences between deployment topologies for the virtual machines (VMs) that comprise a GitHub Enterprise Server instance.
About cluster nodes
In a GitHub Enterprise Server cluster, nodes are individual virtual machines (VMs) running the GitHub Enterprise Server software that comprise the instance. Each node runs a set of services.
Cluster network configuration
A GitHub Enterprise Server cluster requires proper DNS name resolution, load balancing, and communication between nodes.
Initializing the cluster
A GitHub Enterprise Server cluster must be set up with a license and initialized using the administrative shell (SSH).
Upgrading a cluster
To upgrade a GitHub Enterprise Server cluster to the latest release, use the administrative shell (SSH).
Monitoring the health of your cluster
To ensure the performance and redundancy of a GitHub Enterprise Server cluster, you can monitor the cluster's health.
Evacuating a cluster node running data services
If a node in your GitHub Enterprise Server cluster runs services that store distributed data, you can ensure redundancy as you prepare to replace the node by evacuating the node's data.
Replacing a cluster node
If a node fails in a GitHub Enterprise Server cluster, or if you want to add a new node with more resources, mark any nodes to replace as offline, then add the new node.