GitLab CE
Complete DevOps platform you can self-host
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
Gitea
Git Hosting & ForgesLightweight self-hosted Git service
Replaces GitHub, GitLab
Gogs
Git Hosting & ForgesPainless self-hosted Git service
Replaces GitHub, Bitbucket
OneDev
Git Hosting & ForgesSelf-hosted Git server with CI/CD and kanban
Replaces GitHub, GitLab
GitBucket
Git Hosting & ForgesGit platform powered by Scala with GitHub-like UI
Replaces GitHub
GitLab Runner
Git Hosting & ForgesRun CI/CD jobs for GitLab on your own infrastructure
Replaces GitHub Actions runner
Soft Serve
Git Hosting & ForgesSelf-hostable Git server for the command line
Replaces GitHub