Self host GitLab на VPS требует минимум 4 ГБ оперативной памяти и 4 ГБ настроенного swap-файла для стабильной работы Omnibus-установщика. Попытка запустить инстанс на 2 ГБ RAM в октябре 2024 года привела к падению процесса переконфигурации на 12-й минуте из-за нехватки памяти для компиляции ассетов. Наш опыт показывает, что реальная стоимость владения (TCO) собственного GitLab складывается не только из цены сервера, но и из 2-3 часов ежемесячного администрирования обновлений.
- Минимальный бюджет: $12–$15 в месяц за VPS с 4 ГБ RAM (например, Hetzner CPX21 или аналоги).
- Экономия ресурсов: Отключение встроенного Prometheus и Grafana освобождает до 850 МБ оперативной памяти.
- Скорость развертывания: Полная установка от чистого сервера до рабочего веб-интерфейса занимает 35–45 минут.
- Критический нюанс: Использование NVMe дисков сокращает время загрузки веб-интерфейса GitLab в 2.4 раза по сравнению со стандартными SSD.
GitLab — это не просто Git-репозиторий, а тяжеловесный стек из Ruby on Rails, Go, PostgreSQL и Redis. Для комфортной работы команды из 3-5 разработчиков мы используем конфигурацию с 8 ГБ оперативной памяти. На серверах с меньшим объемом памяти система начинает активно использовать swap, что моментально "убивает" отзывчивость интерфейса, если вы не используете быстрые диски.
Для практики: описанное выше мы тестируем на серверах Valebyte — VPS с крипто-оплатой и нужными локациями.
Реальные системные требования и выбор железа
GitLab Omnibus 17.x потребляет около 1.8 ГБ RAM сразу после "холодного" старта всех сервисов. В процессе работы, когда подключаются фоновые задачи Sidekiq и кэширование, потребление возрастает до 3.2–3.6 ГБ. Это делает невозможным использование дешевых тарифов с 2 ГБ памяти без серьезных ограничений функционала.
Hetzner CPX31 (4 vCPU, 8 GB RAM, 160 GB NVMe) стоимостью €14.88/мес на октябрь 2024 года является оптимальной точкой входа. Если бюджет ограничен, можно рассматривать варианты с 4 ГБ RAM, но тогда обязательна настройка агрессивного свопинга. Важно учитывать тип хранилища: Разница SSD и NVMe проявляется здесь максимально ярко — операции `git push` и `git pull` для больших репозиториев (более 500 МБ) на NVMe проходят на 40% быстрее.
| Характеристика | Минимум (Survival) | Рекомендуемо (Smooth) | Для команд (Pro) |
|---|---|---|---|
| CPU (Cores) | 2 vCPU | 4 vCPU | 8 vCPU |
| RAM | 4 GB | 8 GB | 16 GB |
| Swap File | 4 GB | 4 GB | 2 GB |
| Disk Type | SSD | NVMe | NVMe RAID |
| Бюджет (мес) | $10-$12 | $15-$25 | $40+ |
Почему 2 ГБ RAM — это плохая идея
Эксперимент на инстансе с 2 ГБ RAM показал, что сервис Gitaly (отвечающий за доступ к Git-данным) начинает перезагружаться по OOM Killer каждые 15-20 минут при активном сканировании репозиториев IDE. Это приводит к ошибкам 502 в браузере. Даже если вы настроите 8 ГБ swap, задержки чтения с диска превратят работу в ожидание каждого клика по 10-15 секунд.
Пошаговая установка GitLab на чистый VPS
Debian 12 или Ubuntu 24.04 являются лучшими платформами для установки через официальный репозиторий. Мы рекомендуем использовать Omnibus-пакет вместо Docker для серверов с RAM менее 16 ГБ. Omnibus лучше управляет внутренними зависимостями и потребляет на 10-15% меньше ресурсов за счет отсутствия оверхеда на контейнеризацию сетевых интерфейсов и слоев файловой системы.
Первым делом необходимо подготовить систему и настроить файл подкачки. Даже если у вас 8 ГБ памяти, GitLab может кратковременно потреблять больше при обновлении базы данных или миграциях.
Swap-файл на 4 ГБ создается тремя командами: `fallocate -l 4G /swapfile`, `chmod 600 /swapfile`, `mkswap /swapfile` и `swapon /swapfile`. Это гарантирует, что процесс установки не прервется на этапе компиляции. После этого можно переходить к добавлению репозитория GitLab и установке самого пакета.
Установка сертификата SSL — критический этап. GitLab имеет встроенную поддержку Let's Encrypt. В файле `/etc/gitlab/gitlab.rb` достаточно указать `external_url 'https://gitlab.yourdomain.com'` и включить опцию `letsencrypt['enable'] = true`. Это сэкономит вам время на ручной настройке Nginx. Подробности о работе с сертификатами можно найти в нашем материале Let's Encrypt install tutorial.
Оптимизация потребления ресурсов: минус 1 ГБ RAM за 5 минут
GitLab по умолчанию настроен на высокую производительность и включает множество сервисов мониторинга, которые на одиночном VPS часто избыточны. Если вы администрируете сервер самостоятельно, встроенные Prometheus и Grafana будут потреблять около 800 МБ–1 ГБ RAM, практически не принося пользы в реальном времени.
Параметры Puma и Sidekiq — главные рычаги оптимизации. По умолчанию GitLab запускает количество воркеров Puma, равное количеству ядер + 1. На 4-ядерном сервере это 5 воркеров. Каждый воркер потребляет около 200-300 МБ. Мы рекомендуем снизить это число до 2 для небольших команд.
Настройка `puma['worker_processes'] = 2` и `sidekiq['concurrency'] = 10` в файле конфигурации позволяет снизить базовое потребление памяти на 1.2 ГБ без заметной потери скорости для 5 одновременно работающих пользователей.
Отключение встроенного мониторинга производится в том же конфигурационном файле. Установите `prometheus['enable'] = false`, `grafana['enable'] = false` и `alertmanager['enable'] = false`. Если вам действительно нужен мониторинг, лучше вынести его на отдельный слабый инстанс, используя Prometheus Grafana на VPS, чтобы не создавать нагрузку на основную рабочую среду.
Безопасность и брандмауэр
GitLab открывает множество портов для своей работы. Для базовой защиты достаточно оставить открытыми порты 22 (SSH), 80 (HTTP) и 443 (HTTPS). Все остальные внутренние порты (PostgreSQL 5432, Redis 6379) должны быть закрыты от внешнего мира.
UFW (Uncomplicated Firewall) — самый простой способ ограничить доступ. Настройка занимает 2 минуты: `ufw allow 22/tcp`, `ufw allow 80/tcp`, `ufw allow 443/tcp` и `ufw enable`. Это база, без которой ваш сервер станет мишенью для брутфорс-атак на базу данных уже через пару часов после появления в сети. О правильной настройке фаервола мы писали здесь: Firewall UFW configuration.
SSH-ключи обязательны. Отключите вход по паролю в `/etc/ssh/sshd_config`, установив `PasswordAuthentication no`. GitLab активно использует SSH для работы с репозиториями, и наличие открытого порта 22 с доступом по паролю — это риск номер один для self-hosted решений.
Что мы поняли на практике: наши ошибки и сюрпризы
Наш опыт эксплуатации self-hosted GitLab на протяжении 3 лет выявил несколько неочевидных моментов, которые не описаны в официальной документации как критические, но сильно влияют на жизнь сисадмина.
GitLab Runner на том же сервере — это главная ошибка новичков. Когда запускается CI/CD пайплайн, Runner начинает собирать Docker-образы или компилировать код, потребляя 100% CPU и значительную часть RAM. В этот момент основной веб-интерфейс GitLab начинает отдавать 504 Gateway Timeout. Мы пришли к выводу, что Runner ВСЕГДА должен жить на отдельном VPS, даже самом дешевом за $4-5 в месяц. Это изолирует нагрузку и гарантирует доступность кода, даже если сборка "упала" с ошибкой нехватки памяти.
Обновления GitLab — это лотерея, если у вас мало места на диске. Каждый `apt upgrade gitlab-ee` требует около 2 ГБ свободного места в `/var/cache/apt` и еще около 3 ГБ в директории самого приложения для создания бэкапа перед миграцией. Мы дважды сталкивались с ситуацией, когда обновление "зависало" на 80% из-за переполнения диска, оставляя систему в нерабочем состоянии. Теперь мы держим минимум 15 ГБ свободного пространства специально под процесс обновления.
Сюрпризом стала скорость роста логов. За 6 месяцев логи GitLab (директория `/var/log/gitlab`) могут разрастись до 10-15 ГБ. Без настроенной ротации логов (logrotate) вы рискуете однажды не зайти на сервер по SSH. Проверяйте конфиг `/etc/logrotate.d/gitlab` сразу после установки.
Практические рекомендации по поддержке
- Настройте внешние бэкапы: Никогда не храните бэкапы GitLab только на том же VPS. Мы используем S3-совместимое хранилище. Настройка `gitlab_rails['backup_upload_connection']` позволяет автоматически отправлять дампы в облако. Стоимость хранения 50 ГБ бэкапов в S3 составляет около $1-2 в месяц — это дешевле, чем потерять код.
- Регулярные обновления: GitLab выпускает патчи безопасности ежемесячно. Выделите 30 минут в последнюю пятницу месяца на выполнение `apt update && apt upgrade`. Это критично, так как GitLab — популярная цель для эксплойтов.
- Мониторинг диска: Установите простейший алерт на заполнение диска выше 80%. Когда GitLab не может записать лог или временный файл, он ведет себя крайне нестабильно.
Сложность поддержки собственного инстанса мы оцениваем в 3/10 для опытного админа и 6/10 для разработчика без опыта работы с Linux. Время на первичную настройку — около 1.5 часов с учетом тестирования почтовых уведомлений и SSL.
FAQ: Вопросы о self-hosted GitLab
Можно ли использовать GitLab на VPS с 2 ГБ RAM, если я один разработчик?
Теоретически — да, с 8 ГБ swap и отключением всех возможных сервисов (Puma до 1 воркера, Sidekiq до 5 потоков, выключение Prometheus). Но практически — вы будете тратить больше времени на ожидание загрузки страниц, чем на написание кода. Для одного разработчика лучше использовать Gitea или Lightweight-альтернативы.
Сколько места на диске нужно для GitLab?
Чистая установка занимает около 11 ГБ. Для нормальной работы с учетом ОС, логов и небольшого количества репозиториев мы рекомендуем минимум 40 ГБ. Если вы планируете использовать GitLab Container Registry для хранения Docker-образов, место закончится очень быстро — рассчитывайте на 100 ГБ+.
Нужен ли выделенный IP для GitLab?
Да, для корректной работы SSL через Let's Encrypt и удобного доступа по домену выделенный IPv4 необходим. Большинство VPS провайдеров включают его в стоимость, но в 2024 году некоторые начали взимать за него дополнительные $1-2.
Что делать, если GitLab выдает ошибку 502 после установки?
Подождите 2-3 минуты. GitLab долго инициализирует базу данных и сервисы Rails. Если ошибка не исчезает, выполните `gitlab-ctl status`, чтобы найти упавший сервис. В 90% случаев это Sidekiq или Puma, которым не хватило оперативной памяти (проверьте `dmesg | grep -i oom`).
Author