Почему мы подняли свой Gitea и перестали пушить скрипты в GitHub

У нас в «АйТи-Фреш» за последние пару лет скопилось приличное хозяйство: раннеры для СБИС, скрипты бэкапов, обработки для 1С, конфиги для Marzban и Zabbix. Всё это долго жило в приватных репозиториях GitHub — и в какой-то момент я понял, что мне не по себе от одной мысли, где физически лежит код с паролями от клиентских серверов. Рассказываю, почему мы подняли свой Gitea и что из этого вышло.

С чего вообще начались вопросы

Мы обслуживаем полсотни клиентов, и почти под каждого рано или поздно пишется что-то своё: обработка для 1С, скрипт синхронизации с банком, мониторинг для Zabbix, коннектор к 1С-Отчётности. Всё это накапливается годами. У нас таких репозиториев набралось под тридцать, и половина из них — не открытый код для публикации, а рабочие инструменты с секретами внутри: IP-адреса клиентских серверов, логины для WinRM, токены для API.

Пока это лежало в паре приватных репо на GitHub, вопросов не возникало. Но когда счёт пошёл на десятки, а в коммитах стали мелькать куски конфигов pfSense и строки подключения к SQL — я начал задавать себе неудобный вопрос. А что если у GitHub случится утечка? Такое бывало и с куда более крупными платформами. И что если завтра аккаунт заблокируют по ошибке — а такое я видел у коллег, банили компании из-за формальных придирок к содержимому репозитория, и восстановить доступ было той ещё историей.

Почему GitHub — не то место для внутренней кухни

GitHub отличный сервис, я сам им пользуюсь для открытых проектов. Но у него есть особенность, о которой не думаешь, пока не столкнёшься: это чужая инфраструктура за периметром твоей компании. Код, коммиты, история изменений, вебхуки с секретами — всё физически лежит на серверах в США. Формально это нормально для большинства бизнесов. Но когда в коде фигурируют реальные IP клиентов, пароли от их 1С и структура внутренних сетей — это уже совсем другой уровень риска.

Плюс банальная зависимость. У нас был случай в 2025 году, когда GitHub на пару часов лёг целиком — не критично, но раннер СБИС не смог подтянуть обновлённый скрипт с сервера, и пришлось разбираться руками. Мелочь, а неприятно. А ещё есть чисто экономический момент: приватные организации на GitHub с расширенным доступом стоят денег, и за тридцать репозиториев с несколькими участниками набегает заметная сумма в год — притом что мощности используешь на 3 процента.

Почему выбрали именно Gitea, а не GitLab

GitLab CE тоже вариант, я его пробовал разворачивать под другую задачу. Но это тяжёлая штука — минимум 4 гигабайта оперативки только под сам сервис, куча сервисов внутри (Redis, PostgreSQL, Sidekiq, отдельный Puma), и обновления иногда ломают что-то по мелочи. Для команды из трёх-пяти разработчиков это как забивать гвоздь микроскопом.

Gitea — это один Go-бинарник плюс SQLite или Postgres, поднимается на VPS с 1 гигабайтом памяти и не просит взамен ничего лишнего. Интерфейс почти один в один повторяет GitHub — issues, pull requesty, вики, релизы, встроенный CI через Gitea Actions, который синтаксически совместим с GitHub Actions. Переносить существующие workflow с GitHub оказалось делом получаса, а не переписывания заново.

Ещё есть форк Forgejo — по сути тот же Gitea, но с community-управлением после истории с коммерциализацией. Мы посмотрели, но решили не усложнять: для внутреннего использования разница не принципиальна, а документации и готовых докер-образов у Gitea банально больше.

Как разворачивали у себя

Взяли отдельную VM на нашей же площадке — не хотелось сажать git-сервер рядом с продуктивными сервисами клиентов, мало ли что. 2 vCPU, 4 гигабайта RAM, 40 гигабайт диска с запасом под годы роста репозиториев. Поставили через docker-compose — там буквально два контейнера: сам Gitea и Postgres рядом. Минут двадцать на первый запуск, включая настройку домена и выпуск сертификата через Let's Encrypt.

Дальше — обвязка. Закрыли админку и SSH-доступ на git по IP через firewall, оставили только наши рабочие адреса и VPN. Включили обязательную двухфакторку для всех аккаунтов — это заняло пять минут, а нервов сэкономило много. Настроили runner для Gitea Actions прямо на этой же VM: сборка, линтеры, автотесты для python-скриптов гоняются локально, не улетая никуда наружу.

