Layer 5 · self-hosting reality check
What it actually takes to self-host GitLab Community Edition
The docs say 8 GB for a memory-constrained single node; 16 GB is the stated baseline. A separate tuning guide runs it on 2 GB plus 1 GB swap for up to 5 developers, with degraded performance. In practice you want 16 GB, the vendor's single-node baseline. 8 GB can carry 5–20 people if you disable the bundled Prometheus and trim Sidekiq and Puma as the memory-constrained guide describes. Here is the honest version — real requirements, real monthly cost, what you will be maintaining, and the one thing that catches people out.
Usually reached from GitHub alternatives, where GitLab Community Edition is one of the picks.
Wondering whether you need to at all? Is GitHub free? — what the free tier actually allows, and where the wall is.
| RAM — documented minimum | 8 GB for a memory-constrained single node; 16 GB is the stated baseline. A separate tuning guide runs it on 2 GB plus 1 GB swap for up to 5 developers, with degraded performance |
|---|---|
| RAM — what it really needs | 16 GB, the vendor's single-node baseline. 8 GB can carry 5–20 people if you disable the bundled Prometheus and trim Sidekiq and Puma as the memory-constrained guide describes |
| CPU | 8 vCPU is the vendor's single-node baseline; burstable instances are not recommended |
| Disk | 40 GB for the application (the package alone is about 2.5 GB), 5–12 GB for PostgreSQL, plus at least the combined size of all repositories. Use SSD and avoid NFS or EFS. CI artifacts, container images and backups are what fill it. |
| Monthly cost | $48–96/mo for a 5–20 user instance on a 16 GB / 8 vCPU VPS ($24–48 on the 8 GB constrained setup), plus separate runner machines for CI |
| Setup time | 1 hour to install the package; a day to get email, TLS, backups and a runner right |
| How you install it | The Linux package (Omnibus), one install that bundles PostgreSQL, Redis, Gitaly, Puma, Sidekiq, NGINX and Prometheus. You configure it in /etc/gitlab/gitlab.rb and apply changes with gitlab-ctl reconfigure. Docker and Helm installs also exist. |
| Ongoing maintenance | A minor release every month (on the third Thursday) and patch releases twice a month. Security fixes reach only the current minor and the two before it. Major versions also move the bundled PostgreSQL: GitLab 19 requires PostgreSQL 17. |
| Where it stops scaling | One well-sized node goes a long way. Beyond it, GitLab publishes reference architectures that split Gitaly, PostgreSQL, Redis and Sidekiq onto separate nodes sized by load. |
The thing that catches people out
GitLab cannot be upgraded in one jump. Since 17.5, every major has required upgrade stops at x.2, x.5, x.8 and x.11. Each stop's background migrations must finish before you move on to the next. Fall a year behind and you face four or more upgrades in a row, each waiting on migrations, on the one server your team pushes to. Upgrade every month, or at least at every stop. Confirm background migrations have finished before each hop, and take a backup first.
When not to self-host GitLab Community Edition
You are a small team that needs Git hosting, code review and light CI. GitLab CE asks for a 16 GB, 8-core server and monthly upgrades. Forgejo does the same job on a 2 GB box, and GitLab.com gives you GitLab without running it yourself.
Every guide here carries this section. A site that only ever tells you to self-host is selling something — the useful answer is sometimes no.
Other Layer 5 self-hosting guides
- Self-hosting LibreOffice2 GB with a large spreadsheet open
- Self-hosting ONLYOFFICE6 GB for the Document Server with a handful of concurrent editors
- Self-hosting Collabora Online4 GB, and roughly 1 GB per 20 concurrent documents
- Self-hosting CryptPad2 GB for a small instance
- Self-hosting Mattermost4 GB for a team of 50 with PostgreSQL on the same box
- Self-hosting Rocket.Chat6 GB with MongoDB on the same machine
Common questions
- How much RAM does GitLab Community Edition actually need?
- 16 GB, the vendor's single-node baseline. 8 GB can carry 5–20 people if you disable the bundled Prometheus and trim Sidekiq and Puma as the memory-constrained guide describes in practice. The documented minimum is 8 GB for a memory-constrained single node; 16 GB is the stated baseline. A separate tuning guide runs it on 2 GB plus 1 GB swap for up to 5 developers, with degraded performance, which is the figure at which the process starts rather than the figure at which it works under real use. 8 vCPU is the vendor's single-node baseline; burstable instances are not recommended alongside it.
- What does self-hosting GitLab Community Edition cost per month?
- $48–96/mo for a 5–20 user instance on a 16 GB / 8 vCPU VPS ($24–48 on the 8 GB constrained setup), plus separate runner machines for CI This is commodity VPS pricing and excludes your time, which is the larger cost for most people — budget for a minor release every month (on the third Thursday) and patch releases twice a month. Security fixes reach only the current minor and the two before it. Major versions also move the bundled PostgreSQL: GitLab 19 requires PostgreSQL 17.
- How long does it take to set up GitLab Community Edition?
- 1 hour to install the package; a day to get email, TLS, backups and a runner right, via The Linux package (Omnibus), one install that bundles PostgreSQL, Redis, Gitaly, Puma, Sidekiq, NGINX and Prometheus. You configure it in /etc/gitlab/gitlab.rb and apply changes with gitlab-ctl reconfigure. Docker and Helm installs also exist..
- When should I NOT self-host GitLab Community Edition?
- You are a small team that needs Git hosting, code review and light CI. GitLab CE asks for a 16 GB, 8-core server and monthly upgrades. Forgejo does the same job on a 2 GB box, and GitLab.com gives you GitLab without running it yourself.
- What is the most common mistake when self-hosting GitLab Community Edition?
- GitLab cannot be upgraded in one jump. Since 17.5, every major has required upgrade stops at x.2, x.5, x.8 and x.11. Each stop's background migrations must finish before you move on to the next. Fall a year behind and you face four or more upgrades in a row, each waiting on migrations, on the one server your team pushes to. Upgrade every month, or at least at every stop. Confirm background migrations have finished before each hop, and take a backup first.