Gitea vs Forgejo vs GitLab CE in 2026: Picking the Git Forge Behind Your Deploy Pipeline

In May 2026, the Dutch government launched its own git forge to keep public-sector source code out of US-controlled infrastructure. Three months earlier, Gentoo Linux set up an official presence on Codeberg after GitHub started pushing mandatory Copilot integration. Meanwhile, a homelab operator somewhere is running their entire git hosting on a $6-a-month VPS with RAM to spare. All three made a rational choice — and they didn't all pick the same forge.

TL;DR: If your deploy pipeline mostly needs webhooks and a fast clone, run Gitea or Forgejo on a small VPS and stop thinking about it. Pick Forgejo for nonprofit governance and federation bets, Gitea for the MIT license and paid-support ecosystem. Only reach for GitLab CE when its bundled DevSecOps suite replaces tools you'd otherwise pay for separately.

The rest of this post earns that table: real RAM numbers, the fork story that split the lightweight camp, what each CI/runner stack actually gives a pipeline, and the cost math that flips the answer above a certain team size.

The 8x RAM Gap, With Real Numbers​

Specs sheets undersell this. Here is what each forge actually consumes, drawn from project docs, third-party benchmarks, and operator reports in 2026:

The headline "8x" is, if anything, generous to GitLab: 1 GB versus 8 GB at the minimum line, and more like 30–50x at idle (150 MB versus 5.5 GB). Gitea's own docs put idle usage at 50–150 MB, and r/Gitea and r/raspberry_pi operators corroborate running comfortably on 512 MB–1 GB boards for a year of continuous uptime. Forgejo shares the same Go architecture from the fork, so capacity planners treat the two as interchangeable — Codeberg's scaling notes describe hundreds of thousands of users served by horizontal multi-node deployment, not GitLab-style vertical beef per instance.

GitLab's footprint isn't waste; it's a different product. Past a few hundred users its own reference architecture splits Gitaly (git storage), Sidekiq (background jobs), and PostgreSQL onto dedicated nodes. You're not comparing three git servers — you're comparing two git servers against a distributed system that happens to include git. Budget accordingly: a Gitea or Forgejo container runs indefinitely on a $6 VPS, while a serious GitLab CE deployment starts at a 16 GB node and grows into multi-node topology with monitoring to match.

The Fork in 90 Seconds​

Gitea and Forgejo were the same codebase until governance broke them apart. In October 2022, a for-profit company (Gitea Ltd.) took over the Gitea trademark and domain without community consent. Contributors soft-forked as Forgejo the same month; in February 2024, after Gitea 1.21, it became a hard fork free to diverge. Forgejo relicensed to GPLv3+ with v9.0 in August 2024. The practical cutoff: drop-in Gitea-to-Forgejo upgrades stopped working after Gitea 1.22, so anyone on 1.23+ faces a real migration, not a binary swap.

Four years on, both projects are healthy — Gitea's stars (~57k), release cadence, and pull volume kept climbing through 2026 alongside Forgejo's — but they've settled into distinct niches:

Two things worth saying plainly. First, the license split cuts both ways: Forgejo's copyleft guarantees the platform can't be quietly re-commercialized, which is exactly why sovereignty-minded adopters prefer it — but shops with no-copyleft procurement policies will pick Gitea's MIT license for the same reason, and that's legitimate. Second, "Forgejo is the default recommendation on r/selfhosted" is true and mostly about values, not features. For a pipeline that needs webhooks and a fast clone, governance is a tiebreaker, not a capability — both forges push bytes identically.

The CI/Runner Layer Your Pipeline Actually Touches​

Here's where the comparison gets pipeline-specific. A deploy pipeline touches a forge in exactly three places: the webhook that fires on push, the clone that fetches code, and optionally the CI runner that builds and tests. Everything else — issue boards, wikis, code review UX — is developer tooling, not pipeline surface. So judge the CI stacks on pipeline terms:

Gitea Actions and Forgejo Actions share GitHub-compatible YAML, so existing .github/workflows files usually migrate with minimal edits. Both have matured fast: Gitea 1.26 added concurrency groups, per-runner pause/disable, and rerun-failed-jobs; Forgejo v15 added OIDC tokens, concurrency blocks, matrix jobs, and scheduled runs. The runner model is the same on both — a lightweight external binary (act_runner for Gitea, forgejo-runner for Forgejo) that connects outward to the instance, so runners live on disposable machines and scale horizontally without touching the core app. Gitea shipped Runner 3.0.0 in July 2026; Forgejo shipped Runner 13.0.0 in August.

Where they differ in 2026 is at the edges: Forgejo's v16 line adds HTTP APIs for Actions artifacts and workflow/job logs plus "Authorized Integrations" — OIDC-style JWT federation that lets external systems (GitHub Actions, GitLab CI, AWS) authenticate during a hybrid migration window instead of forcing an all-or-nothing cutover. Both mint per-job OIDC tokens and support ephemeral or capacity-based single-job runners, which matters the moment a runner touches untrusted PRs.

