GI

GitLab CE

Complete DevOps platform you can self-host

Git Hosting & Forges ★ 24k stars Hard setup MIT

GitLab Community Edition is a complete DevOps platform covering source control, CI/CD, issue tracking, and container registry. It targets teams wanting an integrated, all-in-one development platform. It is deployed via Docker, Omnibus packages, or Helm.

Key features

  • Integrated CI/CD pipelines
  • Issue boards and milestones
  • Container and package registries
  • Built-in security scanning

Pros & cons

Strengths

  • All-in-one DevOps platform
  • Powerful CI/CD
  • Mature and feature-rich

Trade-offs

  • Resource hungry
  • Complex to operate

GitLab CE replaces

Last reviewed Aug 26, 2026 · 762 words

GitLab CE idles at 3 to 4 GB of RAM on a box doing nothing else, and that number is the decision. It bundles a Rails application, Sidekiq workers, Gitaly, Postgres, Redis, nginx, and a Prometheus stack into one Omnibus package, and every one of those is running whether you have 2 users or 200. The catalogue's 4 GB minimum matches GitLab's own documentation, and in practice 8 GB is where it stops swapping under a CI push. For that you get the most complete self-hosted DevOps platform there is: repositories, merge requests, issue boards, CI/CD with a YAML syntax half the industry knows, a container registry, package registries, and security scanning, MIT-licensed with 24,000 stars and 15 years of releases behind it.

You run GitLab for the CI, not for the git

Plain git hosting with merge requests and issues is done just as well by Gitea or Forgejo in 300 MB. The reason to pay GitLab's memory bill is .gitlab-ci.yml: pipelines with stages, artifacts passed between jobs, environments with deploy tracking, review apps, a registry the pipeline can push to without extra auth, and merge request pipelines that block merging on red. If a team already writes GitLab CI at work, self-hosting CE means their muscle memory transfers. The self-hosted git forges post makes the case in more detail; the short version is that if CI is a nice-to-have, GitLab is the wrong shape.

Install with Docker, then trim what you do not use

The gitlab/gitlab-ce image wants three ports (80, 443, 22), three volumes (/etc/gitlab, /var/log/gitlab, /var/opt/gitlab), and shm_size: "256m", without which Postgres complains. Everything else is set in /etc/gitlab/gitlab.rb followed by gitlab-ctl reconfigure. On a small instance, the settings that matter most are the ones that turn things off:

external_url 'https://git.example.com'
puma['worker_processes'] = 0        # single-process mode, saves about 1 GB
sidekiq['concurrency'] = 10
prometheus_monitoring['enable'] = false
gitlab_rails['gitlab_shell_ssh_port'] = 2222

Single-process Puma and no bundled monitoring bring a quiet instance under 3 GB. Run CI jobs on a separate machine or container with gitlab-runner, never on the GitLab host, because a runaway build competing with Sidekiq is how the web UI stops responding.

The backup does not contain your secrets

gitlab-backup create writes a tarball of repositories, database, uploads, and registry to /var/opt/gitlab/backups, and it deliberately excludes /etc/gitlab/gitlab-secrets.json and gitlab.rb. Restore the tarball without the secrets file and every CI variable, two-factor secret, and stored token is unreadable, permanently. Back up /etc/gitlab alongside the tarball, on the same schedule, to the same place. Test a restore into a fresh container before the day you need one, because the restore must be done on the same GitLab version as the backup, which is the next point.

Upgrades follow a path, and skipping steps breaks it

GitLab releases monthly and supports upgrading only along a documented path: certain versions are required stops because they carry background migrations that later versions assume finished. Jumping two majors in one pull is the most common way people end up with a container that boots into a migration error. GitLab publishes an upgrade path tool; use it, and before each hop check that background migrations from the previous one show as finished in the admin area. Budget an hour a month; the auto-update habit you use for lighter containers does not apply here.

What CE lacks

The Enterprise features that most often send a small team looking elsewhere are merge request approval rules, protected environments with approvers, and multiple assignees. Everything else that matters at homelab or small-company scale is in CE. The GitHub alternatives page covers what an organisation migrating from GitHub Team gains and loses.

What I'd do

If I had a team of 5 or more writing pipelines daily and a machine with 8 GB to spare, GitLab CE with the trimmed gitlab.rb above, a runner on a second host, nightly gitlab-backup plus /etc/gitlab shipped off-box, and a calendar entry for the monthly upgrade. If I were one person wanting a private forge with light CI, Forgejo with its Actions runner, and I would not feel I had lost anything. GitLab is a platform you operate, not a container you run, and the honest question is whether you want that job.

Compare GitLab CE

11 head-to-head comparisons.

Similar git hosting & forges apps