Best European Alternatives to GitLab.com

Why people leave GitLab.com

Leaving GitLab.com is not the same argument as leaving GitHub, and a page that runs the usual script here is not paying attention. GitLab is open core: you can read the code, and you are allowed to run the same platform yourself. The complaint cannot be that the software is a black box.

What you are leaving is the tenancy. GitLab.com is one enormous shared installation operated by GitLab Inc. from San Francisco, and its infrastructure sits in the United States — instance runners deploy into Google Cloud in us-east1, GPU and Arm64 runners in us-central1, and macOS runners on AWS in us-east-1. Your pipelines run there whatever your own address says.

GitLab does sell a European shape of itself, and it is worth knowing what it is before you go shopping. GitLab Dedicated is a single-tenant instance in the AWS region you pick, it requires the Ultimate tier, and it arrives through a sales conversation rather than a settings page. For a great many teams that is the correct answer. For everyone else, the honest question is whether they wanted a DevOps platform at all, or just a good forge.

• One tenancy, one operator, one country Multi-tenancy is the whole economy of GitLab.com, and it is also the thing you cannot configure your way out of. There is no region selector on the free or Premium plans, the shared runners execute your jobs on American infrastructure, and the operator is a US company. Nothing here is hidden or unusual; it is simply not adjustable, which is different from how GitLab feels when you read about the self-managed edition.
• The European answer is a tier and a contract GitLab Dedicated puts a single-tenant instance in an AWS region of your choosing, which genuinely answers the residency question. It requires Ultimate, the most expensive tier, and a conversation with an account team about your expected number of users. A ten-person team that wants its repositories in Frankfurt is not the customer that product was designed for, and will be quoted accordingly.
• The limits appear on the way out GitLab.com caps a repository at 10 GB, an import at 5 GiB and an export at 40 GiB. Nobody notices those numbers while they are using the service; everybody notices them on migration day, when a group export refuses to complete. If you are even considering a move, test an export of your largest group first, because that is the step that decides your timetable.
• The platform keeps growing into your workflow GitLab's documentation is explicit that a new customer on GitLab 18.0 or later has GitLab Duo Core automatically turned on, with no action needed; switching it off is a setting you have to go and find, at instance, group or project level. That is a defensible default and it is also the pattern: capability arrives switched on, and staying deliberate about it becomes a standing administrative task rather than a one-off choice.

What you have to replace, not just match

Be honest about the shortest path first: if the platform is fine and the tenancy is the problem, the least disruptive move is self-managed GitLab on your own European infrastructure. Same product, same pipelines, same imports, and no supplier between you and the repositories. This page does not rank it because it is not a different supplier, but it is a legitimate answer and plenty of teams should take it.

The forges below are for the other realisation, the one that arrives after pricing the hardware: that what you used was repositories, merge requests, issues and a bit of CI, and you were paying in weight for a portfolio and security suite nobody opened. A GitLab installation wants real memory and regular attention. Gitea and Forgejo want a small virtual machine.

Then separate the pieces GitLab bundled. The container registry can move to a registry, the packages to a package host, the wiki into a repository, the security scanning into whatever your CI already runs. Once they are separate, most of them turn out to be replaceable individually, which is why leaving GitLab is usually less frightening than leaving a platform that never unbundled.

The alternatives compared

How each alternative compares to GitLab.com

What actually breaks when you switch

Test the export first, and test it on the biggest thing you own. GitLab.com caps exports at 40 GiB and imports at 5 GiB, and a group that has accumulated artefacts, packages and years of merge requests can run into that. Finding out in week one changes the plan; finding out on cutover weekend changes the weekend.

Expect the pipelines to be the whole project. GitLab CI has no translator to Actions, Woodpecker or build manifests, and the features that made it pleasant — includes, rules, needs, parent-child pipelines — are exactly the ones with no counterpart. Estimate that work by reading your .gitlab-ci.yml files, not by counting repositories.

