GitHub Enterprise Server requires two storage volumes, one mounted to the root filesystem path (
/) and the other to the user filesystem path (
/data/user). This architecture simplifies the upgrade, rollback, and recovery procedures by separating the running software environment from persistent application data.
The root filesystem is included in the distributed machine image. It contains the base operating system and the GitHub Enterprise Server application environment. The root filesystem should be treated as ephemeral. Any data on the root filesystem will be replaced when upgrading to future GitHub Enterprise Server releases.
The root storage volume is split into two equally-sized partitions. One of the partitions will be mounted as the root filesystem (
/). The other partition is only mounted during upgrades and rollbacks of upgrades as
/mnt/upgrade, to facilitate easier rollbacks if necessary. For example, if a 200GB root volume is allocated, there will be 100GB allocated to the root filesystem and 100GB reserved for the upgrades and rollbacks.
The root filesystem contains:
- Custom certificate authority (CA) certificates (in /usr/local/share/ca-certificates)
- Custom networking configurations
- Custom firewall configurations
- The replication state
The user filesystem contains user configuration and data, such as:
- Git repositories
- Search indexes
- Content published on GitHub Pages sites
- Large files from Git Large File Storage
- Pre-receive hook environments
You can deploy GitHub Enterprise Server as a single virtual appliance, or in a high availability configuration. For more information, see "Configuring GitHub Enterprise Server for High Availability."
Some organizations with tens of thousands of developers may also benefit from GitHub Enterprise Server Clustering. For more information, see "About clustering."
Before using GitHub Enterprise Server in a production environment, we strongly recommend you set up backups and a disaster recovery plan. For more information, see "Configuring backups on your appliance."
GitHub Enterprise Server includes support for online and incremental backups with the GitHub Enterprise Serverバックアップユーティリティ. You can take incremental snapshots over a secure network link (the SSH administrative port) over long distances for off-site or geographically dispersed storage. You can restore snapshots over the network into a newly provisioned appliance at time of recovery in case of disaster at the primary datacenter.
In addition to network backups, both AWS (EBS) and VMware disk snapshots of the user storage volumes are supported while the appliance is offline or in maintenance mode. Regular volume snapshots can be used as a low-cost, low-complexity alternative to network backups with GitHub Enterprise Serverバックアップユーティリティ if your service level requirements allow for regular offline maintenance.
For more information, see "Configuring backups on your appliance."
GitHub Enterprise Server is a virtual appliance that runs on your infrastructure and is governed by your existing information security controls, such as firewalls, IAM, monitoring, and VPNs. Using GitHub Enterprise Server can help you avoid regulatory compliance issues that arise from cloud-based solutions.
GitHub Enterprise Server also includes additional security features.
- Operating system, software, and patches
- Network security
- Application security
- External services and support access
- Encrypted communication
- Users and access permissions
- Audit and access logging
GitHub Enterprise Server runs a customized Linux operating system with only the necessary applications and services. GitHub manages patching of the appliance's core operating system as part of its standard product release cycle. Patches address functionality, stability, and non-critical security issues for GitHub applications. GitHub also provides critical security patches as needed outside of the regular release cycle.
GitHub Enterprise Server is provided as an appliance, and many of the operating system packages are modified compared to the usual Debian distribution. We do not support modifying the underlying operating system for this reason (including operating system upgrades), which is aligned with the GitHub Enterprise Server license and support agreement, under section 11.3 Exclusions.
Currently, the base of the GitHub Enterprise Server appliance is Debian 9 (Stretch) and receives support under the Debian Long Term Support program. There are plans to move to a newer base operating system before the end of the Debian LTS period for Stretch.
Regular patch updates are released on the GitHub Enterprise Server releases page, and the release notes page provides more information. These patches typically contain upstream vendor and project security patches after they've been tested and quality approved by our engineering team. There can be a slight time delay from when the upstream update is released to when it's tested and bundled in an upcoming GitHub Enterprise Server patch release.
GitHub Enterprise Server's internal firewall restricts network access to the appliance's services. Only services necessary for the appliance to function are available over the network. For more information, see "Network ports."
GitHub's application security team focuses full-time on vulnerability assessment, penetration testing, and code review for GitHub products, including GitHub Enterprise Server. GitHub also contracts with outside security firms to provide point-in-time security assessments of GitHub products.
GitHub Enterprise Server can operate without any egress access from your network to outside services. You can optionally enable integration with external services for email delivery, external monitoring, and log forwarding. For more information, see "Configuring email for notifications," "Setting up external monitoring," and "Log forwarding."
You can manually collect and send troubleshooting data to GitHub Support. For more information, see "Providing data to GitHub Support."
GitHub designs GitHub Enterprise Server to run behind your corporate firewall. To secure communication over the wire, we encourage you to enable Transport Layer Security (TLS). GitHub Enterprise Server supports 2048-bit and higher commercial TLS certificates for HTTPS traffic. For more information, see "Configuring TLS."
By default, the appliance also offers Secure Shell (SSH) access for both repository access using Git and administrative purposes. For more information, see "About SSH" and "Accessing the administrative shell (SSH)."
GitHub Enterprise Server provides three types of accounts.
adminLinux user account has controlled access to the underlying operating system, including direct filesystem and database access. A small set of trusted administrators should have access to this account, which they can access over SSH. For more information, see "Accessing the administrative shell (SSH)."
- User accounts in the appliance's web application have full access to their own data and any data that other users or organizations explicitly grant.
- Site administrators in the appliance's web application are user accounts that can manage high-level web application and appliance settings, user and organization account settings, and repository data.
For more information about GitHub Enterprise Server's user permissions, see "Access permissions on GitHub."
GitHub Enterprise Server provides four authentication methods.
- SSH public key authentication provides both repository access using Git and administrative shell access. For more information, see "About SSH" and "Accessing the administrative shell (SSH)."
- Username and password authentication with HTTP cookies provides web application access and session management, with optional two-factor authentication (2FA). For more information, see "Using built-in authentication."
- External LDAP, SAML, or CAS authentication using an LDAP service, SAML Identity Provider (IdP), or other compatible service provides access to the web application. For more information, see "Authenticating users for your GitHub Enterprise Server instance."
- OAuth and Personal Access Tokens provide access to Git repository data and APIs for both external clients and services. For more information, see "Creating a personal access token."
GitHub Enterprise Server stores both traditional operating system and application logs. The application also writes detailed auditing and security logs, which GitHub Enterprise Server stores permanently. You can forward both types of logs in real time to multiple destinations via the
syslog-ng protocol. For more information, see "Log forwarding."
Access and audit logs include information like the following.
- Full web server logs for both browser and API access
- Full logs for access to repository data over Git, HTTPS, and SSH protocols
- Administrative access logs over HTTPS and SSH
- User logins, password resets, 2FA requests, email setting changes, and changes to authorized applications and APIs
- Site administrator actions, such as unlocking user accounts and repositories
- Repository push events, access grants, transfers, and renames
- Organization membership changes, including team creation and destruction
You can see a complete list of dependencies in your appliance's version of GitHub Enterprise Server, as well as each project's license, at
Tarballs with a full list of dependencies and associated metadata are available on your appliance:
- For dependencies common to all platforms, at
- For dependencies specific to a platform, at
Tarballs are also available, with a full list of dependencies and metadata, at