European alternatives to GitLab.

GitLab is often assumed to be the European-friendly answer to GitHub, but the hosted GitLab.com service is operated by GitLab Inc., a US-incorporated public company (Delaware, listed on NASDAQ as GTLB). That places GitLab.com within reach of the US CLOUD Act in the same way as Microsoft-owned GitHub, covering repository content, CI logs, tokens, and issue history. This page maps the European alternatives against GitLab.com, checking who legally owns each service, where the data sits, and what compliance posture each can evidence for a Schrems II transfer impact assessment.

There are two routes to a European posture. The first is to move to a European forge: both options here build on Forgejo, the open-source engine governed by Codeberg e.V. in Germany. Codeberg (Germany, Berlin, non-profit, EU-hosted, free, CLOUD Act exposure: None) is the community-governed home for open-source projects, and Codebahn (Swedish operator, France-hosted, paid and supported, CLOUD Act exposure: None) is the commercial managed option with a public DPA and an all-EU sub-processor chain. The second route, specific to GitLab, is to keep the software but self-host GitLab Community Edition on EU infrastructure, which removes direct US exposure while preserving the exact feature set.

So what actually carries over from a GitLab.com account?

• Git repositories with full branch and tag history (portable by design).
• Issues, merge requests (imported as pull requests), labels, milestones, and releases.
• Code review with inline comments and branch protection rules.
• Hosted CI/CD (Codeberg CI on Woodpecker, or Codebahn's EU runners).
• Package registry and container registry.
• Webhooks and a REST API for your own integrations.

Not everything makes the trip, though:

• GitLab's full DevOps platform. Built-in security scanning (SAST, DAST, dependency and container scanning), the value-stream analytics, and the tightly integrated compliance features are broader than the Forgejo-based forges cover. This is the main reason some teams choose to self-host GitLab CE instead.
• GitLab CI/CD syntax. The CI concepts carry over, but .gitlab-ci.yml pipelines need translating to Woodpecker or the Codebahn CI format.
• GitLab-specific integrations. Marketplace and one-click integrations built for GitLab may need webhooks or API wiring on a smaller forge.
• Group and sub-group hierarchy. GitLab's deep nested-group model maps onto organisations and teams on the alternatives, but very large, deeply nested structures may need flattening.

Moving off GitLab.com comes down to a handful of steps, whichever destination you pick.

1. Decide between a European forge and self-hosted GitLab CE first. If your team depends on GitLab's security-scanning and DevOps breadth, self-hosting GitLab CE on EU infrastructure keeps the feature set; if you mainly use the core forge workflow, a Forgejo-based service is lighter to run.
2. Use the Forgejo migration importer. For Codeberg or Codebahn, the "New Migration" flow accepts a GitLab source URL and access token and pulls the code plus issues, merge requests, labels, milestones, and releases in one pass. A bare git push --mirror covers a code-only move.
3. Translate your CI pipeline. Convert .gitlab-ci.yml into a Woodpecker pipeline (Codeberg) or the Codebahn CI format, and replace GitLab-specific job templates with equivalent steps.
4. Re-point clones, runners, and integrations. Update each developer's git remote set-url, register new CI runners where needed, and re-point deployment webhooks and bots to the new forge's API.
5. Reissue tokens and CI/CD variables. Secrets and deploy keys do not migrate; recreate them on the destination and rotate anything that was exposed.
6. Keep the GitLab project as a read-only mirror for 60 days. Archive rather than delete, so CI jobs elsewhere, package pulls, and documentation links do not break silently during the cutover.