Self-hosted GitHub alternative for EU data residency: the short answer
If your organization is regulated in the EU and must keep source code and its metadata inside the EU, GitHub's own answer is GitHub Enterprise Cloud with data residency on GHE.com, which lets you choose where code and data are stored and includes an EU region. A self-hosted GitLab, Gitea or Forgejo running in an EU data center is the alternative when you need full control over where the data sits, who operates the platform, and who supports it. The trade-off is that GHE.com keeps GitHub's operations and upgrade cycle, while the self-hosted route moves those duties, and their cost, to your team or to a partner you pay.
Before you decide, read GitHub's data residency documentation closely. It states that public repositories are not available on GHE.com and that certain GitHub Copilot features are unavailable there, so check those gaps against the way your teams actually work. Then list which obligations depend on location alone and which depend on who operates the system, because a EU region answers the first question but not the second. Confirm with GitHub in writing which data, including backups, support access and telemetry, stays in the region you select.
On the self-hosted side, the decision turns on operations rather than hosting location. GitLab, Gitea and Forgejo each run on infrastructure you control, but you own patching, backups, high availability and incident response. GitLab's self-managed editions also require planned upgrade stops, so budget for that work before you commit. Ask each candidate for its support model, its licensing for the features you need, and a tested restore procedure, then compare those answers with the GHE.com contract terms your legal team will review.
What EU data residency requires from a source hosting platform
Data residency for source code is more than picking a region. Each requirement below is a question to put to any hosted Git vendor, and to yourself if you self-host, before code and metadata leave your current platform. The answers decide whether a regional tenant or a self-hosted forge in an EU data center fits your obligations.
Where code and data are stored
A regional option only helps if the vendor commits to where repositories, issues, pull requests and logs live. GitHub's EU option stores data in the region an enterprise selects on a dedicated GHE.com subdomain. Ask the vendor which systems hold each data type, including backups, search indexes and CI logs, and whether any of them sit outside the chosen region.
Which regions are available
Regional choice depends on the plan and the region list. GitHub Enterprise Cloud with data residency offers EU, Australia, US and Japan regions, and its EU region includes Azure regions in Norway and Switzerland. Confirm the exact region for your tenant in writing, because a region on a list does not show that your data will sit in your jurisdiction of choice.
What a regional tenant excludes
A regional tenant is a separate environment with limits. GitHub's documentation states that public repositories are not available on GHE.com and that certain Copilot features are unavailable there. Map your open source projects, public mirrors and Copilot workflows before you commit, because moving them later can mean a second platform and a second set of accounts.
Where tokens and SSH keys sit
Credentials can fall outside the data region even when repositories do not. Azure DevOps stores customer data in the geography chosen for the organization but keeps tokens and SSH keys in a US datacenter, so a regional choice for code does not settle authentication data. Ask each vendor where personal access tokens, SSH keys, OAuth grants and CI secrets are stored and processed.
Exports and backups
Exports and backups are copies of your data, and they must follow the same residency rules. Git history can move by clone or mirror, but issues, pull requests and reviews need a platform export. Bulk exports also run into API rate limits, such as GitHub's 5,000 REST requests per hour for personal access tokens, so plan the export window. Confirm where export archives are stored and how long they remain available.
Operating the platform yourself
Self-hosting moves the residency question to your own change control. You choose the data center, the backup targets, the key storage and the admin access model, and you own patching and upgrades. GitLab documents offline and air-gapped operation, and Forgejo documents upgrade paths from Gitea, but each release must still be scheduled and tested. Ask a provider or your own team to write down who can read backups and where they are kept.
What GitHub's EU option includes and leaves out
GitHub Enterprise Cloud with data residency lets an enterprise choose where its code and data are stored. The service runs on a dedicated GHE.com subdomain rather than the shared github.com domain, which gives the organization its own hostname and a separate tenant boundary. The EU region is one of the options, and according to GitHub's documentation it includes Azure regions in Norway and Switzerland. The core question for an EU team is whether the storage location you select matches your residency obligations, so the storage region is a decision made at setup and documented in your contract.
- Dedicated subdomain: the enterprise is served from a GHE.com hostname with its own identity and administration scope.
- EU region: storage is placed in Azure regions in Norway and Switzerland, as GitHub documents.
- Storage location choice: the enterprise selects the region for its code and data rather than accepting a default.
- Managed operation: GitHub runs the platform, upgrades and infrastructure, so your team does not operate servers.
Confirm with GitHub which data categories are stored in the selected region, including backups, logs and any metadata that leaves it, and get that answer in writing.
Data residency on GHE.com does not cover everything a GitHub customer uses. GitHub's data residency documentation states that public repositories are not available on GHE.com, so open-source work that depends on public visibility must stay on github.com or move elsewhere. The documentation also states that certain GitHub Copilot features are unavailable on GHE.com. Teams that rely on those features will find a gap, and that gap changes the cost and workflow of the platform. Because the list of unavailable features can change, the reader should check the current documentation rather than rely on a snapshot.
- Public repositories: these are not available on GHE.com, which affects open-source projects and any public collaboration.
- Copilot features: certain Copilot features are unavailable on GHE.com, so check each one your developers use.
- Feature parity: confirm whether other products, add-ons or integrations your teams depend on behave the same way on GHE.com.
- Ongoing change: the availability of features and regions is set by GitHub and may change over time.
Ask GitHub for a current list of exclusions for your plan and region, and map each excluded feature to a workflow owner in your organization.
GitHub Enterprise Server is the self-managed edition of GitHub. It runs as a virtual appliance on infrastructure the customer controls, which can be a data center, a private cloud or an air-gapped network. Choosing it means the customer operates the appliance, applies upgrades and holds the data on its own hardware. That is a different control model from GHE.com, where GitHub operates the service in a region the customer selects. Both options involve licensing and operating cost, but the cost components and responsibilities differ.
- Who operates it: GHE.com is run by GitHub, while Enterprise Server is run by your team on your infrastructure.
- Where data lives: GHE.com stores data in a selected Azure region, while Enterprise Server stores it on hardware you choose.
- Upgrade responsibility: GitHub maintains GHE.com, while Enterprise Server upgrades are scheduled and applied by your team, using the release history in GitHub's documentation.
- Cost components: Enterprise Server adds infrastructure, staff and maintenance effort to the licence, whereas GHE.com bills for the service.
Identify which control model your auditors and data protection officer accept, then compare both against the open-source options in this guide.
Before signing a renewal or a new contract, procurement and security teams should turn the documentation into specific written answers. The goal is to know exactly where code, metadata, logs and support access sit, and which features your teams will lose. Vendors update their region lists and feature availability, so the answers should be dated and attached to the contract. The same questions also serve as the baseline for comparing an open-source forge hosted in an EU data center, where your team controls each answer directly.
- Storage scope: which data categories are stored in the selected region, and which are replicated or processed elsewhere.
- Support access: from which locations GitHub staff can access your data for support, and under what approval process.
- Feature gaps: the current list of Copilot features and other capabilities unavailable on GHE.com for your plan.
- Public work: how public repositories and open-source contributions would be handled if your organization needs them.
- Exit terms: how repositories, issues and pull requests are exported and in what format if you leave.
Record each answer with its date and the name of the GitHub representative who gave it.
Which self-hosted forge meets the constraint and at what trade-off
This table compares GitLab, Gitea and Forgejo on the points that matter when source hosting must stay in the EU: licensing and governance, offline operation, CI compatibility, package registries and paid tiers. Read it with one rule in mind: the data location is set by where your organization runs the server, not by the software itself.
| Requirement | GitLab | Gitea | Forgejo |
|---|---|---|---|
| License and governance | Open core: MIT outside the ee/ directory, proprietary code in ee/ needs a paid subscription | MIT licensed, with commercial leadership and support from CommitGo, Inc. | GPL-3.0-or-later from v9.0, domains held by Codeberg e.V., project governance independent |
| Data location | Set by where you deploy the instance, including EU data centers you choose | Set by where you deploy the instance, including EU data centers you choose | Set by where you deploy the instance, including EU data centers you choose |
| Offline and air-gapped operation | Documented for offline environments, with separate guidance for scanners and GitLab Duo Self-Hosted | Self-hosted installs run without a vendor cloud; confirm the offline steps for your build and packages | Self-hosted installs run without a vendor cloud; confirm offline dependencies for your deployment |
| CI/CD compatibility | GitLab CI/CD uses its own pipeline syntax; GitHub workflows need conversion | Gitea Actions is designed to be compatible with GitHub Actions; confirm each workflow and action you rely on | Forgejo Actions is familiar to GitHub Actions users but not compatible with GitHub Actions |
| Package registries | Built-in package and container registries; confirm the formats your teams publish | More than 20 registry types, including npm, PyPI, Maven, container images and Helm charts | Built-in package registries; confirm the formats you need against current documentation |
| Compliance and security features | Premium adds advanced CI/CD and priority support; Ultimate adds application security, supply chain and compliance features | Gitea Enterprise adds SAML 2.0, audit logging, IP allowlisting, mandatory 2FA and dependency scanning | Community edition only; confirm audit logging, SSO and access controls against your control set |
| Who supports the software | GitLab Inc. through paid subscriptions, plus partners | CommitGo, Inc. through Gitea Enterprise, plus Gitea Cloud as a managed option | Community governance; support comes from your own team or a service provider |
How to deploy a self-hosted forge in an EU data center
This sequence takes a team from a written residency scope to a forge running in an EU data center, with identity, upgrades, backups and migrated repositories all owned and checked before go-live.
Confirm the residency scope in writing
Your compliance lead, legal counsel and the engineering owner agree in writing which data must stay in the EU: repositories, issues, pull request history, container images, packages, logs and backups. They also record which parts of the workflow may touch systems outside the EU, such as identity providers or external CI runners. DeployOpen can turn that agreed scope into a fixed-scope plan. The step is done when the scope document is signed off and every data class has a named owner and location.
Pick the forge and tier
Choose between self-hosted GitLab, Gitea and Forgejo based on the features your teams use daily, such as merge requests, CI/CD, package registries and security scanning. For GitLab, compare the Free, Premium and Ultimate feature lists on the pricing page, since all three tiers are available for self-managed installations. Gitea offers commercial support from CommitGo through Gitea Enterprise, and Forgejo is governed independently. Ask each vendor or support provider which support level and license terms apply to your organization. The step is done when a written decision records the forge, the tier and the support model.
Choose the EU location and architecture
Select the EU cloud region or data center, then size the topology for your user count and availability needs. For GitLab, review the reference architectures and the high availability guidance for 3,000 or more users. GitLab does not support running stateful components such as PostgreSQL and Redis inside Kubernetes, so the Cloud Native Hybrid pattern runs stateless services on Kubernetes and stateful services on VMs or managed services. Confirm that every component, including object storage and mirrors, sits in the agreed location. The step is done when an architecture diagram shows each component and its EU host.
Set up identity through SSO
Connect the forge to your identity provider so that staff sign in with corporate accounts, multi-factor authentication applies, and offboarding removes access in one place. Confirm which SSO protocols each forge supports in its current release, and note that Gitea Enterprise adds SAML 2.0 service provider support and mandatory two-factor authentication. Decide who may create organizations and who holds administrator rights. The identity provider itself must also be placed and governed under your residency scope. The step is done when a test user signs in through SSO, and a disabled account loses access immediately.
Plan upgrade stops and the maintenance cadence
Write a maintenance calendar that matches the vendor's release model. GitLab ships a minor release on the third Thursday of each month and patch releases twice a month, and it requires upgrade stops at versions x.2, x.5, x.8 and x.11. Forgejo publishes LTS releases with a fixed support window, and Gitea releases follow its own line. Your team owns the staging test, the upgrade rehearsal and the rollback plan for each release. The step is done when the calendar, the stop versions and the staging environment are documented and an owner is named for each upgrade.
Configure backups and test restores
Set up scheduled backups of the database, repository storage, uploaded attachments and configuration files, and store copies inside the EU residency boundary. For GitLab, follow the backup and restore documentation for its component layout. Then run a restore into an isolated EU test environment and time it against your recovery expectations. Record who may approve a restore and how encryption keys are held. The step is done when a full restore has succeeded and the result, including any gaps, is written up for the owners.
Migrate repositories with the platform importer
Move repository history with a clone or mirror, then bring issues, pull requests and reviews with the platform importer. Gitea's migration tool supports GitHub as a source, GitLab can import from GitHub and Bitbucket, and Forgejo's dump-repo and restore-repo commands carry issues, pull requests, releases, labels, milestones, comments and wikis. Run a pilot on a few repositories first, then compare counts and spot-check reviews. Export through hosted APIs is subject to rate limits, so plan bulk exports accordingly. The step is done when a migration report confirms that each repository's history and metadata match the source.
Hand over operations and evidence
Transfer runbooks, the residency register, the upgrade calendar, backup records and access reviews to your platform team. Your team owns daily operations, patching, user administration, incident response and the evidence that auditors will request. DeployOpen can prepare the documentation and controls for a compliance assessment, but independent auditors issue any report or certification. The step is done when the platform team runs a supervised upgrade or restore drill without vendor help and the evidence pack is filed.
How repositories, issues and CI move without leaving the EU
Git history and platform metadata move through different mechanisms, so plan for both. Commits, branches and tags travel by clone or mirror between any two forges. Issues, pull requests, reviews and wikis do not, and they need a platform importer. Gitea's migration code includes an importer for GitHub, and the GitLab import documentation lists GitHub, Bitbucket Cloud, Bitbucket Server, Gitea and other GitLab instances as sources, plus plain Git repositories by URL. Forgejo's dump-repo command exports a repository from GitHub with issues, pull requests, releases, labels, milestones, comments and wiki, and restore-repo loads it into a Forgejo instance on your own servers. Run a test migration of a representative repository and compare the result field by field before you schedule the cutover.
Bulk export is throttled, so the timing of your export matters. GitHub allows 5,000 REST requests per hour for personal access tokens, and Bitbucket Cloud allows 1,000 requests per hour for most API resources. Large organizations with many repositories should plan the export across several hours or days and use a token with the right scope. Confirm the current limits for your account type, since they can change, and check whether your EU-hosted GHE.com organization has any different behavior for exports before you rely on it. Also confirm which GitHub artifacts each importer carries over, such as attachments, releases and reviewer assignments, because importers differ in coverage.
Actions secrets do not export, so CI must be rebuilt and re-secured. Workflow files in .github/workflows can be copied, but the values stored as Actions secrets stay with GitHub and must be re-created in the target forge by someone with the right access. Forgejo Actions falls back to .github/workflows but is not compatible with GitHub Actions, and Gitea Actions is designed to be compatible, so test each workflow on a runner in your EU environment rather than assuming it runs unchanged. Inventory every secret, record the owning team, rotate credentials that were shared broadly, and keep the list in your change record so auditors can trace the handover.
Evidence that auditors and data protection teams ask for
Auditors and data protection teams rarely accept a platform choice on its own. They ask what data sits where, who can reach it, how it is recovered and how it is kept current. The cards below list the records that answer those questions for a self-hosted forge in an EU data center. DeployOpen prepares this evidence, but auditors and certification bodies issue any assessment outcome.
Data location and regions
Record where repositories, databases, object storage and backups physically sit, and which data center or cloud region holds each. For GitHub's own EU option, check the documented regions for GHE.com, which include Azure regions in Norway and Switzerland, and note that public repositories and some Copilot features are not available there. For a self-hosted forge, the evidence is your own infrastructure map, signed off by the team that runs it.
Data processing terms
Collect the contract or data processing terms for every party that touches source code or metadata, including the hosting provider, any managed service and any support vendor. Confirm which sub-processors can access data, where support staff operate, and how deletion works at contract end. For a self-hosted platform, the main vendor question is support access, which should be written into the statement of work with defined access windows.
Access control and SSO configuration
Export the configuration that decides who can sign in and what they can change: the identity provider link, group-to-role mappings, mandatory two-factor settings, branch protection rules and token policies. Auditors typically sample these settings and compare them with the access review records. GitLab documents its authentication and authorization options, and Gitea Enterprise adds SAML 2.0 service provider support and mandatory two-factor authentication, which should be confirmed against your chosen edition.
Backup and restore test records
A backup is only evidence once a restore has been performed. Keep dated restore tests that rebuild the forge, including its Git repositories, database and attachments, on separate hardware, and record how long each step took and what was checked afterward. GitLab documents backup and restore procedures for its components, and the test record should name the version restored so it can be matched to the upgrade history.
Upgrade and patch records
Keep a log of every upgrade and security patch, with the version before and after, the date and the approver. Compare this log with the vendor's maintenance policy. GitLab ships patch releases twice a month and backports security fixes to the previous two monthly releases, while Forgejo publishes support windows for stable and LTS releases. A gap between a published security fix and your deployment is the finding most often raised in reviews.
Administrator audit logs
Retain the logs that record administrative actions: user creation and removal, permission changes, repository visibility changes, token creation and runner registration. Check where these logs are stored, who can edit them and how long they are kept, and confirm that they are forwarded to a store the forge administrators cannot alter. Confirm which audit events each edition records, because feature coverage differs between free and paid tiers.
Questions buyers ask before choosing an EU self-hosted forge
What drives the cost of self-hosting GitLab, Gitea or Forgejo compared with GitHub seats and minutes?
The software licence is the smallest part of the difference: Gitea and Forgejo are free to use, and GitLab Free costs 0 dollars, while GitLab Premium costs 29 US dollars per user per month billed annually according to the GitLab pricing page. The recurring costs you carry are servers, storage, backups, monitoring, upgrades and staff time, plus any commercial support contract you choose. GitHub bills per seat, Actions minutes and storage, so your largest cost drivers are headcount on the forge, CI runner capacity and how much repository data you keep. Ask any provider for a quote that separates one-time setup from recurring operations and states which features sit in each tier.
How long does a migration to a self-hosted forge take?
The duration depends on the number of repositories, the size of their Git history, how much issue and pull request metadata you need to carry over, how many CI workflows and secrets must be rebuilt, and how many integrations point at GitHub. Git history moves with a clone or mirror, while issues, pull requests and wikis need a platform importer, such as the GitHub importers in Gitea and GitLab. Ask for a time estimate in the written scope, with each phase, the repositories in each wave and the cutover plan listed separately. No fixed duration applies to every organization.
What does the work require from our own engineering team?
Your team needs to decide who owns the platform, approve the target design and sign off on access controls, backup policy and cutover. Engineers must confirm which repositories, branches and integrations depend on GitHub, and developers must learn new pull request and review flows where the forge differs. Platform engineers usually run the installation, identity integration, runners and upgrades. Ask the implementation partner to list each client-side task in the written scope so you can plan the time your team has to contribute.
Can our own team run a self-hosted GitLab, Gitea or Forgejo instance after the migration?
Yes, if you have people who can operate Linux servers, databases, backups and certificates. GitLab documents several installation methods, including the Linux package that bundles PostgreSQL, Redis and Sidekiq, and it supports offline, air-gapped environments. Gitea and Forgejo are lighter to run on a small server, but they still need backup, patching and upgrade routines. GitLab requires upgrade stops at versions such as 18.2, 18.5, 18.8, 18.11 and 19.2, 19.5, 19.8 and 19.11, according to the GitLab upgrade paths documentation, so plan a regular upgrade cadence. A hybrid model, with DeployOpen providing upgrades, backups and support under a retainer, is another option.
Do we need GitLab Premium or Ultimate features to meet our control requirements?
Map each control to a feature before you choose a tier. GitLab Premium adds advanced CI/CD and priority support, while Ultimate adds application security testing, software supply chain security, vulnerability management and compliance features, according to the GitLab pricing page. Gitea Enterprise adds SAML 2.0 service provider support, audit logging, organization-level branch protection inheritance, IP allowlisting, mandatory two-factor authentication and dependency scanning, according to the Gitea Enterprise page. Forgejo is GPL-3.0-or-later from v9.0, so its feature set is open, but you should confirm each required control against its documentation. Ask for a control-by-control matrix before purchase.
What happens to our GitHub Actions workflows after we move?
Actions workflows do not move automatically, and each forge handles them differently. Gitea Actions is designed to be compatible with GitHub Actions, so many workflows need only limited changes. Forgejo Actions is designed to be familiar to GitHub Actions users but is not compatible with GitHub Actions, according to the Forgejo documentation, so expect to rewrite parts of workflows and to provide your own runners. GitLab uses its own CI/CD configuration and GitLab Runner. Secrets never export from GitHub, so you must re-create them and check every reusable action, self-hosted runner and deployment target. Ask for an inventory of workflows in the scope before cutover.
How long does Forgejo support each release, and how does that affect planning?
Forgejo stable releases receive full support for three months plus a two-week window, while LTS releases, published in the first quarter of each year, receive critical bugfixes and security support for one year and three months, according to the Forgejo upgrade documentation. The LTS release v15 is supported until July 15, 2027, according to the Forgejo releases page. Choose a release line that matches your upgrade capacity, and schedule upgrades within each support window. Confirm the current support dates with the project before you commit to a version.
When GHE.com is enough and when a self-hosted forge is simpler
GHE.com fits organizations that want GitHub's ecosystem with an EU region and can accept its exclusions. Enterprise Cloud with data residency places code and data on a dedicated GHE.com subdomain, with an EU region that includes Azure regions in Norway and Switzerland. The trade-off is in the exclusions: public repositories are not available there, and certain GitHub Copilot features are unavailable. If your engineers depend on GitHub Actions workflows, marketplace apps and Copilot in their daily work, and none of those exclusions touch your code, GHE.com may be the shorter path. Before signing, confirm with GitHub which region your organization will be provisioned in, which services store data outside that region, and where authentication and support access are handled.
A self-hosted GitLab, Gitea or Forgejo fits when the location, operating model or license is the requirement. Hosting in an EU data center you already operate or contract gives you control over the physical location, the network path and the backup targets. GitLab documents offline and air-gapped operation, so a forge can also run in a network with no outbound internet access. Forgejo is GPL-3.0-or-later from v9.0, Gitea is MIT licensed, and GitLab's Community Edition is MIT licensed while its ee/ directory is proprietary. Each license changes what you may modify and redistribute, so have legal review the license file for the exact edition you plan to run. Note that GitLab's Free, Premium and Ultimate tiers all apply to self-managed installations, and that GitLab's maintenance policy limits bug fixes to the current stable release.
Decide with a short written comparison, then confirm the open items with each vendor. Ask GitHub for the written data residency terms, the list of features excluded on GHE.com and the Copilot feature status for your plan. For a self-hosted option, ask Gitea or CommitGo whether the support model covers your EU hosting and identity setup, and ask GitLab which upgrade stops apply to your target version. Your own team must also confirm who operates the platform, who carries the backup and restore testing, and who applies the required upgrades on schedule. Those staffing costs recur every year, and they are the part of a self-hosted decision most often underestimated. Avoid treating any hosting location as a compliance outcome in itself: whether a platform meets your regulatory obligations depends on your controls and on an independent assessment.
