Gitea vs GitLab CE

Gitea is a single Go binary that idles around 200 to 300 MB of RAM with SQLite as the backing store. The project's long-standing guidance is that two CPU cores and 1 GB of RAM covers a small team, and people run it happily on a Raspberry Pi 4 or the cheapest tier of any VPS. On a typical homelab box it disappears into the noise next to your other containers.

GitLab is a different animal. The official requirements page now lists 8 vCPU and 16 GB of RAM as the baseline and says memory-constrained setups need at least 8 GB. That is not padding: an untuned Omnibus install idles around 4 GB because you are running Puma, Sidekiq, Gitaly, PostgreSQL, Redis, nginx, and a full Prometheus monitoring stack whether you asked for them or not. GitLab also wants 40 GB of disk for the application node before your repositories take a single byte.

GitLab does publish a memory-constrained tuning guide that gets a single-user instance down to roughly 2.5 GB of RAM plus 1 GB of swap: disable Puma clustered mode (saves 100-400 MB), cut Sidekiq concurrency to 10, turn off Prometheus and the exporters (saves ~300 MB), and tune jemalloc. It works, and their own docs show about 1.7 GB used at rest afterward. But you are running the platform in a configuration its own engineers frame as degraded, and every monthly upgrade risks pushing you back over the line.

The historical reason to eat GitLab's resource bill was CI/CD, and that argument is much weaker in 2026. Gitea Actions shipped in 1.19, has been enabled by default since 1.21, and uses GitHub Actions YAML. You drop workflows into .gitea/workflows, most Marketplace actions (checkout, setup-node, setup-python, cache) run unchanged, and the runner (renamed from act_runner in April 2026) hit version 2.0 in June 2026 with Docker job isolation and an ephemeral mode for hardened setups. The 1.26 release added concurrency groups, per-job retry, and workflow dependency graphs, which were the loudest missing pieces.

It is still not GitLab. There are no merge request pipelines as a first-class concept, no environments with deploy tracking, no review apps, and no multi-project pipeline triggers. But be honest about what your pipelines do. If the answer is run tests, build an image, push it to a registry, and maybe SSH a deploy script somewhere, Gitea Actions does all of that today, and the built-in OCI registry means the image push does not even leave the box.

GitLab CI/CD remains the best self-hosted pipeline system you can run, full stop. A decade of production hardening, .gitlab-ci.yml with includes and DAG-based needs, first-class artifacts and caching, and pipelines wired directly into the merge request workflow. If CI is the actual product you are self-hosting and the Git repo is just where code lives, GitLab is still the stronger tool and the RAM is the price of admission.

A Gitea upgrade is: download the new binary or pull the new image, restart, done in under a minute. Backups are one dump command plus the repositories directory. The June 2026 security release (1.26.3 and 1.26.4 fixed a cluster of CVEs, including an HTTP header trick that granted admin access) is your reminder that lightweight does not mean patch-optional, but patching costs you minutes, not evenings.

GitLab ships a release every month and expects you to keep up. As of July 2026 only 19.1, 19.0, and 18.11 are supported, and 18.11 hits end of support on July 16. Fall a few versions behind and you cannot jump to latest: you must upgrade through required stops in sequence, waiting for background migrations at each one. Omnibus makes each individual hop mostly painless, but it is a recurring chore, and a failed migration on a big instance is a genuinely bad night.

This is the part homelab spreadsheets miss. The RAM line item is visible; the twelve upgrade windows a year are not. If your Git server is infrastructure you want to forget exists, Gitea's operational profile is closer to a static site than a platform.

Gitea is MIT licensed with no feature gates inside the product, but stewardship sits with Gitea Ltd, a for-profit company that took over the trademark and domains in 2022, and there are now paid Cloud and Enterprise editions. That takeover is exactly why Forgejo exists: contributors who wanted community control forked the project under the nonprofit Codeberg e.V., went hard fork in early 2024, relicensed new code under the GPL, and now ship their own LTS line (v15 as of mid 2026) with ActivityPub federation work Gitea does not have. Migration from Gitea to Forgejo is only guaranteed from around the fork point, so pick a lane early rather than late.

GitLab CE is open core. The core is MIT, but the moment you want merge request approval rules, code owners enforcement, protected environments, or most of the security scanning dashboards, you hit the paid wall. For a homelab this rarely bites because the free core is genuinely large. For a growing team it is a slow ratchet that is designed, competently, to convert you into a subscription.