GitLab Community Edition is the MIT-licensed build of GitLab: repositories, merge requests, issues, a container registry, CI/CD with runners, wikis and a package registry in one Omnibus bundle. It replaces a GitHub Enterprise or Bitbucket Data Center deployment for organizations that want the whole toolchain on their own hardware.
Our verdict on GitLab CE#
Be honest about the floor: GitLab's own requirements page says 8 GB of memory is the minimum for memory-constrained environments and that 16 GB with 8 vCPU is the baseline. A four-person team on a 4 GB VPS will get a booting instance that swaps and times out, and swap is exactly what the docs tell you to disable. Budget 8 GB minimum and 16 GB if you run CI on the same box. What you get for that is the only self-hosted tool here that covers repos, CI, a container registry, packages, environments and issue tracking in one upgrade unit. CE is genuinely MIT and genuinely complete for source control and CI. What it lacks is the governance layer: required merge request approvers, CODEOWNERS enforcement, merge trains, epics and roadmaps, pull mirroring, advanced code search, audit events and the security dashboards, all of which sit in Premium or Ultimate. If your workflow needs enforced review policies, GitLab CE will not give them to you.
Who GitLab CE is for#
Choose it if
- An engineering group of 10 to 200 that wants source control, CI and a container registry from one vendor and one upgrade.
- Teams migrating off GitHub Enterprise who need feature parity rather than a lighter alternative.
- Anyone who already has a 16 GB server with spare capacity and would rather run one big thing than five small ones.
- Regulated environments that need everything, including build artifacts and container images, inside one audited boundary.
Look elsewhere if
- Your server has 4 GB of RAM or less; you will spend your time tuning Puma workers instead of shipping code.
- You want repositories and pull requests and nothing else, where Forgejo does the same job in 3 percent of the memory.
- You need enforced approval rules, CODEOWNERS gating or security scanning results, all of which are paid tiers and cannot be unlocked in CE.
What running it actually looks like#
The Omnibus package is one container or one deb/rpm that supervises PostgreSQL, Redis, Puma, Sidekiq, Gitaly, Workhorse, NGINX, Prometheus and more under runit. The Docker route mounts three volumes: /etc/gitlab, /var/log/gitlab and /var/opt/gitlab, and publishes 80, 443 and 22. Set external_url before first boot; changing it later means reconfiguring and fixing every stored URL. First start runs migrations and seeds the database, and the docs warn it may take a long time. On a modest machine expect 5 to 15 minutes before the instance answers, and the healthcheck will 502 throughout. Official arm64 Docker images landed in 18.2.0, and arm64 Linux packages exist for Debian, Ubuntu, RHEL and AlmaLinux with known-issue caveats. Every config change is a gitlab-ctl reconfigure, which is a Chef run that restarts services.
Resource profile#
- Memory
- 4096 MB idle, around 8192 MB in ordinary use. Documented minimum is 8 GB of memory with 16 GB as the stated baseline; the figures here are observed resident use for a quiet single-team instance, and Puma plus Sidekiq plus Gitaly plus PostgreSQL set the floor regardless of how few users you have.
- CPU and acceleration
- Documented baseline is 8 vCPU. Two cores will boot it and feel slow; every CI job you run locally competes with the web workers unless runners live elsewhere.
- Storage growth
- 40 GB for the application node plus your repositories, and the database lands at roughly 5 to 12 GB. The container registry and CI artifacts are what actually fill the disk, so set artifact expiry on day one.
- Operational load
- 4 of 5, Heavy. Version-pinned upgrade paths with required intermediate stops, a bundled PostgreSQL that migrates on restart, secrets stored outside the backup archive, and restores that fail loudly if you skipped `gitlab-secrets.json`. This is a system you administer, not a container you run.
Figures describe a small single-household install and are the working assumptions behind our stack planner. Your numbers will differ with library size, user count and hardware. See methodology.
Data and backup surface#
gitlab-backup create writes a tar holding the database, repositories, LFS, uploads, CI artifacts and job logs, the package and container registries, wikis, Pages, Terraform state and snippets. It deliberately excludes /etc/gitlab/gitlab-secrets.json and /etc/gitlab/gitlab.rb, plus TLS material in /etc/gitlab/ssl and the SSH host keys, because the database holds encrypted columns and keeping the key with the ciphertext defeats the point. Back up /etc/gitlab separately or your restore will come up with unreadable CI variables and broken two-factor secrets. Redis and queued Sidekiq jobs, Elasticsearch indexes and object storage contents are not included. The docs warn that around 100 GB of repositories the backup takes over two hours, and near 400 GB the built-in command stops being viable.
Derived backup shape
Postgres dump. pg_dump (or pg_dumpall) into a file, then snapshot that file plus the app's data volume.
Traps and surprises#
The backup does not contain your secrets
gitlab-backup create skips /etc/gitlab/gitlab-secrets.json on purpose. Restore without it and GitLab starts, but every encrypted column is garbage: CI/CD variables, integration tokens, two-factor seeds and runner registration tokens all fail to decrypt. Copy /etc/gitlab to the same place you keep the backup tar, and test that a restore of both together actually logs in.
Upgrades have required intermediate stops
You cannot jump from an old GitLab to current in one step. GitLab publishes required stop versions for each major and minor path, and each stop must be allowed to finish its background database migrations before you move on, which can take hours on a large instance. Check the upgrade path tool for your exact source version before you touch anything, and take a snapshot first.
The documented minimum is 8 GB and swap is discouraged
The requirements page states 8 GB of memory for memory-constrained environments, 16 GB as baseline, and separately says to disable swap where possible because it causes significant performance degradation under load. A 4 GB instance therefore has no safety valve: Sidekiq and Puma workers get OOM-killed under CI load and jobs silently stall.
CE and EE are different builds, not a licence toggle
The gitlab-ce package contains only FOSS code; gitlab-ee contains the proprietary code and runs at the Free tier until you apply a licence. Going from CE to EE is a package swap that works; going back from EE to CE is a documented downgrade procedure that involves removing EE-only data. Decide which build you want before you have five years of history in it.
CI artifacts and the registry fill the disk quietly
Job artifacts and container images default to keeping far more than you expect, and the container registry needs a separate garbage collection run that requires read-only mode to be safe. A busy pipeline can add tens of gigabytes a week. Set artifact expiry in .gitlab-ci.yml and an instance-wide default, and schedule registry garbage collection, before the volume fills and PostgreSQL stops accepting writes.
Specifications#
- Category
- Git forges and developer infrastructure
- Licence
- MIT (Permissive)
- Written in
- Ruby on Rails / Go / Vue
- First release
- 2011
- Maturity
- Mature
- Datastore
- PostgreSQL plus Redis (both bundled in Omnibus)
- Default ports
80,443,22- Ships as
- docker, deb/rpm package (Omnibus), helm chart
- arm64 builds
- Yes
- Identity
- Native OIDC. OmniAuth ships in the free self-managed build with OIDC, SAML, LDAP and social providers configured in `gitlab.rb`; LDAP group sync and multiple LDAP servers are Premium.
- Replaces
- GitHub Enterprise Server, Bitbucket Data Center, Azure DevOps Server, Jenkins
- Project site
- about.gitlab.com
- Source
- gitlab.com/gitlab-org/gitlab-foss
- Documentation
- docs.gitlab.com
Alternatives to GitLab CE#
Everything else in git forges and developer infrastructure, closest in operational weight first.
| Tool | Ops load | Idle RAM | Licence |
|---|---|---|---|
| Harbor | 4, Heavy | 2500 MB | Apache-2.0 |
| Forgejo | 2, Light | 150 MB | GPL-3.0-or-later |
| Gitea | 2, Light | 150 MB | MIT |
| Woodpecker CI | 2, Light | 90 MB | Apache-2.0 |
| code-server | 2, Light | 200 MB | MIT |
Where GitLab CE comes up elsewhere#
Head to head
Migration guides
Sources#
Facts on this page were checked against the project's own material. Where a number is our own estimate rather than a published figure, the text says so.
Published . Last reviewed . Found something out of date? Tell us and we will fix it and log the change.