About clustering

Clustering architecture

GitHub Enterprise Server is comprised of a set of services. In a cluster, these services run across multiple nodes and requests are load balanced between them. Changes are automatically stored with redundant copies on separate nodes. Most of the services are equal peers with other instances of the same service. The exceptions to this are the mysql-server and redis-server services. These operate with a single primary node with one or more replica nodes.

Learn more about services required for clustering.

Is clustering right for my organization?

Clustering provides better scalability by distributing load across multiple nodes. This horizontal scaling may be preferable for some organizations with tens of thousands of developers. However, setting up a redundant and scalable cluster can be complex and requires careful planning. This additional complexity will need to be planned for during installation, disaster recovery scenarios, and upgrades.

GitHub Enterprise Server requires low latency between nodes and is not intended for redundancy across geographic locations.

Clustering provides redundancy, but it is not intended to replace a High Availability configuration. For more information, see High Availability configuration. A primary/secondary failover configuration is far simpler than clustering and will serve the needs of many organizations. For more information, see Differences between Clustering and High Availability.

How do I get access to clustering?

Clustering is designed for specific scaling situations and is not intended for every organization. If clustering is something you'd like to consider, please contact your dedicated representative or GitHub's Sales team.