GITLAB · TECH
GitLab: complete DevOps platform with CI/CD, registry, and security
GitLab 17 as the all-in-one DevOps platform. Community Edition MIT, Enterprise proprietary. Self-host or cloud. Very comprehensive but resource-hungry.
Researched & fact-checked by: DuneDive LLC · As of: 2026-05
What is GitLab?
GitLab is a complete DevOps platform – Git hosting plus CI/CD plus container registry plus security scanning plus issue boards plus wiki plus monitoring plus container orchestration. The project started in 2011 as a GitHub alternative and became GitLab Inc. in 2014 (Nasdaq-listed since 2021). As of May 2026, version 17, an established player with two editions: Community Edition (CE, MIT licence, self-host free) and Enterprise Edition (EE, proprietary, from USD 29 per user/month).
Community vs Enterprise: CE covers about 80% of features – Git, CI/CD, issues, PRs, container registry, package registry. EE adds enterprise-specific features: multi-region replication, compliance-grade audit events, advanced security scanning (SAST/DAST/dependency), code-owner approval rules, multi-project pipelines, push rules, group-level security dashboards.
Hosting options: (1) gitlab.com cloud – free tier with 400 CI minutes/month, Premium from USD 29/user/month, Ultimate from USD 99/user/month. (2) Self-host Omnibus package – everything in one Debian/RPM package or Docker image. (3) Self-host Kubernetes Helm chart – for large setups with horizontal scaling.
Architecture: GitLab is a Rails monolith with many helper services – PostgreSQL, Redis, NGINX, Sidekiq (background jobs), Gitaly (Git server), Präfect (Gitaly cluster), Workhorse (HTTP proxy), Pages, Registry. Everything pre-integrated in the Omnibus image. That makes GitLab powerful but resource-hungry – minimum 4 GB RAM at idle, 8 GB RAM for active production use.
May 2026 status: GitLab 17 has advanced the migration path to Cells (multi-tenant architecture), Duo (AI assist) is available, and free-tier limits have tightened further versus 2024. Self-host CE remains the rational choice for serious SME setups when hardware is available.
Why it matters
GitLab solves a specific problem for an SME with 15+ developers or strict compliance needs: "we want a single vendor and one UI for everything".
SME suitability (May 2026) – conditional: for small teams (1-10 developers) GitLab Omnibus is often overkill. Hardware demand (8 GB RAM minimum), learning curve, and operations effort do not match the added value. From 15 developers up or for mandates with strict compliance, GitLab becomes sensible: everything under one roof, one UI, one audit log, one permissions hierarchy.
CH DSG fit: fully achievable on self-host. GitLab CE runs self-host on Hetzner Falkenstein, all data stays on-premise. Auditor access via read-only user with clearly defined roles. On gitlab.com cloud: EU region nominally present, but GitLab Inc. is a US company – data processing agreement and transfer impact assessment are mandatory.
Complete toolchain: one of the real advantages. Instead of Gitea + Woodpecker + Sentry + Trivy + Mattermost each with own login, config, and update cycle, GitLab CE covers this domain. For a mandate, the choice rationale is simpler: "we have GitLab, it does everything".
CI/CD integrated: GitLab CI is built in, no separate runner container required (although possible). Pipeline definition in .gitlab-ci.yml. Very mature: multi-stage pipelines, matrix builds, approval gates, secrets vault, multi-project pipelines, dynamic child pipelines. Pipeline language richer than GitHub Actions, but also more complex.
Security features (EE): SAST (Static Application Security Testing), DAST (Dynamic), dependency scanning, licence compliance, container scanning – all built in. For regulated sectors (finance, insurance, healthcare) a clear value-add. But from Premium tier upwards (USD 29/user/month).
What GitLab is not: not a fast setup. If you need a Git hosting solution in half a day: Gitea. If you want a lean open-source toolchain without lock-in: Gitea + Woodpecker. GitLab is the rational pick when requirements already dictate full complexity.
How it works
GitLab Omnibus is a single Docker image (or Debian/RPM package) with all components pre-integrated.
docker-compose.yml example for an SME setup:
```yaml services: gitlab: image: gitlab/gitlab-ce:17.0.0-ce.0 hostname: gitlab.firm.ch environment: GITLAB_OMNIBUS_CONFIG: | external_url "https://gitlab.firm.ch" gitlab_rails["smtp_enable"] = true gitlab_rails["smtp_address"] = "smtp-relay.brevo.com" gitlab_rails["smtp_port"] = 587 gitlab_rails["backup_keep_time"] = 604800 ports: - "443:443" - "80:80" - "22:22" volumes: - gitlab-config:/etc/gitlab - gitlab-logs:/var/log/gitlab - gitlab-data:/var/opt/gitlab restart: unless-stopped shm_size: "256m" volumes: gitlab-config: gitlab-logs: gitlab-data: ```
First start takes 5-10 minutes (init of Postgres, Redis, Gitaly, Sidekiq). Then browse to https://gitlab.firm.ch, read the admin password from /etc/gitlab/initial_root_password, log in, change the root password.
Hardware requirements: GitLab officially documents 4 vCPU + 4 GB RAM minimum for up to 100 users. Realistic for a running production setup with an active team: 4 vCPU + 8 GB RAM + 50 GB disk for data + 20 GB for logs. Hetzner CCX23 (4 dedicated vCPU, 16 GB RAM, 160 GB SSD) is the typical default – around CHF 30/month.
GitLab Runner: CI/CD needs runners – separate containers/VMs executing jobs. One shared runner per instance is standard.
```yaml runner: image: gitlab/gitlab-runner:latest volumes: - /var/run/docker.sock:/var/run/docker.sock - runner-config:/etc/gitlab-runner restart: unless-stopped ```
After docker exec gitlab-runner register with the registration token from the GitLab UI.
Pipeline example (.gitlab-ci.yml):
```yaml stages: [build, test, deploy] build: stage: build image: node:20 script: npm ci && npm run build artifacts: { paths: [dist/] } test: stage: test image: node:20 script: npm test deploy: stage: deploy image: alpine:latest script: - apk add openssh-client - ssh deploy@server "cd /app && git pull && npm ci && pm2 restart all" only: [main] ```
Backup: gitlab-backup create produces a complete tarball (DB plus repos plus uploads). Cron daily, retention 7 days, off-site copy via rsync. Restore: gitlab-backup restore BACKUP=timestamp – recoverable in 10-30 minutes depending on data size.
Setup in 5 steps
- 01Provision Hetzner CCX23 or larger (minimum 4 dedicated vCPU, 16 GB RAM, 100+ GB SSD), DNS-map subdomain gitlab.firm.ch.
- 02Start docker-compose with gitlab/gitlab-ce:17.0, set GITLAB_OMNIBUS_CONFIG with external_url, SMTP config (Brevo), backup_keep_time.
- 03First start: read root password from /etc/gitlab/initial_root_password, log in, enable sign-up restriction, enforce 2FA for admins.
- 04Deploy GitLab Runner, register with token from Admin -> Runners, choose docker executor, set resource limits (CPU 2, memory 4 GB per job).
- 05Set up backup cron: gitlab-backup create daily, rsync to Hetzner Storage Box, monthly restore test in a staging environment.
When to use GitLab
GitLab is the right choice when (a) the team has 15+ developers, (b) compliance requires very detailed audit trails, (c) a single platform for Git/CI/CD/registry/security is desired, (d) hardware budget for 8+ GB RAM servers is available.
Concrete cases: a SaaS boutique with 20 developers and several client platforms – GitLab CE with multi-project pipelines covers it without extra per-tool licences. A finance advisory under FINMA-adjacent oversight – GitLab Premium with SAST/DAST plus audit events meets requirements. A corporate subsidiary with 100+ developers leaving GitHub Enterprise – GitLab Ultimate is a serious migration option.
At Fairlane we run Gitea (not GitLab) – we have 1-3 developer-activity per day, a single binary suffices. GitLab would be overkill. We see GitLab more often at larger clients (15-50 developers) and in industries under compliance pressure.
When not to use
GitLab is the wrong choice when (a) the team is under 10 developers – Gitea suffices with less effort, (b) the budget cannot carry 16 GB RAM Hetzner hardware – RAM hunger is real, (c) operations experience for multi-service stacks (Postgres, Redis, NGINX, Sidekiq, Gitaly) is missing in the team – updates and recovery are more complex than Gitea, (d) Premium/Ultimate features (SAST, DAST, audit events) are not needed – then CE-level functionality is reachable via Gitea+Woodpecker with less complexity.
Pitfalls: running GitLab Omnibus on 4 GB RAM without memory tuning – OOM kills follow, workshops on unicorn["worker_processes"] and sidekiq["concurrency"] become necessary. Skipping GitLab updates – security patches are frequent, major upgrades every 6 months are mandatory. Not testing backup cron – gitlab-backup restore is non-trivial, regular disaster-recovery tests are mandatory.
Not recommended: running GitLab CE plus various external tools in parallel – the entire idea of GitLab is integration, placing separate Sentry/Trivy/Mattermost instances next to it gives up the main advantage. GitLab.com Free as production backbone for SMEs with CH clients – data in the US, no data processing agreement available in the free tier.
Trade-offs
STRENGTHS
- All-in-one: Git, CI/CD, registry, security, issues in one platform
- CI/CD engine very mature (multi-stage, matrix, multi-project)
- Community Edition MIT-licensed, fully self-host
- Market standard for enterprise-grade DevOps with a clear roadmap
WEAKNESSES
- Resource-hungry – 4 GB RAM minimum, realistically 8-16 GB
- Operations complexity – multi-service stack with its own Sidekiq, Gitaly, Workhorse
- EE features (SAST, DAST, audit events) behind USD 29/user/month
- Backup-restore path complex – disaster recovery must be tested regularly
FAQ
GitLab CE or EE – what is enough for an SME?
For 90% of SME cases, CE is enough. Issues, PRs, CI/CD, container registry, package registry, basic security scanning – all in CE. EE becomes useful with (a) compliance like ISO 27001 or FINMA-adjacent oversight with mandatory audit trail, (b) multi-region replication, (c) advanced security (SAST, DAST, licence compliance). Rule of thumb: under 25 developers and no hard audit duty – CE. Above: evaluate EE.
GitLab or Gitea – when does the switch make sense?
Switching from Gitea to GitLab makes sense when the team grows to 20+ developers and (a) multi-project pipelines are needed, (b) code-owner approval rules must be enforced, (c) compliance audits demand the GitLab-specific audit trail. Until then: Gitea remains the rational choice. The switch is feasible, but CI/CD pipelines must be rewritten (Gitea Actions YAML to GitLab CI YAML).
What does GitLab self-host realistically cost?
Hardware: Hetzner CCX23 around CHF 30/month for SMEs up to 50 users. One-off setup: 2-3 days including nginx reverse proxy, Lets-Encrypt, SMTP, backup cron, runner setup. Ongoing maintenance: 4-8 hours per month (updates, monitoring, backup verify, occasional tunings). First year including setup: CHF 5000-10000. gitlab.com Premium comparable scope: USD 29 per user per month – 15 users USD 5200/year. Self-host wins from about year two.
What happens during a GitLab outage?
Without an HA setup: during an outage, the team cannot push, pull, or work on issues. Local Git clones remain functional – code work is possible, but no code review and no CI/CD. Recovery from backup usually 30-90 minutes depending on data size. Recommendation: monthly restore test in a staging environment so the path is rehearsed before a real outage. For >25 developers: evaluate an HA setup with two nodes + Gitaly cluster.
Related topics
Sources
- GitLab – Documentation · 2026-05
- GitLab – Pricing tiers · 2026-05
- GitLab Omnibus – Installation guide · 2026-04
- GitLab 17 – Release announcements · 2026-04