Gitea vs GitLab: Which Self-Hosted Git Forge on a VPS?

A self-hosted Git forge keeps your intellectual property off public platforms and removes any arbitrary limit on the number of private repositories, collaborators, or CI minutes. On a VPS, you control data location, backups, and integration with your internal pipeline. Gitea (and its fork Forgejo) is written in Go: a single binary, instant startup, minimal memory footprint, ideal for a modest VPS. GitLab CE is an integrated suite (issues, CI/CD, Docker registry, package registry, wiki, environments) but consumes far more RAM. The choice depends on your need: a clean, fast Git, or a complete DevOps platform in a single product.

Gitea is released under the MIT license: you can read the code, modify it, redistribute it, and host it without commercial restrictions. Forgejo, its community fork born in 2022, applies the same license. GitLab CE is also MIT — but only the Community Edition layer. GitLab EE (Enterprise Edition) is proprietary: premium features (advanced SAML SSO, multiple MR approvals, integrated SAST/DAST, epics, roadmaps) are locked behind a paid subscription starting at several hundred euros per user per year. For a team self-hosting GitLab CE, the main risk is not the license itself but the upsell effect: missing CE features progressively push toward paid EE. With Gitea or Forgejo, all available features are included in the free version with no paid tier. If license compliance or audits matter in your context — public administration, government contracting, or enterprise accounts — this difference is structural.

Gitea uses roughly 100 to 150 MB of RAM at idle in a standard Docker deployment with PostgreSQL. With about ten active runners and a few simultaneous pipelines, you stay under 400 MB for the forge itself — easily fits on a 2 GB RAM VPS while leaving room for the OS and database. GitLab CE in omnibus is in a different league: PostgreSQL, Redis, Sidekiq, Gitaly, Puma, and NGINX all run in parallel. At idle, the stack commonly exceeds 3 to 4 GB of RAM on a fresh deployment and can climb to 6 to 8 GB under CI load. GitLab officially recommends 8 GB of RAM for production use with CI enabled. On the CPU side, Gitea is nearly invisible at idle; GitLab triggers background Sidekiq processes (indexing, webhooks, cleanups) that consume CPU intermittently even with no visible activity.

Gitea Actions appeared in Gitea 1.19 (2023) and reuses exactly the GitHub Actions workflow syntax: existing .github/workflows/*.yml files are reusable without modification in most cases. The underlying executor is act (the open-source engine that simulates GitHub Actions locally), wrapped in a Docker runner. This is sufficient for the majority of pipelines: build, test, lint, image push, SSH deployment. Limitations appear on advanced cases: no shared caches across runners at scale, no native review environments, more limited artifact management. GitLab CI is more mature on these points: distributed runners across multiple machines, Kubernetes executors, shared caches, dynamic environments, review apps, inline test report pages, powerful rules: and include: directives. If your pipeline goes beyond a dozen parallel jobs, manages per-MR review environments, or requires integrated SAST/DAST in the merge report, GitLab CI is irreplaceable in its CE version (for CI/CD itself — SAST remains EE). The practical rule: Gitea Actions is sufficient for teams of 1 to 20 developers with standard pipelines; GitLab CI becomes necessary when pipeline maturity is itself a selection criterion.

CVE-2026-85706 is a Server-Side Request Forgery (SSRF) vulnerability discovered in GitLab CE and EE affecting versions prior to the March 2026 patch. It allows an authenticated attacker to force GitLab to make HTTP requests to internal network resources via the remote repository import feature. On a VPS where GitLab shares the internal network with other services (databases, registries, APIs), the exposure is real. Gitea is not affected by this specific CVE — its remote import code is separate. The GitLab to Gitea migration is documented and covered by gitea-migration-tool: it imports repositories, issues, labels, milestones, pull requests, and comments from the GitLab API. CI/CD pipelines do not migrate automatically (GitLab CI syntax differs from Gitea Actions), but for teams using GitHub-Actions-close syntax in their GitLab CI, the conversion is lightweight. If you are running an unpatched version of GitLab CE on an exposed VPS, migrating to Gitea or urgently upgrading are the only reasonable options.

Gitea is frugal: 1 vCPU and 1 GB of RAM are enough for a small team, 2 GB with the database and a few runners. GitLab CE is far more demanding: aim for at least 4 GB of RAM (8 GB recommended in real-world use with CI), 4 vCPUs, and a fast disk, since the suite bundles PostgreSQL, Redis, Sidekiq, and Gitaly. In both cases you need Docker and Compose, a subdomain (git.yourdomain.com), a reverse proxy for TLS, and ideally a second subdomain if you enable the Docker registry. Plan for a dedicated volume for the repositories and a backup strategy.