The choice is usually framed as a data location question. It is mostly an operational responsibility question, and secondarily a feature availability one.
Both products are called GitHub Enterprise, both have organisations and repositories and rulesets, and the differences that matter are about who runs the thing and how quickly capabilities arrive.
The short answer
Section titled “The short answer”GitHub Enterprise Cloud is hosted by GitHub. Organisations live on GitHub.com, or on a dedicated ghe.com subdomain with data residency.
GitHub Enterprise Server is an appliance you run. Your infrastructure, your upgrades, your backups, your capacity planning.
The feature set differs, and Server trails. Capabilities appear in Cloud first and reach Server on its release cycle, if at all.
The support policy is explicit. GitHub documents that it “supports at least the four most recent feature releases”, with each release supported for approximately a year from its release date.
Which means an upgrade cadence is not optional. Falling more than four feature releases behind puts you on an unsupported version.
The release and upgrade cycle
Section titled “The release and upgrade cycle”Feature releases arrive periodically, and each is supported for about a year. GitHub’s documentation states the support policy as at least the four most recent feature releases.
Which sets a floor on your upgrade cadence. Running four releases behind means you are on the oldest supported version, and the next release makes you unsupported.
Work out what that means in practice. With releases arriving several times a year and each supported for approximately a year, an organisation that upgrades once a year is permanently near the edge of support. One that upgrades twice a year has comfortable margin. One that upgrades when somebody remembers will eventually be unsupported and will discover it during a security advisory.
Patch releases are separate from feature releases, and they carry security fixes within a version. These are smaller, more frequent, and applying them promptly is the more immediate security obligation.
Verify the current versions and dates in GitHub’s release documentation rather than working from any secondary source — this is exactly the information that goes stale.
Upgrades are an operational project. Planning, a maintenance window, testing, and a rollback position. Not a background task.
Read the upgrade path documentation. Multi-version jumps may require intermediate steps, and discovering that during a maintenance window is expensive.
Self-hosted runners have version compatibility requirements with the Server release, which means a Server upgrade may require a runner update as well.
Where the feature gap actually bites
Section titled “Where the feature gap actually bites”“Server trails Cloud” is true and unhelpfully vague. The gap matters in specific places, and knowing which ones lets you evaluate it against your own plans.
Newly announced capabilities. Anything GitHub ships is available in Cloud first. A feature announced today may reach Server in a later feature release, or may not.
Preview features. Several capabilities discussed in this pillar are documented as being in public preview, and preview features are generally a Cloud concern. An enterprise on Server should assume preview capabilities are not available to it.
Identity capabilities. Enterprise Managed Users, and the OIDC and conditional access support described in OIDC for EMU, are Cloud concerns.
Audit log streaming destinations and behaviour. Verify what your Server version supports rather than assuming parity with the Cloud documentation.
AI and Copilot capabilities, which move quickly and where the gap is correspondingly larger.
Actions ecosystem access. Server can access public actions with the right configuration, and the arrangements differ from Cloud.
The practical approach: whenever you read documentation, check that you are reading the version for your platform. GitHub’s documentation is versioned, and the Cloud documentation describes capabilities a Server deployment may not have. This single habit prevents most planning errors.
And re-check at each upgrade. A feature unavailable two releases ago may have arrived, and knowing what an upgrade delivers is part of justifying it.
What you take on with Server
Section titled “What you take on with Server”The honest list, because this is where the decision is actually made.
Infrastructure. Sizing, provisioning, storage, network, and growth. A repository estate that doubles needs capacity planning.
Upgrades. Multiple times a year, each a project.
Backups and restore. Including testing the restore, which is the part that gets skipped.
High availability, if you need it. A second appliance, replication, and a tested failover.
Monitoring. Availability, performance, capacity, and the ability to tell whether a slowdown is the appliance or the network.
Support escalation. Somebody who can diagnose and someone to call.
Runner infrastructure. Actions on Server needs runners you provide.
Security patching, driven by the upgrade cadence.
None of this is exotic, and all of it is a team’s ongoing work. The comparison against Cloud should price it rather than treating it as absorbed by existing operations.
What Cloud costs you
Section titled “What Cloud costs you”Not free of trade-offs either.
Less control over timing. Changes arrive when GitHub ships them. A behaviour change you did not want is not something you can defer, and a change that breaks an integration must be responded to rather than scheduled.
Data location is GitHub’s, unless you use data residency.
Network dependency. A connectivity problem between your organisation and GitHub is an outage you cannot fix.
Less isolation. A multi-tenant service, with the corresponding assurance model — one that most organisations accept and some cannot.
Feature availability may still be limited, particularly with data residency, where some capabilities behave differently or are unavailable.
Vendor concentration. Source code, CI, packages, issue tracking and identity integration on one provider. That is a business continuity consideration worth having a position on, even though the alternative — spreading them across providers — has its own substantial costs.
Which are real and are mostly accepted. Most organisations conclude that the operational relief outweighs them, and the ones that do not usually have one of the specific requirements below.
What is the same
Section titled “What is the same”Worth establishing, because the differences get all the attention and the similarities are what make the products comparable at all.
Git is identical. Clone, commit, branch, merge, push. Nothing about the product changes Git.
The organisation and repository model. Enterprise accounts, organisations, teams, repositories, permissions.
Pull requests, issues, reviews and CODEOWNERS.
Rulesets and branch protection, subject to which rules the version supports.
The REST and GraphQL APIs, with version-appropriate endpoints. Automation written against one generally works against the other with a base URL change.
Actions, conceptually — workflows, jobs, steps, reusable workflows — with runner provision differing.
Webhooks and apps.
Which means the governance material in this pillar largely transfers. Ruleset design, custom properties, fleet management, lifecycle, standardised CI — the concepts and most of the mechanisms apply to both, and the differences are in availability rather than in approach.
And it means expertise transfers. An engineer who understands one product understands the other, which matters for hiring and for running both.
The exceptions cluster in identity and in newer capabilities, which is where the rest of this article focuses.
Data residency
Section titled “Data residency”GitHub Enterprise Cloud with data residency places enterprise data in a chosen region, on a dedicated ghe.com subdomain.
It is not only a location change. Some features behave differently or are unavailable, and integrations assuming github.com need attention.
It uses managed user accounts, which brings the full set of Enterprise Managed Users constraints — no public content, no external collaboration.
Some capabilities documented elsewhere in this pillar are explicitly unavailable with data residency, including OIDC authentication for audit log streaming to Amazon S3.
Which makes it a third option rather than a variant of Cloud. If it is under consideration, every feature decision in your plan needs verification against data residency documentation specifically.
Availability and continuity
Section titled “Availability and continuity”The dimension where the products differ most in kind, and where the comparison is frequently made carelessly.
With Cloud, availability is GitHub’s responsibility. An outage is something you experience and cannot fix, and the mitigation is that outages are GitHub’s core business to prevent.
With Server, availability is yours. Which means it is exactly as good as your infrastructure and your operational practice — potentially better than a hosted service, and in practice frequently worse, because a single appliance with no high-availability configuration is a single point of failure with a restore time measured in hours.
High availability on Server is a second appliance, replication, and a tested failover. That is additional infrastructure and additional operational work, and organisations frequently defer it.
The honest comparison is between a hosted service with a published availability record and your appliance with whatever configuration you have actually implemented — not with the configuration you intend to implement.
Disaster recovery differs similarly. With Cloud, your recovery concern is your own data — repositories are on GitHub’s infrastructure, and your obligation is whatever backup policy you have chosen to add. With Server, recovery is entirely yours, including the restore you have not tested.
And the failure modes differ. A Cloud outage affects everybody and is widely visible, with public status information. A Server outage affects only you, and diagnosing it is your team’s work at whatever hour it happens.
Whichever you choose, have a position on what happens when it is unavailable. Can engineers work? Can deployments proceed? Can an incident be resolved? Those questions have answers under both products, and having thought about them beforehand is the difference between an inconvenience and a crisis.
Deciding
Section titled “Deciding”Choose Cloud when you want the current feature set, do not want to run infrastructure, and your data location requirements are satisfiable.
Choose data residency when a regulatory or contractual requirement specifies a region, and you can accept managed users and the feature differences.
Choose Server when you have a genuine requirement for self-hosting — an air-gapped environment, a regulatory position that does not permit a hosted service, or infrastructure control that is contractually required — and you have a team to run it.
Do not choose Server for “control” without a specific requirement. The operational cost is continuous, the feature lag is real, and the security exposure from a missed upgrade cadence is significant.
Do not choose Server on cost. Once infrastructure, operations staff and upgrade projects are priced, the comparison is rarely what people expect.
Cost, honestly
Section titled “Cost, honestly”The comparison people get wrong most often, because the visible costs are on one side and the invisible ones on the other.
Cloud costs are a licence, plus metered usage for Actions minutes, storage, and any add-ons. Visible, on an invoice, and straightforward to attribute.
Server costs are a licence, plus everything else. Infrastructure — compute, storage, network, and the same again for high availability and for staging. Runner infrastructure. And staff time: upgrades several times a year, backup verification, monitoring, capacity planning, incident response, and support escalation.
The staff time is the number people omit. Several upgrade projects a year, each consuming days of engineering time across planning, testing and execution, plus the ongoing operational load. Over a year that is a meaningful fraction of a person, and for a large deployment considerably more.
Neither is obviously cheaper. For a small estate, Server’s fixed operational cost dominates. For a very large one, the calculation shifts. The point is not that one wins — it is that the comparison must include the operational cost or it is not a comparison.
Price the risk too. A Server deployment that falls behind on upgrades carries a security exposure with a real expected cost, and it is the most likely failure mode rather than an edge case.
And price the feature lag. Capabilities you cannot use are a cost, even if it does not appear on an invoice — particularly where a capability would have reduced other work.
Compute your own numbers. Every organisation’s are different, and any general claim about which is cheaper should be treated as unverified.
Running both
Section titled “Running both”Some enterprises run both, which is a real configuration and it has real costs.
Two feature sets. A capability available in Cloud and not in Server means either two ways of working or the lowest common denominator.
Two governance configurations. Rulesets, policies and identity configured twice, drifting apart.
Two sets of tooling. Automation that works against both, or twice.
A migration question that never resolves. Repositories in one place that should be in the other, indefinitely.
Where it is genuinely warranted — an air-gapped environment alongside general engineering, or a subsidiary with a regulatory constraint — treat the boundary explicitly and minimise what crosses it.
Where it is historical, plan the consolidation. See migration planning.
Running Server well
Section titled “Running Server well”If Server is the right choice, these are the practices that separate a well-run deployment from one that becomes a liability.
Treat upgrades as scheduled work, not as projects to be justified each time. A standing quarterly slot means the cadence holds. Requiring a business case each time means falling behind.
Maintain a staging appliance. Upgrades tested against a copy of production, with real data volumes, before the production window. The single most valuable practice, and the one most often skipped for cost reasons.
Test the restore quarterly. Restore a backup to a separate appliance and confirm it works. A backup that has never been restored is an assumption.
Monitor capacity ahead of need. Storage, memory and CPU trends, with an alert well before a threshold. An appliance that runs out of disk is an outage.
Watch the repository estate’s growth. Sizing was done for the estate as it was, and a large monorepo appearing changes the calculation. See repository health.
Plan runner capacity separately. Actions on Server needs runners you provide, and their capacity is a distinct concern from the appliance’s.
Keep a documented rollback for each upgrade, and know how long it takes.
Have a named owner. An appliance nobody owns is an appliance that falls behind, and the failure is gradual until it is not.
The migration question
Section titled “The migration question”Organisations move between the products in both directions, and the direction determines the difficulty.
Server to Cloud is the common direction, and it is supported by tooling. GitHub Enterprise Importer accepts GitHub Enterprise Server as a source from a documented minimum version. See GitHub Enterprise Importer.
Cloud to Server is less common and less well served. Consider it a bespoke project rather than a supported path.
Either direction carries the same tail that dominates every platform migration: Actions secrets, variables, environments, self-hosted runners, workflow run history, Git LFS objects, and teams and team memberships are not carried by the importer. That list is usually larger than the repository migration itself.
And identity is a separate project. Moving platform does not move accounts, and the identity model may need to change — particularly if the destination uses managed users.
Plan it as a migration, with the discipline in migration planning, rather than as a platform change.
Run the lifecycle process first. Every repository you archive rather than migrate is work you do not do.
Common mistakes
Section titled “Common mistakes”Choosing Server for control without a specific requirement. Continuous cost, feature lag, upgrade exposure.
Not pricing the operational burden. Infrastructure, upgrades, backups, monitoring, staff.
Falling behind the supported release window. No security patches.
Assuming a Cloud feature exists in Server. It trails, and some things are Cloud-only.
Treating data residency as a location change. Feature availability and user management both differ.
Not testing the restore. A backup that has never been restored is a hope.
Running both without a boundary. Two of everything, drifting.
Planning around a version’s feature set without verifying the current release. These details change.
The requirements that genuinely favour Server
Section titled “The requirements that genuinely favour Server”Because “we need control” is not a requirement, it is worth naming the ones that are.
An air-gapped or disconnected environment. A network with no internet path. This is the clearest case and it is not satisfiable by any hosted service.
A regulatory position that prohibits hosted processing of the relevant data, where data residency does not satisfy it. Rare, and real in some jurisdictions and sectors.
A contractual obligation to a customer specifying infrastructure control. Also real, also worth checking whether data residency satisfies it before committing.
Latency to a location a hosted service does not serve well. Increasingly rare, and occasionally decisive.
An integration requiring network-level access to the platform that a hosted service cannot provide.
What is not a requirement:
“We want our data on our infrastructure.” A preference, unless something specifies it.
“We need to control when things change.” Legitimate as a preference, and it is purchased with the entire operational burden plus the feature lag.
“It’s cheaper.” Rarely true once staff time is priced.
“Security.” A self-hosted appliance that falls behind on upgrades is less secure than a hosted service, not more. This inversion is common and worth stating.
Write the requirement down. If it cannot be written in one sentence naming a specific constraint, the decision is a preference — and preferences should be weighed against the operational cost explicitly rather than assumed to be free.
Governance differences in practice
Section titled “Governance differences in practice”Applying the rest of this pillar to a Server deployment requires a few adjustments.
Enterprise policies exist on both, and the available set differs by version. Check the documentation for your version rather than the Cloud pages.
Rulesets exist on both, with the rule catalogue varying by version. A rule described in Cloud documentation may not be available.
Custom properties and property-based targeting — verify availability for your version, because this is the foundation for targeted governance and its absence changes the whole approach.
Audit logging is present, with destination options and retention behaviour that need checking against your version rather than assumed from Cloud.
Identity is where the largest differences sit. SAML and SCIM behave differently, and the managed-user model is a Cloud concern.
Actions requires runners you provide, which makes runner groups and the network design in that article more central rather than less.
API automation transfers directly, with a different base URL. The scripts in API automation work against Server with that change, subject to endpoint availability.
The practical guidance: read this pillar for the concepts, and verify each specific mechanism against your version’s documentation before building on it. The reasoning about what to govern and how to roll it out is platform-independent; the availability of any particular mechanism is not.
Mental model
Section titled “Mental model”Cloud trades control for operational relief; Server trades operational burden for control. The feature gap is real and the upgrade cadence is not optional — a Server deployment is a commitment to an ongoing project several times a year, and an organisation that cannot sustain that will end up unsupported.
What you learned
Section titled “What you learned”- GitHub documents that it supports at least the four most recent Enterprise Server feature releases
- Each Server feature release is supported for approximately a year from its release date
- The support policy sets a floor on upgrade cadence, and falling behind means no security patches
- Upgrade paths may require intermediate versions, and self-hosted runners have compatibility requirements
- Server’s operational surface is infrastructure, upgrades, backups, high availability, monitoring and runners
- Cloud’s trade-offs are timing, data location, network dependency and the multi-tenant assurance model
- Data residency uses managed user accounts and has its own feature differences, including for audit log streaming authentication
- Running both means two feature sets, two governance configurations and two sets of tooling
Exercise
Section titled “Exercise”Reason from your organisation’s position.
-
State the specific requirement, if any, that would rule out a hosted service. Predict: can you write one?
-
If you run Server, find your current version and check it against the currently supported releases.
-
Calculate how many upgrade projects you have completed in the last two years, against how many releases shipped.
-
Price the Server operational burden: infrastructure, staff time on upgrades, backups, monitoring.
-
When was your restore last tested end to end?
-
List three features you use or want. Verify availability for your platform.
-
If data residency is under consideration, list the features in this pillar you would need to re-verify.
-
If you run both, write down what determines which platform a repository belongs on.