GitHub Actions vs GitLab CI vs Gitea Actions у 2026: що обрати для self-hosted CI/CD

GitHub Actions vs GitLab CI vs Gitea Actions у 2026: що обрати для self-hosted CI/CD

У трьох попередніх частинах ми виконали одну задачу тричі. Сценарій щоразу був той самий: push у main, збірка, тести, викладка на продакшн через SSH, перевірка, що застосунок піднявся. Змінювалася лише платформа.

Тепер ці три рішення варто покласти поруч. Не для того, щоб визначити переможця, бо його немає: усі три роблять роботу, і будь-яку з них можна довести до робочого стану. Питання інше — яке з них дасть менше зайвої роботи саме вашій команді, з її кодом, вимогами і кількістю часу на адміністрування.

1.1 Що саме порівнюємо

Умови для всіх трьох однакові: код у приватному репозиторії, збірка і деплой виконуються на вашому VPS, продакшн у закритій мережі, доступ по SSH з окремим користувачем без прав root.

Ключова річ, яку ця серія показала на практиці: self-hosted runner відповідає на питання, де виконується код, і не відповідає на питання, де він зберігається. Це два різні рішення, і плутанина між ними породжує більшість помилок при виборі.

2. Конфіг-файл і структура

2.1 Де живе конфігурація

Різниця не косметична. У GitHub і Gitea перевірки на pull request, нічне сканування і реліз за тегом лежать окремими файлами, які редагуються незалежно. У GitLab точка входу одна, а поділ робиться через include, і це дає інший ефект: конфігурацію легко централізувати в окремому репозиторії шаблонів і підключати десятками проєктів.

2.2 Ієрархія

GitHub Actions і Gitea Actions мають однакову будову: on → jobs → steps. Стадій як окремої сутності немає, порядок задається через needs.

GitLab CI будується інакше: stages → задачі → script. Стадії оголошуються явно і виконуються послідовно, а кроків усередині задачі немає — є список команд.

# GitHub / Gitea
jobs:
  build:
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm run build

# GitLab
stages: [build, test, deploy]

build:
  stage: build
  script:
    - npm ci
    - npm run build

Практичний наслідок видно на великому pipeline. Стадії GitLab читаються згори вниз як порядок виконання, і це зручно, коли конфіг переглядає людина ззовні: аудитор, новий інженер, замовник. Модель GitHub гнучкіша, але щоб побачити порядок, треба простежити ланцюжок needs між задачами.

2.3 Оточення задачі

У GitLab образ вказується на рівні задачі ключем image, і це базовий спосіб роботи: задача виконується у контейнері.

У GitHub і Gitea контейнер це опція. За замовчуванням кроки виконуються прямо на runner, а для запуску у контейнері є ключ container на рівні задачі. Потрібні версії мов частіше ставляться діями setup-node, setup-python і подібними.

# GitLab: контейнер за замовчуванням
test:
  image: node:20
  script: [npm test]

# GitHub / Gitea: версія через дію
jobs:
  test:
    steps:
      - uses: actions/setup-node@v4
        with: { node-version: '20' }
      - run: npm test

2.4 Умовний запуск

Тут логіка різна, і при міграції це місце потребує уваги.

У GitHub і Gitea ключ if ставиться на задачу або на крок і обчислює вираз:

deploy:
  if: github.ref == 'refs/heads/main'

У GitLab список rules перевіряється згори вниз, спрацьовує перше правило, що збіглося, і воно визначає не тільки запуск, а й поведінку задачі:

deploy:
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
      when: manual
      allow_failure: false
    - when: never

Різниця у можливостях: rules вирішує одразу три питання — чи потрапить задача у pipeline, чи буде вона ручною, чи блокує вона результат. У GitHub і Gitea те саме збирається з кількох механізмів: if, workflow_dispatch, environment з підтвердженням.

3. Secrets і змінні

3.1 Синтаксис

GitHub і Gitea звертаються до секретів однаково, через контекст:

run: ./deploy.sh
env:
  KEY: ${{ secrets.SSH_PRIVATE_KEY }}

GitLab підставляє секрет як звичайну змінну оточення, без окремого простору імен:

script:
  - ./deploy.sh
variables:
  KEY: $SSH_PRIVATE_KEY

За цим стоїть різниця у моделі. У GitHub і Gitea секрет це окрема сутність зі своїм сховищем. У GitLab це змінна з прапорцями захисту, і саме прапорці визначають, наскільки вона захищена. Звідси головне правило четвертої частини: Masked без Protected не захищає ні від чого серйозного.

3.2 Рівні зберігання

