Большинство разработчиков привыкли использовать GitHub как стандартное место для хранения репозиториев, так как это удобно, бесплатно и глубоко интегрировано в рабочий процесс. Однако стремление к полному контролю над собственной инфраструктурой побудило автора перевести свои проекты на самохостинг. Выбор пал на Forgejo — свободный Git-сервер, являющийся форком Gitea.
Особенности развертывания и миграции репозиториев
Развертывание Forgejo было выполнено на домашнем сервере с ОС Debian с использованием Portainer Stacks в Docker. Первоначальная настройка потребовала коррекции параметров URL и SSH-домена, чтобы избежать проблем с перенаправлением. Для обеспечения доступности сервиса извне его пришлось добавить в качестве ресурса в конфигурацию Pangolin.
Процесс миграции двух проектов — одного публичного и одного приватного — оказался достаточно простым. Для импорта репозитория потребовался лишь URL и токен доступа. В рамках миграции были перенесены 443 коммита, 15 веток, 17 тегов и 15 релизов. После завершения процедуры репозитории стали доступны через внешнюю сеть, визуально не отличаясь от стандартных хостинг-решений.
Сохранение привычного рабочего процесса
Главным вопросом оставалось влияние смены сервера на повседневную деятельность. Автор использует следующую цепочку: локальная разработка, отправка изменений (push) в удаленный репозиторий, который по вебхуку уведомляет систему Coolify для автоматического развертывания обновления. Эксперимент показал, что рабочий процесс практически не претерпел изменений.
Были перенастроены вебхуки для совместимости с Gitea и обновлены ключи SSH для доступа к закрытым репозиториям. Все стандартные команды git остались прежними, а интеграция с Coolify продолжила работать в автоматическом режиме без дополнительного вмешательства в дашборд.
Трудности и новые зоны ответственности
Переход на собственную инфраструктуру не лишен компромиссов. Ключевой проблемой стали CI-раннеры. При попытке запустить существующие рабочие процессы GitHub Actions сервис Forgejo выдал ошибку из-за отсутствия подходящего раннера, помеченного как ubuntu-latest. Решение требует регистрации фонового демона раннера на хост-машине, что добавляет технической сложности.
Другим ограничением стала невозможность автоматической миграции пакетов. Например, Docker-образы пришлось либо оставлять в реестре GitHub, либо вручную пересобирать и загружать в реестр Forgejo. Кроме того, ответственность за работоспособность системы теперь целиком лежит на плечах владельца:
- Обеспечение аптайма сервера (в данном случае — 8-летнего ноутбука).
- Настройка резервного копирования данных.
- Обновление программного обеспечения.
- Зависимость от стабильности домашнего интернет-соединения.
Несмотря на появление дополнительных административных задач, автор считает, что устранение внешней зависимости и получение полного контроля над кодовой базой оправдывают затраченные усилия и возникшие сложности.
Предыстория: почему GitHub стал «стандартом по умолчанию»
Важно понимать, что переход на Forgejo не был продиктован ненавистью к платформе GitHub. Автор подчеркивает: «GitHub никогда не был проблемой». Это был путь наименьшего сопротивления, начатый еще в студенческие годы, задолго до эпохи массового внедрения ИИ в разработку. За все время использования накопилось более 50 репозиториев, тысячи коммитов и сотни Pull Request’ов. Никто не выбирает GitHub намеренно — разработчики просто используют Git для контроля версий, а GitHub становится дефолтным местом хранения кода из-за отсутствия накладных расходов, бесплатности и глубокой интеграции в привычный рабочий процесс.
Детали развертывания и первые препятствия
Процесс развертывания был максимально быстрым, однако возникли технические нюансы. Использование Portainer Stacks через Docker позволило запустить Forgejo за считанные минуты, но при первичной настройке автор столкнулся с ошибкой редиректа ROOT_URL. Это произошло из-за того, что при деплое были указаны серверный домен, корневой URL и SSH-домен, что сделало фронтенд недоступным по локальному IP. Решение потребовало добавления сервиса в качестве ресурса в систему Pangolin. Автор отмечает, что история с Pangolin — это отдельная тема, связанная с ограничениями CGNAT (Carrier-Grade NAT), к которой он планирует вернуться в будущем.
Что касается процесса миграции, стоит уточнить: если репозиторий публичный и пользователю не требуется переносить сопутствующие данные (такие как Issues, PR-запросы или релизы), то токен доступа даже не нужен. Это делает переход с внешних сервисов максимально тривиальной задачей.
Анализ рабочего процесса: Forgejo как альтернатива
Forgejo позиционируется как сервер, созданный на базе форка Gitea. Он полностью поддерживает жизненный цикл разработки: хостинг репозиториев, управление задачами, вики-страницы и CI/CD через Forgejo Actions. Это дает разработчику возможность получить «ощущения от использования GitHub» на собственной инфраструктуре.
Важным моментом стало сохранение целостности CI/CD цепочки. Автор опасался, что изменение локации репозитория потребует перестройки всей системы деплоя. Однако, поскольку Forgejo поддерживает вебхуки, совместимые с форматами Gitea, интеграция с Coolify прошла гладко. Автор не менял ничего в продакшн-окружении, а просто клонировал репозиторий, внес изменения, сделал коммит и отправил их в новый пуш. Вебхук сработал автоматически, и Coolify самостоятельно начал процесс сборки — вмешательство в дашборд не потребовалось.
Осознание цены контроля: отказ от комфорта ради независимости
Переход на self-hosting требует принятия факта, что некоторые удобства GitHub придется компенсировать самостоятельно. Основные аспекты, на которые стоит обратить внимание:
- CI-раннеры: Forgejo распознал YAML-файлы GitHub Actions, но выполнение было заблокировано из-за несовместимости метки ubuntu-latest. Хотя Forgejo может исполнять синтаксис GitHub Actions, для этого необходимо регистрировать отдельный фоновый демон-раннер, что является дополнительным трением для пользователя.
- Реестры пакетов: В отличие от кода, Docker-образы не мигрируют автоматически. Это ставит перед разработчиком выбор: либо оставлять зависимость от GitHub Container Registry (GHCR), что обесценивает идею полного self-hosting, либо тратить время на ручную пересборку и перенос образов в собственный реестр Forgejo.
- Hardware и Failure Modes (режимы отказа): Ответственность за инфраструктуру — это не просто настройка софта, а владение всеми «режимами отказа». Учитывая, что домашний сервер автора — это 8-летний рабочий ноутбук, любая потеря интернет-соединения или аппаратный сбой делают невозможным пуш кода или запуск деплоя.
Подводя итог первой недели использования, автор отмечает: это не привело к «магическому улучшению» процесса, но выполнило главную задачу — исключение одной внешней зависимости из цепочки разработки. Это осознанный торговый обмен: немного больше «бумажной работы» и административных хлопот взамен на право владеть собственной инфраструктурой целиком.
