Gitea как замена GitHub: почему для пет-проектов и коммерческой разработки я выбрал свой Git-сервер

На днях я пилил новую фичу в одном из своих пет-проектов: агент сделал правки, аккуратно закоммитил, запушил ветку, открыл Pull Request — и пайплайн внезапно покраснел. Захожу в логи, ожидая опечатку или упавший тест Pest, а там сюрприз от GitHub:

The job was not started because recent account payments have failed or your spending limit needs to be increased. Please check the ‘Billing & plans’ section in your settings.

Приехали. 2 000 бесплатных минут в месяц на приватные репозитории закончились. Казалось бы, в чем проблема? Закинь пару баксов на баланс и работай дальше. Но карта российская, зарубежный эквайринг её отбивает, spending limit в профиле жестко стоит на нуле, а до конца месяца ещё пара недель.

И в этот момент меня осенило, насколько сильно изменился сам рабочий процесс за последний год. Раньше, когда код писался строго руками по вечерам, две тысячи минут в месяц казались бесконечностью: сделал два-три коммита в день, раз в неделю собрал релиз — дай бог набежит пара сотен минут раннеров.

Сейчас мой рабочий стек выглядит иначе. В фоне у меня постоянно крутятся AI-агенты (Claude Code, Hermes Agent). Агент работает короткими быстрыми итерациями по TDD: написал тест — запушил — проверил результат в CI — подправил — снова запушил. За один вечер плотной работы с агентом набегает по 20–30 пушей и прогонов.

А каждый прогон для современного Laravel-проекта — это не просто «запустить PHPUnit». Это матрица тестов под PHP 8.3 и 8.4, статанализ PHPStan, форматирование Laravel Pint и сборка фронта через Vite. Два-три прогона — это уже 10 минут раннера. В таком темпе гитхабовская бесплатная квота испаряется буквально за первые несколько дней активной разработки.

А мержить код, сгенерированный нейросетью, вслепую без прогона тестов — это верный способ превратить пет-проект в минное поле. Нужно было срочно решать, куда съезжать.

Почему не GitLab и не облака

Первая мысль, которая возникает у любого бэкендера при слове self-hosted — поднять старый добрый GitLab CE. Но я быстро отмёл эту идею. GitLab — это гигантский комбайн. В состоянии полного покоя этот монстр съедает от 4 до 8 гигабайт оперативной памяти просто на то, чтобы крутить свои демоны и веб-морду. Арендовать отдельную жирную виртуалку за пару-тройку тысяч рублей в месяц только ради того, чтобы хранить десяток приватных репозиториев — откровенный перебор.

Вторая альтернатива — российские облачные сервисы вроде GitVerse от Сбера или GitFlic. Они нормальные, карты принимают, под санкции не попадают. Но переходить из одного чужого облака в другое — это менять шило на мыло: ты снова зависишь от чужой политики тарифов, очередей на публичные раннеры и условий платформы. Мне же хотелось полной автономности: чтобы код жил у меня, а тесты крутились столько, сколько нужно.

Почему я выбрал Gitea

В итоге я развернул Gitea на своем домашнем сервере (обычный мини-ПК на Ubuntu, где у меня уже крутится несколько контейнеров). И это оказалось идеальным попаданием.

Во-первых, она практически невесомая. Gitea написана на Go. Весь сервис в Docker вместе с базой SQLite потребляет около 150–200 мегабайт оперативки. Она спокойно живет рядом с рабочими сервисами и даже не замечает нагрузки.

Во-вторых, интерфейс не вызывает отторжения. Разработчики Gitea не стали изобретать велосипед: структура веток, удобный просмотр diff-ов, inline-комментарии при ревью Pull Request, Issues и релизы визуально и функционально повторяют GitHub. Не приходится ломать мышечную память.

Но самое главное — это встроенный движок Actions и раннер act_runner.

Раннер для Gitea построен на базе известной утилиты nektos/act. И его главная киллер-фича: он нативно понимает файлы .github/workflows/*.yml! Мне вообще не пришлось переписывать свои пайплайны. Те же шаги сборки, те же экшены настройки PHP и композера — раннер просто берет Docker-сокет сервера, на лету поднимает нужный контейнер и прогоняет билд ровно так же, как это делал GitHub.

Как это устроено в проде

Вся связка из Git-сервера и раннера поднимается буквально одним docker-compose.yml:

services:
  gitea:
    image: gitea/gitea:latest
    container_name: gitea
    environment:
      - USER_UID=1000
      - USER_GID=1000
      - GITEA__database__DB_TYPE=sqlite3
      - GITEA__database__PATH=/data/gitea/gitea.db
      - GITEA__actions__ENABLED=true
    volumes:
      - ./data:/data
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    ports:
      - "3001:3000"
      - "2222:22"
    restart: always

  runner:
    image: gitea/act_runner:latest
    container_name: gitea_runner
    environment:
      - GITEA_INSTANCE_URL=http://gitea:3000
      - GITEA_RUNNER_REGISTRATION_TOKEN=your_token_here
      - GITEA_RUNNER_NAME=home-runner
    volumes:
      - ./runner-data:/data
      - /var/run/docker.sock:/var/run/docker.sock
    depends_on:
      - gitea
    restart: always

Токен для регистрации раннера генерируется в админке Gitea за пару кликов (Панель управления → Actions → Runners). После запуска раннер цепляется к серверу и начинает слушать очередь задач.

Для работы из консоли я поставил утилиту tea (официальный CLI от Gitea, прямой аналог гитхабовского gh). Логинишься через токен приложения — и прямо из терминала можно смотреть статус сборок, открывать PR и управлять ветками. А чтобы git push и clone по HTTPS не спрашивали пароль каждый раз, в конфиге гит прописывается хелпер:

git config --global credential.https://git.yourdomain.ru.helper "!tea login helper"

Подводные камни: о чем стоит помнить

Было бы нечестно петь одни дифирамбы и не упомянуть о нюансах self-hosted подхода. Их немного, но они реальные:

1. Бэкапы — теперь только твоя забота. На GitHub мы привыкли, что код лежит где-то в облаке и никуда не пропадет. На своем сервере нужно позаботиться об этом самому. В моем случае вся база — это SQLite-файл, а репозитории лежат в одной папке ./data, поэтому ночной cron-скрипт с бэкапом архива в зашифрованное облако решает вопрос полностью.

2. Сеть и домен. Чтобы пушить код не только из домашнего Wi-Fi, сервер нужно выставить наружу через реверс-прокси (Nginx или Caddy с SSL-сертификатом) или ходить через VPN/Tailscale.

3. Публичный Open Source все равно остается на GitHub. Если вы пишете публичные библиотеки или хотите показывать портфолио работодателям — GitHub по-прежнему незаменим, потому что это главная социальная сеть для разработчиков со звездами и комьюнити. Но для приватных коммерческих заказов, клиентских сайтов и домашних микросервисов Gitea закрывает все задачи на 100%.

Сейчас у меня на Gitea крутится уже больше двадцати репозиториев. Агенты непрерывно коммитят и гоняют тесты, раннер отрабатывает за минуту прямо на локальном железе, а я больше не вздрагиваю от уведомлений о закончившемся лимите минут.