GitLab instead of GitHub

This is the entry on the list where the popular answer is wrong, so it is worth being precise.

The misconception

"GitLab is the European alternative to GitHub" is widely repeated and not true. GitLab Inc. is a US-incorporated company. The all-remote culture and the international workforce make it feel less American than Microsoft-owned GitHub, but corporate nationality is what the CLOUD Act follows — and GitLab.com additionally runs on Google Cloud.

If you move your repositories from GitHub SaaS to GitLab SaaS on jurisdiction grounds, you have changed vendor and not jurisdiction. That is a lot of migration effort for a benefit you did not get.

Applying the test from the CLOUD Act guide consistently means saying so, even when it makes the tidy answer messier.

What GitLab does solve

Lock-in and portability, which are genuinely valuable and are a different problem from jurisdiction.

GitLab is open-core. You can run the same software yourself, and you can move from GitLab.com to a self-managed instance without changing tools. GitHub has no equivalent path — GitHub Enterprise Server exists but is a separate product on a separate release cadence, and the gravity of GitHub Actions, Issues and the surrounding ecosystem is substantial by design.

So: GitLab reduces the cost of leaving. That is worth having even if you never exercise it, and it is why "GitLab in the direction of travel" is a defensible position.

The options, ranked honestly

The fourth row is the one most organisations should look at hardest and usually skip. A European managed-hosting provider running GitLab for you gives you EU jurisdiction without your team becoming GitLab administrators. It costs more than SaaS and much less than a platform hire.

The honest operational warning

Self-managing GitLab is not a weekend project. You are taking on a database, object storage, CI runner fleet, backup and restore, and an upgrade cadence that does not wait for you. Teams underestimate this consistently.

If you take it on without the capacity to run it, you will end up with an under-patched, under-backed-up instance holding your source code — which is a worse security position than GitHub, whatever the jurisdiction says. Sovereignty you cannot operate is not sovereignty.

Deploying from an EU git host

The objection that stops most of these migrations is not sovereignty. It is "our whole deployment pipeline is wired to GitHub."

Usually less than it appears. Worth separating two things:

Where your code lives and what triggers your deploy are different problems. Most platform-as-a-service providers deploy from a git push to a remote they host, which means your code host is not part of the deployment path at all. Clever Cloud works this way: clever deploy pushes your current branch to a Clever-hosted git endpoint, and Clever never reads your GitHub repository. Any git host works, because the host is not involved.

What you lose by leaving GitHub is the convenience integration — link the repo in the console, and a push to GitHub triggers a build. You replace it with a CI job that runs the deploy itself, holding a deploy token as a CI secret. That is a short pipeline, not a project:

# Forgejo Actions / Woodpecker / GitLab CI — same shape in all three
deploy:
  on: push to main
  steps:
    - checkout
    - install the provider CLI
    - authenticate from CI secrets
    - run the deploy command

The same pattern applies to any EU-hosted provider. If yours deploys from a container registry rather than a git push, the CI job builds and pushes an image instead — again independent of where the source is hosted.

Options that pair well

Self-hosted Forgejo on a small European VPS is the pragmatic answer for most teams: light to run, private repositories without a terms-of-service question, Actions close enough to GitHub's to port workflows quickly, and the software is governed by a German non-profit, so the supply chain is European as well as the hosting.

One consideration when sizing this: a code host is a system you must back up and patch. Sovereignty you cannot operate is not sovereignty, and that warning applies to a 2 GB Forgejo instance as much as to a GitLab estate.

Where source code sits on the risk scale

Worth asking directly: how sensitive is your code?

For many organisations source code is commercially significant but contains no personal data, which puts it in a different risk category from customer records. That may justify accepting US jurisdiction for repositories while insisting on EU hosting for the systems holding customer data.

That is a legitimate, defensible position — and reaching it deliberately is the point. It is a different thing from having never asked.

The verdict

If your driver is lock-in: GitLab is a real improvement, and GitLab.com is fine.

If your driver is jurisdiction: only self-managed GitLab, or a European vendor such as Codeberg, actually delivers it. Budget for the operational load honestly, or use an EU hosting partner.

And if you were about to migrate to GitLab.com to satisfy a sovereignty requirement, stop and re-read the requirement first.