What's changed: New GH-100 Chapter 2 (user support & standards = admin vs GitHub Support triage, support bundles/diagnostics, dev-process standards [branching/reviews/releases/workflows] backed by rulesets; deployment & licensing = GHEC with EMU / Data Residency + EMU / personal accounts / GHES, seat + metered billing, monitoring license usage and reclaiming unused seats, SCIM/EMU linkage)
2.2Deployment Scenarios and Licensing
Understand the main GitHub Enterprise deployment scenarios (GHEC with EMU, GHEC with Data Residency + EMU, GHEC with personal accounts, GHES), licensing and billing models, and monitoring license usage.
There isn’t one way to adopt GitHub. GH-100 tests choosing a deployment scenario per requirements (data residency, identity management, operational overhead) and understanding licensing/billing. Broadly, it splits into GitHub-hosted GitHub Enterprise Cloud (GHEC) and self-hosted GitHub Enterprise Server (GHES).
2.2.1Main deployment scenarios
Key scenarios: (1) GHEC with EMU—cloud, users fully managed by the company IdP (EMU); for strict identity control. (2) GHEC with Data Residency + EMU—EMU plus keeping data in a specific region (for data-residency requirements). (3) GHEC with personal accounts—the traditional model where members join with personal accounts (governed by SAML SSO). (4) GHES—self-hosted on-prem/your cloud, with full in-house data control. Choose by requirements: "full identity control = EMU," "data residency = Data Residency," "full self-management = GHES."
2.2.2Licensing and billing
GitHub Enterprise is billed primarily by user (seat) license. On top, there are metered products—GitHub Actions minutes and storage, GitHub Packages storage, and Copilot/GHAS seats/usage. Admins must understand which products are fixed (seat) vs metered and estimate cost. Manage licenses in enterprise/org billing settings, configuring payment (credit card / invoice / Azure subscription billing).
2.2.3Monitoring license usage
For cost and compliance, monitor license consumption—assigned seats, free seats, active/inactive users, and metered-product usage. Admins review usage reports to reclaim unused seats and act before metered costs balloon (optimization in Chapter 5). Combined with EMU or SCIM (Chapter 1), departed users’ seats free up automatically, easing inventory.
Common: (1) Choose deployment by requirements: GHEC with EMU (full identity control) / GHEC with Data Residency + EMU (data residency) / GHEC with personal accounts / GHES (full self-management). (2) Billing is by user (seat) plus metered (Actions minutes/storage/Copilot/GHAS, etc.). (3) Monitor license usage and reclaim unused seats; SCIM/EMU auto-free departed users’ seats.
Watch out: (1) EMU (identity control) and Data Residency (data location) are different requirements—there’s a combined scenario (GHEC with Data Residency + EMU). (2) GHEC (cloud) and GHES (self-hosted) differ in features/ops. (3) Don’t conflate seat billing with metered billing—account for both in cost estimates. (4) Unused seats left unchecked waste cost/compliance—reclaim via regular monitoring.
2.2.4Section summary
- Deployment: GHEC with EMU / Data Residency + EMU / personal accounts / GHES, chosen by requirements
- Billing by user (seat) plus metered (Actions minutes/storage/Copilot/GHAS)
- Monitor license usage and reclaim unused seats; SCIM/EMU auto-free departed seats
- EMU (identity) and Data Residency (data location) differ; GHEC and GHES differ in ops
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. Which deployment fits keeping data in a specific region while fully managing users via the company IdP?
Q2. Which deployment suits an org wanting full in-house data control on-prem?
Q3. Which correctly describes GitHub Enterprise billing?
Q4. What should an admin do to avoid cost waste from unused seats?
Q5. How does using SCIM or EMU change seat management for departed users?
Q6. Which correctly relates EMU and Data Residency?