GitLab CE vs Gitea
Pick Gitea — repositories, pull requests, issues, a package registry and an Actions runner on 512 MB, in one container, MIT the whole way down. Pick GitLab CE when you genuinely want one system for repositories, merge requests, CI/CD, a container registry and Pages, and you accept the bill: upstream documents 16 GB as the single-node baseline and 8 GB as the memory-constrained floor, first boot takes minutes, and merge request approval rules, epics and advanced search sit behind Premium while dependency scanning and compliance need Ultimate.
Side by side
This is the widest gap in the code-hosting catalogue, and it is not a gap in quality. GitLab CE is a whole DevOps platform — repositories, merge requests, issues, a CI/CD runner fleet, container and package registries, Pages — arriving as one install. Gitea is a forge: the place your code lives, with pull requests, issues, a package registry and an Actions runner, in a Go binary that starts in seconds. Both are free to self-host with no user cap. The question is not which is better software. It is whether you want a platform, and whether you have the hardware and the patience a platform costs.
The hardware gap is the headline
Gitea asks for 512 MB. GitLab documents 16 GB as the baseline for a single-node install and says it can run in a memory-constrained environment with at least 8 GB. That is not a tuning difference, it is a different class of machine, and it changes what renting a server for this costs every month for as long as you run it.
The shape of the install follows from the same place. GitLab's Omnibus package —
and the container, which wraps that same bundle — brings PostgreSQL, Redis,
Gitaly, Puma, Sidekiq and NGINX up behind a single gitlab.rb configuration
file. It is genuinely well engineered, and it is genuinely a lot: the image is
enormous, first boot takes several minutes before the server answers, and the
initial root password is written to a file inside the container that is deleted
on the first restart after 24 hours, so you read it early or you reset it. It
also claims port 22 for Git over SSH, which means moving the host's own sshd
before you start. Our catalogue rates it 4 out of 5; upstream also warns
against running the Docker image on Kubernetes, where the Helm chart or the
Operator is the supported path.
Gitea is one container, one volume, SQLite unless you ask for otherwise, and a 2 out of 5. You are pushing to it the same afternoon.
Open core is the other real difference
Both records say MIT, and both are telling the truth about different things.
Gitea is MIT throughout. GitLab's LICENSE file opens with "Portions of this
software are licensed as follows" — everything outside the ee/ and jh/
directories is MIT, client-side JavaScript is MIT, the documentation is CC
BY-SA, and ee/ and jh/ carry their own proprietary licences. The Community
Edition you install is the MIT half.
That matters because the tier boundary runs through features people assume are standard. Merge request approval rules, epics and advanced search need Premium. Dependency scanning and the compliance tooling need Ultimate. Plenty stays free and it is not a stingy free tier — unlimited private repositories, merge requests, issues, CI/CD, container scanning, the container registry and Pages are all in CE — but if approval rules are the reason you are self-hosting a forge, check the tier badge on the documentation page before you provision 16 GB of anything.
What you actually give up by choosing Gitea
Being fair to GitLab: it is not merely a heavier Gitea. What you leave behind is the integration. Issues, merge requests, pipelines, environments, the registry and the registries are one product with one permission model and one place to look, and at organisation scale that coherence is the product. GitLab also covers ground Gitea does not attempt — deployment environments, review apps, and a delivery path that is described in one place instead of five.
With Gitea you assemble. The Actions runner covers builds; anything past that — artifact promotion, environment tracking, deployment approvals — is another tool you choose and wire up. For most self-hosters that is the right trade, because most self-hosters wanted a forge and a build runner. For a team whose process genuinely spans all of it, assembling six tools to avoid one is not a saving.
Which should you self-host?
Pick Gitea if…
- You want a Git server with pull requests and CI, and you would like it to run on a small, cheap box.
- Fully open licensing matters to you, and you do not want to check a tier badge before relying on a feature.
- Nobody's job description includes owning a DevOps platform.
Pick GitLab CE if…
- You want repositories, merge requests, CI/CD, registries and Pages as one system with one permission model, and you will use most of it.
- You have the hardware — 8 GB is the constrained floor, 16 GB is the documented baseline — and a maintenance window habit for upgrades.
- Your team is heading toward the paid tiers anyway, and starting on CE is the on-ramp rather than the destination.
Running either on a VPS
Size for the platform, not for the forge. Gitea is comfortable on the smallest
instance worth renting, with room for a reverse proxy and something else beside
it. GitLab wants its own machine and real disk: give it the 8 GB floor as an
absolute minimum, prefer the documented 16 GB if the instance is doing anything
else, and expect the registry and CI artifacts to grow storage faster than the
repositories do. Upstream recommends disabling swap rather than leaning on it,
which is worth knowing before you pick a plan whose only headroom is swap. Pin a
versioned image tag rather than tracking latest, set external_url to the name
you will actually use, and free up port 22 on the host first. Setup steps and
VPS options are linked below.