One GitHub Enterprise licence gives you both deployment options (GitHub docs), so this isn't a purchasing decision — it's an architecture decision you can revisit. For most organizations it's straightforward. For Canadian organizations with a hard data-residency requirement, it currently isn't, and that's the part worth reading.
The basic trade
GitHub Enterprise Cloud. GitHub hosts it. In GitHub's words, “your repositories and other resources are hosted by GitHub, and you'll automatically have access to the latest features and bugfixes” (GitHub docs). You get a 99.9% monthly uptime SLA. You do no patching.
GitHub Enterprise Server. You run it — a self-contained virtual appliance on Hyper-V, VMware, OpenStack KVM, AWS, GCP or Azure. Your administrators own every upgrade and hotpatch (GitHub docs). There is no GitHub uptime SLA, because availability is yours.
The feature gap is real and GitHub states it plainly: “most features are released on GitHub.com first, then come to GitHub Enterprise Server”. Per GitHub's own comparison, IP allow lists and data residency are Cloud-only, while self-hosted deployment, pre-receive hooks and LDAP are Server-only (github.com/pricing).
The upgrade burden people underestimate
This is the cost that doesn't appear in any comparison table.
GitHub supports at least the four most recent Server feature releases. As of this writing that's 3.21 (released June 2026, support closing June 2027), 3.20, 3.19 and 3.18 (GitHub docs). Releases arrive roughly quarterly and each carries about twelve months of support.
The practical consequence: a GitHub Enterprise Server instance must be upgraded at least annually, forever, or it falls out of support. That's a recurring, scheduled, tested piece of work owned by a named person.
Organizations that choose Server for control and then don't staff for that end up running an unsupported instance, which is the worst of both options.
To be clear, Server is not a neglected product — 3.21 shipped in June 2026 with organization custom properties, a projects hierarchy view, Actions handling 300+ job workflows, and multiple data disks for MySQL and repository data (GitHub Changelog). It's actively developed. It just costs you operational time that Cloud doesn't.
The Canadian data residency problem
Here's the finding that changes the decision for a lot of Canadian organizations, and it's one we'd rather tell you now than during an assessment.
GitHub Enterprise Cloud with data residency is not available in Canada.
GitHub's documentation lists the available regions as: “EU (includes Azure regions in EFTA countries, currently Norway and Switzerland), Australia, US, Japan” (GitHub docs). GitHub's marketing page says the same: “Currently available in the European Union (EU), Australia, U.S. and Japan — with more regions coming soon” (GitHub).
Canada is not on that list. It is also not named in any roadmap commitment — GitHub says only that it “plans to offer data residency in more regions.” The regions that have gone live did so over about eighteen months: EU in October 2024, US in May 2025, Japan in December 2025, EFTA added to the EU region in March 2026. There is no announced Canadian date.
If your obligation is that source code must be stored in Canada — common in provincial and municipal government, and in regulated financial and health workloads — then GitHub Enterprise Cloud cannot satisfy it today, whatever the deployment. The honest options are:
Run Enterprise Server in a Canadian region. Self-hosted on Azure Canada Central or Canada East, another Canadian cloud region, or on-premises. You get genuine residency control and full network isolation, and you accept the annual upgrade obligation and the feature lag.
Re-examine the requirement. Sometimes the constraint is a policy on personal or customer data rather than on source code specifically. That's worth checking carefully before committing to a self-hosted platform for the next five years, because the two lead to very different architectures.
What you should not do is assume this gets solved by procurement. It's a product-availability fact, not a negotiation.
If residency isn't your constraint
For everyone else, Cloud is the default and the burden of proof sits with Server.
Choose Cloud when you want the newest features as they ship, don't want to own upgrades and availability, want the 99.9% SLA, or need IP allow lists. Choose Server when data must stay in a specific place, when you need genuine network isolation, when you depend on pre-receive hooks or direct LDAP, or when regulatory obligations require the whole environment under your control.
And you can run both — Server for the regulated workload, Cloud for everything else, bridged with GitHub Connect to share features and workflows between them. That's a common and entirely reasonable end state, not a compromise.
One caveat if you land on data residency in a non-Canadian region: it isn't identical to standard Enterprise Cloud. Public repositories and gists aren't available at all, macOS Actions runners and some Packages ecosystems aren't currently supported, and all API calls must target your dedicated *.ghe.com subdomain rather than api.github.com — which will break Marketplace actions that hard-code the standard endpoint (GitHub docs). Worth reviewing the full feature list before you commit.
Not sure which side of this you fall on? Working out the residency and compliance constraints is the first thing we do in a GitHub Enterprise migration assessment — and if you're new to the platform, start with what GitHub Enterprise actually is.