Self-hosting GitLab
Keeping your source, your CI and your container registry on your own hardware means your release pipeline does not stop when someone else has an outage — and your code never leaves Amsterdam.
GitLab is not a small application. The Omnibus package bundles PostgreSQL, Redis, Sidekiq, Puma, Gitaly, the registry and more into one install. It is the right way to run it, but you must give it room.
Size it honestly
For a real team, plan on 8 GB of RAM as a floor and 16 GB if you enable the container registry and CI. GitLab will start on 4 GB and then swap itself to death under the first pipeline — see when memory runs out. CPU matters less than RAM and fast storage; put the repositories on NVMe.
Install the Omnibus package
Add the package repository for your distribution, then install the gitlab-ee (or gitlab-ce) package with your external URL baked in:
EXTERNAL_URL="https://git.example.com" apt install gitlab-ee
That one variable sets the URL GitLab uses everywhere. Change it later and you edit /etc/gitlab/gitlab.rb and run gitlab-ctl reconfigure.
Keep runners off the box
Never run CI jobs on the GitLab server itself. A runaway build will starve the application. Put runners on a second machine — see self-hosted CI runners — and register them against your instance.
TLS and the registry
GitLab can request Let’s Encrypt certificates itself, but the container registry needs its own hostname and certificate. Decide the registry URL before you turn it on; moving it afterwards means re-tagging every image.
Backups are a command, restores are a habit
gitlab-backup create
That captures repositories, database and uploads — but not /etc/gitlab/gitlab-secrets.json, and without those secrets a restored backup cannot decrypt stored tokens. Copy that file somewhere safe separately, and rehearse a restore onto a staging server before you need one.
Still stuck? Mail support@novogara.com — an engineer answers, at any hour. Back to the knowledge base