Один рядок тут вирішує більше за решту. Оточень у Gitea немає, тому розділення доступів між staging і продакшном доводиться робити вручну: різними іменами секретів, окремими репозиторіями або окремими runner з різними мітками. Для команди з двох людей це дрібниця, для процесу, де деплой на продакшн вимагає підтвердження відповідального, це серйозне обмеження.

4. Runner і executor

Механіка виконання у всіх трьох однакова, і це головне, що варто винести з серії. Агент сам звертається до платформи, забирає задачу з черги, виконує і повертає логи. Платформа нікуди не «штовхає» задачі, тому агенту не потрібні відкриті вхідні порти і біла адреса.

Рядок про паралельність має практичну вагу при плануванні сервера. Один агент GitHub бере одну задачу, тому для чотирьох паралельних збірок реєструються чотири агенти. GitLab і Gitea роблять те саме одним процесом і одним параметром у конфізі.

Рядок про Kubernetes важливий, якщо збірки вже живуть у кластері. У GitLab це вбудований executor, у GitHub це окремий контролер, у Gitea доводиться обходитися контейнерами на VPS.

5. Один deploy, три конфігурації

Задача однакова: викласти зібрані файли на сервер через rsync і перезапустити сервіс. Показані лише блоки деплою, збірка і тести у всіх трьох виглядають однаково.

5.1 GitHub Actions

deploy:
  needs: build
  runs-on: [self-hosted, linux, deploy]
  environment: production
  steps:
    - uses: actions/download-artifact@v4
      with: { name: dist, path: dist/ }

    - name: Підготувати SSH
      run: |
        install -m 700 -d ~/.ssh
        install -m 600 /dev/null ~/.ssh/deploy_key
        echo "${{ secrets.SSH_PRIVATE_KEY }}" > ~/.ssh/deploy_key
        echo "${{ secrets.SSH_KNOWN_HOSTS }}" > ~/.ssh/known_hosts

    - name: Викласти і перезапустити
      run: |
        rsync -az --delete -e "ssh -i ~/.ssh/deploy_key" \
          dist/ deploy@${{ secrets.DEPLOY_HOST }}:/var/www/app/
        ssh -i ~/.ssh/deploy_key deploy@${{ secrets.DEPLOY_HOST }} \
          "sudo systemctl restart app.service"

    - name: Прибрати ключ
      if: always()
      run: rm -f ~/.ssh/deploy_key

5.2 GitLab CI

deploy-production:
  stage: deploy
  tags: [self-hosted, shell]
  environment:
    name: production
    url: https://app.example.com
  dependencies: [build]
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
      when: manual
      allow_failure: false
  before_script:
    - chmod 600 "$SSH_PRIVATE_KEY"      # змінна типу File
  after_script:
    - shred -u "$SSH_PRIVATE_KEY" 2>/dev/null || rm -f "$SSH_PRIVATE_KEY"
  script:
    - |
      rsync -az --delete \
        -e "ssh -i $SSH_PRIVATE_KEY -o UserKnownHostsFile=$SSH_KNOWN_HOSTS" \
        dist/ deploy@$DEPLOY_HOST:/var/www/app/
    - |
      ssh -i "$SSH_PRIVATE_KEY" -o UserKnownHostsFile="$SSH_KNOWN_HOSTS" \
        deploy@$DEPLOY_HOST "sudo systemctl restart app.service"

5.3 Gitea Actions

deploy:
  needs: build
  runs-on: deploy              # мітка host-режиму
  steps:
    - uses: actions/download-artifact@v3   # v4 потребує API GitHub
      with: { name: dist, path: dist/ }

    - name: Підготувати SSH
      run: |
        install -m 700 -d ~/.ssh
        install -m 600 /dev/null ~/.ssh/deploy_key
        echo "${{ secrets.SSH_PRIVATE_KEY }}" > ~/.ssh/deploy_key
        echo "${{ secrets.SSH_KNOWN_HOSTS }}" > ~/.ssh/known_hosts

    - name: Викласти і перезапустити
      run: |
        rsync -az --delete -e "ssh -i ~/.ssh/deploy_key" \
          dist/ deploy@${{ secrets.DEPLOY_HOST }}:/var/www/app/
        ssh -i ~/.ssh/deploy_key deploy@${{ secrets.DEPLOY_HOST }} \
          "sudo systemctl restart app.service"

    - name: Прибрати ключ
      if: always()
      run: rm -f ~/.ssh/deploy_key

5.4 Що з цього видно

