Autor: [Adam Nadolny](/autorzy/adam-nadolny) Ekspert DevOps i infrastruktury · Zweryfikowano Kwiecień 2026 1. [Strona główna](/) › 2. [Baza wiedzy](/baza-wiedzy/) › 3. GitLab CE — instalacja na VPS # GitLab Community Edition — instalacja na VPS Opublikowano: 10 kwietnia 2026 · Kategoria: VPS i serwery GitLab Community Edition to kompletna platforma DevOps open-source: Git hosting, issue tracker, CI/CD pipelines, Container Registry, Package Registry i wiele więcej — wszystko self-hosted na Twoim VPS. W porównaniu z GitHub czy GitLab.com daje pełną kontrolę nad kodem i danymi. Ten artykuł przeprowadzi Cię przez instalację, konfigurację CI/CD i backup. ## 1\. Instalacja GitLab CE (metoda Omnibus) Metoda Omnibus to oficjalnie rekomendowana instalacja — jeden pakiet zawiera wszystkie zależności (PostgreSQL, Redis, Nginx, Puma, Sidekiq, Gitaly). Nie musisz nic konfigurować osobno. Wymagania minimalne: 4 GB RAM, 4 vCPU, 20 GB SSD. \# Ubuntu 22.04 / 24.04 # 1. Zainstaluj zaleznosci sudo apt update && sudo apt install -y curl ca-certificates postfix # 2. Dodaj repozytorium GitLab curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash # 3. Ustaw URL GitLab i zainstaluj (ZMIEN na swoj URL!) sudo EXTERNAL\_URL="https://gitlab.example.com" apt install gitlab-ce -y # Instalacja trwa kilka minut — konfiguruje PostgreSQL, Redis, Nginx... # 4. Sprawdz status wszystkich komponentow sudo gitlab-ctl status # 5. Pobierz haslo root (generowane przy instalacji) sudo cat /etc/gitlab/initial\_root\_password # Haslo wazne przez 24h — zmien je od razu! # 6. Zaloguj sie: https://gitlab.example.com # Login: root, Haslo: z kroku 5 # Jesli instalujesz za istniejacym Nginx (reverse proxy): # W gitlab.rb ustaw: # external\_url 'http://gitlab.example.com' # http (bez SSL) # nginx\['listen\_port'\] = 8080 # nginx\['listen\_https'\] = false ## 2\. Konfiguracja gitlab.rb — kluczowe ustawienia \# /etc/gitlab/gitlab.rb — główny plik konfiguracyjny # Po każdej zmianie: sudo gitlab-ctl reconfigure # === PODSTAWOWE USTAWIENIA === external\_url 'https://gitlab.example.com' # Certyfikat SSL Let's Encrypt (automatyczny jesli external\_url = https://) letsencrypt\['enable'\] = true letsencrypt\['email'\] = 'admin@example.com' letsencrypt\['auto\_renew'\] = true letsencrypt\['auto\_renew\_hour'\] = 3 # === EMAIL (SMTP) === gitlab\_rails\['smtp\_enable'\] = true gitlab\_rails\['smtp\_address'\] = "smtp.gmail.com" gitlab\_rails\['smtp\_port'\] = 587 gitlab\_rails\['smtp\_user\_name'\] = "myapp@gmail.com" gitlab\_rails\['smtp\_password'\] = "app\_password" gitlab\_rails\['smtp\_domain'\] = "gmail.com" gitlab\_rails\['smtp\_authentication'\] = "login" gitlab\_rails\['smtp\_enable\_starttls\_auto'\] = true gitlab\_rails\['gitlab\_email\_from'\] = 'gitlab@example.com' # === OPTYMALIZACJA RAM (dla VPS z 4-8 GB) === # Ogranicz Puma (aplikacja Ruby) puma\['worker\_processes'\] = 2 puma\['min\_threads'\] = 1 puma\['max\_threads'\] = 4 # Ogranicz Sidekiq (jobs) sidekiq\['max\_concurrency'\] = 5 # Ogranicz PostgreSQL postgresql\['shared\_buffers'\] = "256MB" postgresql\['max\_connections'\] = 50 # Ogranicz Gitaly gitaly\['configuration'\] = { git: { use\_bundled\_git: true, }, } # Wylacz Prometheus jesli nie potrzebujesz (oszczedza RAM) prometheus\_monitoring\['enable'\] = false alertmanager\['enable'\] = false node\_exporter\['enable'\] = false redis\_exporter\['enable'\] = false postgres\_exporter\['enable'\] = false gitlab\_exporter\['enable'\] = false # === BACKUPY === gitlab\_rails\['backup\_path'\] = "/var/opt/gitlab/backups" gitlab\_rails\['backup\_keep\_time'\] = 604800 # 7 dni (w sekundach) # === SSH === gitlab\_rails\['gitlab\_shell\_ssh\_port'\] = 22 # Po zmianach: sudo gitlab-ctl reconfigure ## 3\. GitLab Runner — instalacja i rejestracja \# === INSTALACJA RUNNERA === # Najlepiej na osobnej maszynie (VPS) — nie na tym samym co GitLab # Dodaj repozytorium GitLab Runner curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" | sudo bash sudo apt install gitlab-runner -y # Alternatywnie przez Docker: docker run -d --name gitlab-runner --restart always \\ -v /srv/gitlab-runner/config:/etc/gitlab-runner \\ -v /var/run/docker.sock:/var/run/docker.sock \\ gitlab/gitlab-runner:latest # === REJESTRACJA RUNNERA === # Pobierz token: GitLab → Admin → CI/CD → Runners → New instance runner # lub dla projektu: Settings → CI/CD → Runners → New project runner sudo gitlab-runner register # Interaktywna rejestracja zapyta o: # - GitLab instance URL: https://gitlab.example.com # - Registration token: glrt-xxxxxxxxxxxx # - Runner name: docker-runner-1 # - Executor: docker (rekomendowany) # - Default Docker image: docker:24-dind lub alpine:latest # Nieinteraktywna rejestracja: sudo gitlab-runner register \\ --non-interactive \\ --url "https://gitlab.example.com" \\ --token "glrt-xxxxxxxxxxxx" \\ --name "docker-runner-1" \\ --executor "docker" \\ --docker-image "alpine:latest" \\ --docker-volumes "/var/run/docker.sock:/var/run/docker.sock" # Sprawdz status i lista runnerow: sudo gitlab-runner status sudo gitlab-runner list # Runner config: /etc/gitlab-runner/config.toml ## 4\. Pipeline CI/CD — przykładowy .gitlab-ci.yml \# .gitlab-ci.yml — w root repo # Kompletny pipeline: test → build → deploy stages: - test - build - deploy # Globalne zmienne variables: DOCKER\_REGISTRY: registry.gitlab.example.com IMAGE\_NAME: ${DOCKER\_REGISTRY}/${CI\_PROJECT\_PATH} IMAGE\_TAG: ${CI\_COMMIT\_SHORT\_SHA} # Cache node\_modules miedzy jobami .node\_cache: cache: key: "${CI\_COMMIT\_REF\_SLUG}" paths: - node\_modules/ # ===== STAGE: TEST ===== test: stage: test image: node:20-alpine extends: .node\_cache script: - npm ci - npm run lint - npm test coverage: '/Statements.\*?(\\d+(?:\\.\\d+)?)%/' artifacts: reports: coverage\_report: coverage\_format: cobertura path: coverage/cobertura-coverage.xml only: - merge\_requests - main # ===== STAGE: BUILD ===== build: stage: build image: docker:24 services: - docker:24-dind variables: DOCKER\_TLS\_CERTDIR: "/certs" script: - docker login -u $CI\_REGISTRY\_USER -p $CI\_REGISTRY\_PASSWORD $CI\_REGISTRY - docker build -t ${IMAGE\_NAME}:${IMAGE\_TAG} -t ${IMAGE\_NAME}:latest . - docker push ${IMAGE\_NAME}:${IMAGE\_TAG} - docker push ${IMAGE\_NAME}:latest only: - main # ===== STAGE: DEPLOY ===== deploy: stage: deploy image: alpine:latest environment: name: production url: https://example.com before\_script: - apk add --no-cache openssh-client - eval $(ssh-agent -s) - echo "$SSH\_PRIVATE\_KEY" | tr -d '\\r' | ssh-add - - mkdir -p ~/.ssh && chmod 700 ~/.ssh - ssh-keyscan -H $DEPLOY\_HOST >> ~/.ssh/known\_hosts script: - ssh deploy@$DEPLOY\_HOST " cd /opt/myapp && docker pull ${IMAGE\_NAME}:${IMAGE\_TAG} && docker compose up -d --no-deps app && docker image prune -f " only: - main when: manual # Wymaga recznego potwierdzenia w UI ## 5\. Backup i restore \# ===== BACKUP ===== # Natychmiastowy backup (repozytoria + baza + attachmenty) sudo gitlab-backup create # Z timestamp w nazwie pliku: sudo gitlab-backup create BACKUP=mybackup\_$(date +%Y%m%d) # Lokalizacja backupow: ls -la /var/opt/gitlab/backups/ # WAZNE: Backupuj tez te pliki osobno! (nie sa w standardowym backupie) sudo cp /etc/gitlab/gitlab.rb /backup/ sudo cp /etc/gitlab/gitlab-secrets.json /backup/ # gitlab-secrets.json zawiera klucze szyfrowania — bez niego restore nie zadziala! # Automatyczny backup przez cron (codziennie o 2:00) # sudo crontab -e 0 2 \* \* \* /opt/gitlab/bin/gitlab-backup create CRON=1 2>> /var/log/gitlab-backup.log # Transfer backupu na zewnetrzny storage (S3, rsync): # W gitlab.rb: # gitlab\_rails\['backup\_upload\_connection'\] = { 'provider' => 'AWS', ... } # gitlab\_rails\['backup\_upload\_remote\_directory'\] = 'my-backup-bucket' # ===== RESTORE ===== # 1. Zainstaluj identyczna wersje GitLab (!) na nowym serwerze # 2. Skopiuj plik backupu do /var/opt/gitlab/backups/ # 3. Skopiuj gitlab.rb i gitlab-secrets.json do /etc/gitlab/ # 4. Zatrzymaj uslugi zapisujace dane sudo gitlab-ctl stop puma sudo gitlab-ctl stop sidekiq # 5. Przywroc backup (TIMESTAMP z nazwy pliku) sudo gitlab-backup restore BACKUP=1234567890\_gitlab\_backup.tar # 6. Uruchom ponownie i sprawdz sudo gitlab-ctl restart sudo gitlab-rake gitlab:check SANITIZE=true sudo gitlab-rake gitlab:doctor:secrets ## Porównanie GitLab CE z Gitea Cecha GitLab CE Gitea RAM (minimum) 4 GB (8+ zalecane) 256 MB (1 GB zalecane) CI/CD Wbudowany GitLab CI — bardzo zaawansowany Gitea Actions (GitHub Actions kompatybilny) Container Registry Wbudowany (per projekt) Brak natywnego Security scanning SAST, DAST, Dependency Scanning Brak Issue tracker Pełny (board, epics, roadmap) Podstawowy GitLab Pages Wbudowane Brak Złożoność Wysoka Niska Dla kogo Zespoły DevOps, firmy, kompleksowe projekty Homelaby, małe projekty, ograniczone zasoby ## Najczęstsze pytania Jakie są minimalne wymagania sprzętowe dla GitLab CE? + GitLab CE wymaga co najmniej: 4 GB RAM (8+ GB rekomendowane dla większych zespołów), 4 vCPU, 20+ GB dysku (SSD rekomendowany). Dla małych zespołów (do 5 osób) można zejść do 2 GB RAM z włączoną przestrzenią swap, ale będzie wolny. GitLab to duża aplikacja — Ruby on Rails + PostgreSQL + Redis + Sidekiq + Puma + Gitaly. Gitea wymaga znacznie mniej zasobów i jest lepszą opcją jeśli masz ograniczone zasoby lub potrzebujesz tylko Git hosting bez CI/CD. Czym GitLab CE różni się od Gitea? + GitLab CE to kompleksowa platforma DevOps: Git hosting + Issue tracker + CI/CD (GitLab CI) + Container Registry + Package Registry + Security scanning + Wiki + Pages. Gitea to lekki Git hosting (fork Gogs) z podstawowym issue trackerem, Actions (kompatybilne z GitHub Actions) i minimalnym footprintem RAM/CPU. Wybierz GitLab CE gdy potrzebujesz kompleksowego CI/CD i DevOps. Wybierz Gitea gdy priorytetem jest lekkość, szybkość i ograniczone zasoby serwera. Jak skonfigurować GitLab Runner? + GitLab Runner to agent wykonujący zadania CI/CD. Instalacja: curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh | sudo bash && sudo apt install gitlab-runner. Rejestracja: sudo gitlab-runner register z podaniem URL GitLab, tokenu rejestracji (z Settings → CI/CD → Runners), nazwy i executora (docker, shell, kubernetes). Executor docker jest rekomendowany — każde zadanie uruchamia się w izolowanym kontenerze. Jak wykonać backup i restore GitLab CE? + Backup: sudo gitlab-backup create — tworzy archiwum w /var/opt/gitlab/backups/. Plik zawiera repozytoria, bazy danych, attachmenty. Konfigurację (/etc/gitlab/gitlab.rb i /etc/gitlab/gitlab-secrets.json) backupuj OSOBNO — nie jest w standardowym backupie. Restore: zatrzymaj GitLab (sudo gitlab-ctl stop puma sidekiq), skopiuj plik backupu do /var/opt/gitlab/backups/, uruchom: sudo gitlab-backup restore BACKUP=TIMESTAMP\_gitlab\_backup.tar, następnie sudo gitlab-ctl restart i sudo gitlab-rake gitlab:check. ## Sprawdź oferty pasujące do tego scenariusza Poniżej masz szybkie przejścia do ofert i stron z kodami rabatowymi tam, gdzie są dostępne. Contabo VPS z 8+ GB RAM pod produkcyjny GitLab CE z CI/CD i Container Registry VPS 8 GB RAM [Aktywuj rabat →](/out/contabo) #Reklama · link partnerski [Zobacz kod rabatowy →](/kody-rabatowe/contabo) Mikr.us Budżetowy VPS do Gitea (lżejsza alternatywa gdy RAM jest priorytetem) Gitea alt. [Aktywuj rabat →](/out/mikrus) #Reklama · link partnerski [Zobacz kod rabatowy →](/kody-rabatowe/mikrus) LH.pl Hosting gdy potrzebujesz tylko Git przez SSH bez własnego GitLab Hosting + SSH [Aktywuj rabat →](/out/lh-pl) #Reklama · link partnerski [Zobacz kod rabatowy →](/kody-rabatowe/lh-pl) ## Powiązane strony - [Docker Compose w produkcji](/baza-wiedzy/docker-compose-produkcja) - [Git deploy na hostingu — post-receive hook](/baza-wiedzy/git-deploy-hosting) - [Nginx — konfiguracja virtual hosts](/baza-wiedzy/nginx-vhost-konfiguracja) - [Bezpieczeństwo VPS — checklist](/baza-wiedzy/bezpieczenstwo-vps-checklist) - [Wszystkie artykuły](/baza-wiedzy/)