Отдельно вынесли бэкапы. Gitea умеет штатно дампить всё — базу, репозитории, вложения — одной командой gitea dump. Мы повесили это на cron раз в сутки с выгрузкой на наш FTP-хранилище, плюс раз в неделю снимок всей VM целиком через Veeam. Дважды пригождалось — один раз после неудачного обновления версии, второй раз просто по человеческой ошибке с force push в чужую ветку.

Что реально изменилось в работе

Самое приятное — это ощущение контроля. Когда я захожу на git.itfresh внутренний адрес и вижу список репозиториев, я точно знаю, где физически лежат эти данные и кто к ним имеет доступ. Не нужно гадать, применились ли настройки приватности, не проверяет ли кто-то посторонний список коллабораторов через дыру в правах организации.

Второе — скорость. Клонирование и пуш внутри своей же локальной сети происходят почти мгновенно, особенно ощутимо на репозиториях с крупными файлами — у нас там иногда лежат дампы конфигов на сотни мегабайт. Через GitHub такие операции с домашнего интернета иногда подтормаживали.

Третье, не менее важное — вебхуки. Раньше, чтобы GitHub мог дёрнуть наш внутренний сервер при пуше, приходилось городить туннели или публиковать эндпоинт наружу с дополнительной защитой. Теперь Gitea и целевой сервис сидят в одной локальной сети, вебхук летит по внутреннему IP без всякого проброса портов на белый свет.

Какие грабли встретили

Первая проблема — обновления. Gitea выпускает релизы часто, и если запустить и забыть, через полгода можно упереться в устаревшую версию с закрытыми уязвимостями, которые никто не патчил. Завели себе простое правило: обновляем раз в квартал, читаем changelog, сначала тестируем на копии VM, потом уже на боевой.

Вторая — человеческий фактор. На GitHub привыкли, что если случайно удалил репозиторий, можно написать в поддержку и в течение суток что-то восстановят. У себя такой подстраховки нет — есть только твои бэкапы. После одного испуга, когда коллега случайно снёс ветку с полугодовой историей правок обработки для клиента, мы включили защиту веток и обязательные pull request для всего, что касается production-скриптов.

Третья мелочь, но раздражающая — мониторинг самого Gitea. Мы же теперь сами отвечаем за аптайм git-сервера, а не перекладываем это на инфраструктуру GitHub. Добавили простую проверку в Zabbix — пинг эндпоинта и проверку места на диске, благо диск с историей коммитов на удивление быстро съедает гигабайты, если хранить бинарники в репозиториях.

Кому это вообще нужно

Если у вас один разработчик и десяток публичных пет-проектов — оставайтесь на GitHub, не усложняйте. А вот если в компании есть свой IT-отдел, который пишет внутренние интеграции, скрипты автоматизации, обработки для 1С с реальными данными клиентов — переезд на свой git оправдан почти всегда, и порог входа сейчас смешной: одна недорогая VPS за 500-800 рублей в месяц закрывает потребности отдела до 15-20 человек с запасом на годы вперёд.

Отдельно скажу для бухгалтерских и юридических фирм, которые тоже иногда обзаводятся собственными скриптами автоматизации отчётности — там вопрос конфиденциальности стоит даже острее, чем в обычном IT. Если в репозитории мелькают реквизиты клиентов или доступы к банк-клиенту, держать это на стороннем сервисе, даже приватно, лишний повод для беспокойства, который решается за один вечер настройки.

Частые вопросы

Сколько стоит содержать свой Gitea в месяц?
У нас вся история умещается в одну VPS за 500-800 рублей в месяц — этого достаточно для отдела до 20 человек и десятков репозиториев. Для сравнения, организация на GitHub с приватным доступом и несколькими участниками за год легко набегает на сумму в несколько раз больше.

Сложно ли перенести существующие репозитории с GitHub?
Нет, Gitea умеет мигрировать репозитории прямо из интерфейса — вставляешь ссылку на GitHub-репозиторий и токен доступа, и она сама затягивает историю коммитов, issues и вики. У нас перенос тридцати репозиториев занял один рабочий день, включая перепроверку прав доступа.

А что с CI/CD, есть аналог GitHub Actions?
Да, Gitea Actions работает почти по тем же yml-файлам, что и GitHub Actions, с небольшими отличиями в доступных экшенах. Мы просто скопировали существующие workflow и поправили пару строк — всё завелось без переписывания заново.

Что если сервер с Gitea выйдет из строя, потеряем весь код?
Только если забить на бэкапы. У нас ежедневный дамп через встроенную команду gitea dump плюс еженедельный снимок всей VM. Восстановление из такого дампа занимает минут двадцать, мы это проверяли не в теории, а на практике.