• GitHub і Gitea майже збігаються. Відмінності зводяться до мітки у runs-on, версій дій і відсутності environment.
• GitLab бере на себе більше роботи з ключем. Змінна типу File створює тимчасовий файл сама, тому кроків з echo немає.
• Ручний крок реалізується по-різному. У GitLab це when: manual у правилі, у GitHub це environment з рецензентом, у Gitea окремий workflow з workflow_dispatch.
• Готові дії спокушають скрізь. Крок з appleboy/ssh-action коротший за ручний rsync, але у Gitea він тягнеться з GitHub, а на постійному runner будь-яка стороння дія бачить ваші секрети. Для одного rsync і одного ssh вигода не варта залежності.
• Прибирання ключа обов'язкове всюди. Оточення на self-hosted runner постійне, і забутий ключ лишається доступним наступній задачі, з якої завгодно гілки.

6. Порівняльна таблиця

Про безкоштовні хвилини свідомо без цифр: тарифи змінюються частіше, ніж оновлюються статті. Загальна картина стабільна — GitHub дає безлімітні хвилини публічним репозиторіям і обмежену квоту приватним, GitLab дає квоту на безкоштовному тарифі, Gitea не рахує нічого, бо все виконується у вас. Актуальні цифри звіряйте на сторінках тарифів. Головне тут інше: хвилини на власному runner не рахуються у жодній з платформ, тому квота перестає бути аргументом, щойно ви поставили свій агент.

7. Кому що підходить

7.1 GitHub Actions

• Проєкт уже на GitHub. Найсильніший аргумент, який перекриває решту: переносити репозиторій заради CI майже ніколи не варто.
• Open source. Публічні репозиторії отримують хмарні збірки без обмеження хвилин, і власний агент їм не потрібен, ба більше — не рекомендований.
• Потрібні готові кроки. Marketplace закриває типові задачі одним рядком: збірка образів, публікація пакетів, звіти покриття.
• Команда без досвіду з CI. Найнижчий поріг входу: файл редагується прямо у браузері, помилки видно одразу.

Проти: на self-hosted агенті обережність з чужими діями стає обов'язковою, а частина того, що у GitLab вбудовано (звіти, історія деплоїв), збирається зі сторонніх кроків.

7.2 GitLab CI

• Команда вже на GitLab. Той самий аргумент, що і вище, дзеркально.
• Складні pipeline. Стадії, граф залежностей, дочірні pipeline і матриці дають більше контролю на конфігураціях з десятками задач.
• Багато проєктів з однаковими налаштуваннями. Змінні рівня групи і include з централізованого репозиторію шаблонів економлять помітно.
• Потрібні аудит і прозорість. Явний порядок стадій читається людиною ззовні без розбору залежностей, а історія деплоїв показує, який коміт зараз на продакшні.
• Kubernetes прямо зараз. Вбудований executor без окремого контролера.

Проти: власна інсталяція GitLab це помітно важчий сервіс, ніж Gitea. Якщо потрібен саме закритий контур, а не складні pipeline, цей варіант дорожчий за ресурсами.

7.3 Gitea Actions

• Код не повинен покидати вашу інфраструктуру. Договірні зобов'язання, ізольована мережа, повний контроль над даними.
• Невелика команда і один сервер. Git-платформа і runner живуть на тому самому VPS, ресурсів потрібно менше, ніж GitLab.
• Досвід з GitHub Actions уже є. Синтаксис переноситься майже цілком, перевчатися не доводиться.
• Бюджет. Немає оплати за користувача, тільки вартість сервера.

Проти: немає оточень з підтвердженням, немає історії деплоїв, немає Kubernetes, а екосистема дій обмежена. Плюс усе адміністрування ваше: бекапи, оновлення, HTTPS, дзеркало дій для закритого контуру.

8. Висновок

Серія починалася з питання, що таке CI/CD, і закінчується вибором з трьох робочих інструментів. Що варто забрати з неї цілком:

• Два різні питання. Self-hosted runner вирішує, де виконується код. Де він зберігається — окреме рішення, і плутанина між ними породжує більшість помилок при виборі платформи.
• Якщо код може лежати у хмарі — беріть ту платформу, на якій команда вже працює, і додайте власний агент. Це найдешевший шлях до контролю над ресурсами і доступом до закритої мережі.
• Якщо код має лишатися у вас — Gitea для невеликої команди, self-managed GitLab там, де потрібні складні pipeline і повний набір вбудованих можливостей.
• Механіка скрізь однакова. Агент опитує чергу, виконує задачу, повертає логи. Освоївши одну платформу, ви читаєте конфіги решти без словника.
• Постійне оточення вимагає дисципліни. Прибирання ключів, тайм-аути, обмеження на паралельність і обережність зі сторонніми діями. Це плата за швидкість і контроль.

Практичний план для того, хто починає з нуля: підніміть найпростіший pipeline з двох кроків на поточній платформі, доведіть його до зеленого стану, і лише потім додавайте власний runner. Деплой підключайте останнім, коли збірка і тести вже стабільні. Такий порядок дає працюючий результат за кілька днів замість кількох тижнів на налаштування всього одразу.

Часті питання