Forgejo vs GitLab CE on a Small VPS: RAM, CI Runners and the Upgrade Treadmill

There comes a point where hosting your own Git server stops being an idea and becomes a small invoice. You pick a VPS, usually the cheap tier with 2 or 4 GB of RAM, and you choose what to run on it. For most people, that choice comes down to GitLab Community Edition, the full-featured platform that companies run, or Forgejo, the lightweight forge forked from Gitea.

I have run both on small virtual servers, upgraded both through several major versions, and restored both from backup after mistakes I would rather not repeat. On a small VPS, the decision mostly comes down to three things: how much memory each one needs before you push a single commit, what CI looks like, and how much of your life the upgrades will take.

Forgejo for small servers, GitLab for 8 GB and up

On a VPS with 2–4 GB of RAM, run Forgejo. It is a single lightweight service that leaves room for everything else, its upgrades are routine, and it covers what most individuals and small teams actually use: repositories, pull requests, issues, packages and Actions-style CI.

Run GitLab CE if you have 8 GB of RAM or more to give it, you need its deeper CI/CD and project-management features, or your team already works in GitLab and you want the same tool at home. It is a superb platform. It is just not a small one.

A lightweight forge and a DevOps platform

Forgejo is a community-run fork of Gitea, created in 2022 and stewarded by the non-profit behind Codeberg. It is written in Go and ships as a single binary or container image. It covers the familiar forge features: repositories, pull requests, code review, issues, wikis, releases, a package registry, and Forgejo Actions, a CI system whose workflow files closely follow GitHub Actions. It can use SQLite for small installs or PostgreSQL and MySQL for larger ones.

GitLab CE is the open-source edition of GitLab, a complete DevOps platform. The standard install, the Omnibus package, bundles a lot: the Rails application, PostgreSQL, Redis, background workers, Gitaly for Git storage, NGINX, and monitoring components. Beyond what Forgejo offers, it has a mature CI/CD system with pipelines, environments and a built-in container registry, plus more extensive project planning tools. Some advanced features are reserved for paid editions, but CE is still a very complete platform.

Memory: the decision on a small VPS

This is the part that settles most choices before features come into it.

Forgejo is light. A personal or small-team instance with SQLite or a small PostgreSQL database sits comfortably in a few hundred megabytes of RAM. On a 2 GB VPS, it leaves most of the machine free for a reverse proxy, backups, and whatever else you want to run.

GitLab is heavy by design, because it runs many services at once. Its own documentation sets a minimum of around 4 GB of RAM and recommends swap, and that minimum is the floor rather than a comfortable place to live. On 4 GB it runs, but slowly, especially the web interface right after a restart. With 8 GB it feels like the GitLab you use at work. You can tune it down by reducing the web and background worker counts and turning off bundled monitoring, and people do run it on 4 GB that way. But you are fighting the software’s defaults, and every upgrade can bring new memory demands.

On a 2 GB VPS, GitLab is simply not an option. On a 4 GB VPS, it is possible if GitLab is the only thing on the machine. On 8 GB, it is fine.

CI runners: do not run them on the same box

Both platforms run CI jobs through a separate runner process: GitLab Runner for GitLab, and the Forgejo runner for Forgejo Actions. In both cases the forge only schedules the work; the runner does the building.

The most common mistake on a small VPS is putting the runner on the same machine as the forge. A build that compiles code or builds a container image uses all the CPU and memory it can get, and on a small server that starves the forge itself. With GitLab, which is already near its memory limit, a single heavy build can push the whole machine into swap.

The better setup for either one is a runner on a different machine: an old desktop at home, a mini PC, or a cheap second VPS. The runner connects out to the forge, so the build machine does not need a public address. Forgejo’s runner is easy to set up for this, and so is GitLab Runner. The real cost is the machine you now have to look after, which is worth weighing before you decide you need CI at all. A lot of personal repositories never do, and what people mean by “self-hosted GitHub” is often just a place to push code, not a CI farm.

Feature-wise, GitLab CI is more mature: richer pipeline logic, environments, review apps, and years of documentation and examples. Forgejo Actions is newer, but the GitHub Actions-style syntax means many existing workflows need few changes, and for building, testing and deploying small projects it does the job well.

Upgrades: the hidden monthly bill

Self-hosting a forge is not a one-off install. It is a commitment to keep it updated, because a Git server facing the internet with known security holes is a liability.

Forgejo upgrades are uneventful. You stop the service, replace the binary or pull the new container image, and start it again. Database migrations run automatically on startup. Major versions arrive a few times a year with release notes worth reading, but the process stays the same. Back up first, as with any upgrade, but expect it to take minutes.

GitLab releases a new version every month, plus regular security patches. Most upgrades are smooth with the Omnibus package, but GitLab has required upgrade stops: if you fall behind, you cannot jump straight to the latest version. You have to upgrade step by step through specific versions, letting background migrations finish at each stop. Ignore a self-hosted GitLab for six months and catching up can become an evening’s work. Stay current and it is manageable, but it is a monthly chore you sign up for.

For a small team where nobody’s job is to look after the Git server, that difference matters more than any feature list.

Features you might actually miss

GitLab’s advantages are real, and for some people they decide it:

• CI/CD depth. Multi-stage pipelines, environments, deployment tracking and a large ecosystem of examples.
• Project management. Issue boards, milestones and planning tools that go further than Forgejo’s.
• Familiarity. If your team uses GitLab at work, the same interface at home or for a side business saves relearning.
• Integrated tooling. Container registry, package registry, wikis, and security scanning features in some tiers, all in one place.

Forgejo’s advantages are mostly about what it does not demand: little memory, simple upgrades, an interface that feels like GitHub, easy backups, and a community-governed project with a copyleft licence. It also offers repository mirroring, so you can mirror to or from GitHub, and work on federation between forges, which may matter more in a few years.

If you are deciding between Forgejo and its relatives rather than against GitLab, the Gitea vs Forgejo vs GitHub comparison covers that choice.

Backups and moving later

Both can be backed up, but they differ in effort. A Forgejo backup is the data directory, the repositories and the database. With SQLite, it is essentially one folder. Restoring onto a fresh server is quick and easy to test.

GitLab has a built-in backup command that produces an archive of repositories and the database, but configuration files and secrets must be backed up separately. Forget the secrets file and parts of your restored instance, such as CI variables and two-factor settings, will not work. It is well documented, but it has more moving parts, and you should test a restore at least once before you need one.

Moving between them later is possible. Forgejo can import repositories, issues and pull requests from GitLab, so starting small with Forgejo does not lock you in, and starting with GitLab does not stop you leaving.

Sizing the forge to the server

Forgejo is the right size when:

• Your VPS has 2–4 GB of RAM, or you want the forge to share the machine with other services.
• You want upgrades that take minutes and backups that are one folder.
• Your CI needs are build, test and deploy for small projects.
• You prefer a lightweight, community-governed project with a GitHub-like feel.

GitLab CE is worth its weight when:

• You can give it 8 GB of RAM, or a whole 4 GB VPS with careful tuning.
• You need GitLab CI’s depth, environments, and deployment tracking.
• Your team already uses GitLab and wants the same tool.
• Someone is willing to keep up with monthly upgrades.

For a personal forge or a small team on a cheap VPS, Forgejo is the sensible default: it does what you need and leaves the machine, and your evenings, mostly free. GitLab earns its weight when you need what only it does, and when you have the hardware and the time to keep it running.