GitLab CI/CD is in a different league and it shows: first-class multi-stage pipelines, mature runner fleet management with tagging and Kubernetes/cloud autoscaling, a built-in container and package registry, and SAST plus dependency scanning wired into the pipeline natively. Nobody disputes the depth. The question is whether your pipeline uses it. If your CI is "lint, test, build image, push, trigger deploy," the lightweight forges cover it with a fraction of the moving parts — and if you already run Jenkins or external runners, the forge-native CI may be redundant entirely.

The honest pipeline test: if your deploy flow is webhook → clone → build → push, all three forges are overqualified at the webhook and clone steps, and the lightweight two are sufficient at the build step for most teams. GitLab earns its footprint when the pipeline itself needs what only it bundles — integrated security scanning gates, compliance attestations, or fleet autoscaling you don't want to build.

Federation: The Feature That Doesn't Matter (Yet)​

Forgejo is building ActivityPub-based federation (the ForgeFed effort): cross-server issues, pull requests, and stars across independent instances. Gitea has nothing planned; GitLab has nothing either. It's the single most distinctive item on Forgejo's roadmap — and it currently matters zero percent to a deploy pipeline.

Say that plainly because roadmap slides won't: federation, even when it ships, addresses collaboration between humans on different servers, not machine-to-machine pipeline traffic. No webhook payload, runner protocol, or clone path changes when two forges federate. It could matter someday if your workflow spans organizations that each self-host (think upstream/downstream distro collaboration, or a vendor contributing across company boundaries), and it's a genuine differentiator for the Codeberg ecosystem. But nobody should pick a forge in 2026 for CI reasons based on federation. Treat it as a call option on future collaboration patterns, priced into Forgejo for free — nice to hold, wrong to pay extra for, and you're not paying extra.

The Cost Math​

All three cores are free to self-host. The money is in seats and infrastructure, and the gap compounds fast:

A 50-person engineering org on GitLab Premium pays roughly $1,450/month at list before provisioning a single gigabyte of the 16 GB-plus deployment. The same team on a lightweight forge pays for a VPS whose bill barely moves between 10 and 100 people. But the math flips when consolidation enters: if GitLab's bundled SAST, container scanning, and compliance reporting replace two or three paid point tools, the per-seat fee can be cheaper than the stack it displaces plus the integration labor. That's the only honest pro-GitLab cost argument, and it only pencils out above a certain team size with dedicated platform budget. Below that line, you're paying enterprise prices for pipeline steps a webhook already handles.

Proof It's Real​

The 2026 migration stories sort neatly by motive, and none of them were decided on feature checklists:

• The Netherlands government (Forgejo). In May 2026, code.overheid.nl launched as a sovereign Forgejo instance, free for any Dutch government organization, built explicitly to keep public code under domestic jurisdiction. Migration tooling around it handles repos, issues, PRs, labels, releases, and wikis as one-time imports or continuous GitHub mirrors.
• Gentoo Linux (Forgejo via Codeberg). In February 2026, Gentoo announced an official Codeberg presence, with maintainers citing GitHub's push toward mandatory Copilot integration as a factor. A major distro moving its social-coding surface off GitHub was 2026's clearest signal that forge choice is now a governance decision.
• Codeberg itself (Forgejo at scale). The largest public Forgejo instance grew from ~300k repos and 200k users (Nov 2025) to 650k+ projects and 390k+ users by June 2026 — proof the lightweight architecture scales to public-internet load, not just private teams.
• Homelab Gitea. The modal 2026 deployment story on Reddit: one Raspberry Pi or $5 VPS, SQLite or MySQL backend, a handful of repos, under 1 GB RAM, running indefinitely. Unremarkable is the point.
• Enterprises on GitLab Ultimate. Orgs with platform teams and SAST/DAST/compliance mandates keep consolidating on GitLab precisely because one suite replaces four or five tools — accepting the heaviest infra and seat bill of the three as the price of that consolidation.

Each decision was rational in context. The Dutch government bought jurisdiction and governance. Gentoo bought independence from a Copilot-mandating platform. Enterprises buy consolidation math. Homelabs buy simplicity. "Best overall" is the wrong frame; fit-to-motive is the whole game.

The Decision Guide​

If you've skimmed everything above, here's the short version as rules:

1. Default to a lightweight forge. For webhook → clone → build pipelines, Gitea and Forgejo are sufficient, and the 8x RAM gap plus zero seat cost dominate every other consideration.
2. Forgejo when governance is the point. Nonprofit steward, copyleft license, patches for everyone simultaneously, yearly LTS supported into 2027. The r/selfhosted default for good reason.
3. Gitea when permissive licensing or paid support matters. MIT license for strict procurement, Gitea Enterprise/Cloud when you want an SLA and someone to page. Already running it stably? Stay — migration buys values, not velocity.
4. GitLab CE when consolidation pays. You have SAST/DAST, registry, and compliance needs that would otherwise be three vendors and a pile of glue. Below that threshold it's a distributed system doing a webhook's job.
5. Ignore federation in the pipeline decision. Revisit when ForgeFed ships something runners can touch.

One last pipeline-specific note: whichever forge you pick, choose PostgreSQL as the backend. All three support it, and it's the one decision that keeps a future forge switch to a data migration instead of a data migration plus a database migration. Your deploy pipeline shouldn't care which forge fires the webhook — and with Postgres underneath, it won't have to.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. It doesn't care which forge fires the webhook either. Star the repo on GitHub or deploy your first app today.