And watch for what quietly held the estate together: the container registry, package registries, environments and deployment approvals, and the tokens wired into cloud accounts. Each is replaceable on its own; together they are the reason a migration that looked like a fortnight takes a quarter. List them from the project settings before anyone announces a date.

If GitLab is open source, why move at all?

Because open source answers a question about the software and not about the service. You can read GitLab's code, audit what it does and run it yourself — none of which changes the fact that on GitLab.com the instance is operated by a US company on US infrastructure, with no region for you to choose.

That is why the open-core argument cuts in an unusual direction here. The right response to disliking GitLab.com is often not a different forge at all; it is the same software on your own hardware, which the licence explicitly permits.

The forges on this page are the answer to a different sentence: "we ran the numbers on self-hosting GitLab and it is more platform than we want to own." That is a legitimate conclusion, and it is the one this page is written for.

What does GitLab Dedicated actually give me?

A single-tenant instance, fully isolated, hosted and maintained by GitLab in the AWS region you select, with high availability and disaster recovery included. For an organisation that wants GitLab and needs its data in a specific place, that is the product and it works.

The conditions are the tier and the conversation. Dedicated is Ultimate-only, and setup runs through an account team that asks for your expected number of users rather than presenting a price on a page. You will hear seat minimums quoted in forums; GitLab's own documentation does not state one, so treat any specific number you read as hearsay until your account manager confirms it.

Worth noting for the same audience: a new customer on GitLab 18.0 or later gets GitLab Duo Core turned on automatically, and the documentation sets out how to turn it off at instance, group or project level. If an AI usage policy or a residency review stands in the way of that default, make it part of the provisioning checklist rather than a discovery later.

How much of my GitLab setup survives a move to a lighter forge?

Repositories, branches, tags and issue text survive comfortably; Gitea and Forgejo both have importers that pull a project across the API, including issues, labels and milestones, and Codeberg runs Forgejo so the same import applies.

Merge request history degrades. Discussion threads, approvals and the exact review state are GitLab objects, and what lands on the other side is a readable record rather than a faithful copy.

The pipelines are rewritten. GitLab CI does not convert to Forgejo or Gitea Actions, and the further you have gone into includes, parent-child pipelines, rules and needs, the less of it maps onto anything. Teams with a heavy CI estate should think hard about self-managed GitLab instead, because that is the only move where the pipelines come with you.

Is a small forge really enough for a professional team?

For repositories, review and issue tracking, yes, and it has been for years. The parts people genuinely miss are narrower than the feature list suggests: the container registry, the built-in security scanning, and the environments and deployment views.

The registry is easy to replace, and a European registry in the same region as your cluster is usually faster than the one you had. Scanning is the honest gap — GitLab bundles SAST, DAST and dependency scanning into its top tier, and on a small forge you assemble that yourself from open tooling in CI. That is achievable, and it is work.

The test that settles it is not a feature comparison. Look at what your team opened in GitLab last month. If it was merge requests and issues, a forge is enough; if it was security dashboards and value stream analytics, it is not.

Which one to pick

If the platform suits you and the tenancy does not, run GitLab yourself on European infrastructure. It keeps the pipelines, the imports and the habits, and it is the only option that changes nothing except who holds the machine. That it is not one of the four ranked here is a consequence of this being a page about alternatives, not a judgement about the move.

If you have concluded that the platform was more than you needed, Forgejo is the one to install and Gitea is the one to install when somebody needs a support contract attached. Both are small enough that the hosting bill stops being an argument against leaving.

If the work is open source, Codeberg is the best home on this page and the one that removes the operator question instead of relocating it — as long as you can live with shared CI and a strictly free-software policy.

And if you are on GitLab Ultimate for the security suite, or your pipelines are a decade of accumulated CI, the responsible advice is to price GitLab Dedicated in a European AWS region before you price anything on this page. It answers the residency question completely, and for that estate it is usually cheaper than rebuilding.