Собственный Git-сервер.
Репозиторий — это оргструктура.

Почти любой спор о self-hosting Git — это спор об исходном коде, а исходный код — как раз та часть, которая имеет меньше всего значения. Большая его часть ничем не примечательна, значительная доля — это тонкий слой поверх open-source библиотек, и если бы он утёк завтра, практический ущерб обычно свёлся бы к неловкости, а не к вреду. Именно поэтому фраза «мой код не секрет» кажется исчерпывающим ответом — и именно поэтому она им не является.

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

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

Третья строка — это та строка, которая ловит команды, думающие, что они уже решили этот вопрос. Фордж, установленный вами самостоятельно на машине, арендованной по корпоративной карте под верифицированным аккаунтом компании, вынес приложение с платформы, но оставил личность ровно там же, где она и была. Это реальный выигрыш в контроле — и никакого выигрыша в защите от раскрытия.

А четвёртая строка прямо называет свою цену, потому что остальная часть этого руководства — в основном про то, как её платить. Режим отказа self-hosting — это не слежка, а потеря данных. Платформа хранит резервные копии, о которых вы никогда не задумываетесь. Ваш сервер хранит те резервные копии, которые настроили вы. Шаг 06 — это не необязательный штрих в конце, это шаг, который делает безопасными все остальные пять.

Сначала закажите машину. В панели: Order → VPS → Sentinel, образ Debian 12, в любом бастионе, где вы хотите, чтобы жила ваша история, — Helsinki, Stockholm, Oslo или Reykjavík. Для открытия аккаунта не требуется email, а счёт оплачивается в Monero, Bitcoin, Lightning или любом другом поддерживаемом активе. Здесь это важнее, чем для большинства нагрузок: фордж — единственный сервис, вся ценность которого в том, что запись о вашей работе не привязана к имени.

Затем пройдите чек-лист укрепления защиты в первый час — SSH только по ключу на перенесённом порту, автоматические обновления, файрвол с политикой default-deny — потому что всё дальнейшее предполагает машину, которая ещё не стала чьей-то ещё.

Направьте на машину доменное имя — A-запись и AAAA, если нужна доступность по IPv6, — и дайте ему распространиться, прежде чем начинать, потому что обратный прокси попытается получить сертификат на это имя при первом запуске, а проваленная проверка — так себе способ начать. Затем пропишите правила файрвола, пока ещё ничего не слушает порты.

Проблема двух SSH. Фордж использует SSH для Git, а ваш сервер уже использует SSH для администрирования. Оба не могут владеть портом 22, и именно из-за их смешивания люди получают административный демон, которому вдобавок приходится разбираться в Git. Держите их раздельно: администрирование — на перенесённом порту из руководства по укреплению защиты, Git — на отдельном публичном порту, который пробрасывается в контейнер. 2222 — общепринятый выбор, и в нём нет ничего сакрального.

ufw default deny incoming
ufw allow 47222/tcp                  # administrative SSH, moved
ufw allow 80/tcp                     # ACME HTTP-01 challenge
ufw allow 443/tcp                    # the web interface
ufw allow 2222/tcp                   # git over SSH, into the container
ufw enable
ufw status numbered

# Nothing else is open. In particular: PostgreSQL stays on the Docker
# network and is never published to the host, let alone the internet.

Устанавливайте Docker из официального репозитория, а не из пакета дистрибутива, чтобы Compose v2 был доступен, а версия оставалась актуальной. Затем создайте каталог для стека и сделайте его единственным местом на машине, которое хранит состояние — именно этот каталог резервирует шаг 06.

curl -fsSL https://get.docker.com | sh
docker compose version

install -d -m 0750 /srv/forgejo
cd /srv/forgejo

Вставьте свой публичный ключ в настройки профиля, а затем научите свой клиент, где находится фордж. Поскольку Git работает на нестандартном порту, запись в вашем SSH-конфиге стоит тех тридцати секунд — она убирает порт из каждого URL, который вам когда-либо придётся набирать, и делает remote переносимыми.

# ~/.ssh/config
Host git.example.com
    Port 2222
    User git
    IdentityFile ~/.ssh/id_ed25519

# Then, in any repository:
git remote set-url origin git@git.example.com:you/project.git
git push -u origin main
ssh -T git@git.example.com        # expect a greeting, not a shell

Именно последняя команда говорит вам, согласны ли друг с другом проброс портов, SSH-сервер контейнера и ваш ключ. Приветствие от Forgejo означает, что вся цепочка работает. Запрос пароля означает, что вместо этого вы попали на административный sshd хоста, и проброс портов настроен неверно.

Теперь подпишите свои коммиты. Это тот шаг, который пропускает большинство руководств по self-hosting, а на self-hosted фордже он важнее, чем на платформе. Поле автора коммита — это произвольный текст: любой, кто может сделать push, может вписать туда ваше имя. Подпись — это доказательство того, что конкретный ключ создал конкретный коммит, и это доказательство остаётся в силе даже после того, как сервер, на который был отправлен push, скомпрометирован, перенесён или выброшен. Git умеет подписывать тем же SSH-ключом, который у вас уже есть, так что обходной путь через PGP больше не нужен:

git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git config --global commit.gpgsign true
git config --global tag.gpgsign true

git commit --allow-empty -m "signed"
git log --show-signature -1

Затем добавьте тот же публичный ключ в фордже во второй раз — как ключ для подписи, а не для аутентификации. Forgejo проверяет подпись на стороне сервера и показывает коммит как verified; без этой второй записи у него нет способа связать подпись с вашим аккаунтом, и каждый коммит будет показан как unverified, даже если подписан правильно.

Deploy-ключи — для машин, которым нужно только читать. Продакшен-серверу, сборочной машине или зеркалу не нужен пользовательский аккаунт на фордже. Вместо этого выдайте deploy-ключ: пара ключей, добавленная к одному репозиторию, только для чтения, если явно не разрешена запись, и не дающая доступа ни к чему другому на инстансе. Отозвать его — значит удалить одну запись. Это самая эффективная привычка для поддержания порядка на self-hosted фордже, потому что пользовательские аккаунты накапливают права, а deploy-ключи — нет.

Миграция с платформы — удобный момент сделать всё это как следует. Мастер New Migration в Forgejo берёт URL репозитория и токен доступа и переносит ветки, теги, issues, комментарии, метки, вехи, релизы и pull requests. Сначала прогоните один репозиторий, чтобы увидеть форму результата, ожидайте, что лимиты API будут замедлять крупные партии, и держите источник в режиме только для чтения несколько недель, а не удаляйте его в тот же день.

Git здесь необычно всепрощающий, и стоит точно объяснить почему. Каждый клон — это полная копия истории, так что пока у хотя бы одного разработчика есть актуальная рабочая копия, код переживает сервер. Это по-настоящему успокаивает — и покрывает ровно одну из двух вещей, которые хранит ваш фордж. Другая — issues, обсуждения pull request, ветки ревью, релизы, страницы wiki, пользователи, команды, права доступа, история CI — существует только в базе данных, ни у кого нет её клона, и это обычно та часть, на накопление которой ушло три года.

Сначала push-зеркало. Оно бесплатное и работает само по себе. В репозитории: Settings → Mirror settings → добавьте push-зеркало с URL и токеном доступа для назначения. После этого Forgejo реплицирует каждую ветку и тег после каждого push — во второй Forgejo, в Codeberg или на платформу, которую вы решили оставить в роли витрины, а не дома. Одна оговорка, которую стоит проговорить прямо: push-зеркало добросовестно публикует заново всю историю, включая секрет, который вы собирались удалить.

Затем настоящая резервная копия — и это не встроенный архив. В Forgejo есть команда forgejo dump, которая упаковывает конфигурацию, репозитории, данные и дамп базы данных в единый zip-архив. Это по-настоящему полезная вещь, чтобы передать мейнтейнеру при сообщении об ошибке. Но не то, на что стоит полагаться, чтобы вернуться с того света: SQL, который она производит, имеет давно известные проблемы при повторном импорте, а архив каждый раз пересобирает весь набор репозиториев заново, что на реальном инстансе означает большой файл, который пишется с нуля каждую ночь. Используйте вместо этого скучный, проверяемый путь — сделайте дамп базы данных её собственным инструментом и заберите каталог данных в резервную копию как файлы:

#!/bin/sh
# /usr/local/bin/forgejo-backup — run from a systemd timer, nightly
set -eu
cd /srv/forgejo

# 1. Consistent database dump, written next to the data.
docker compose exec -T db pg_dump -U forgejo -Fc forgejo > ./db.dump

# 2. Everything that matters, to an encrypted offsite repository.
restic backup ./data ./db.dump ./docker-compose.yml ./.env ./Caddyfile

# 3. Retention, then prove the repository is still readable.
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune
restic check

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

Затем один раз, намеренно, восстановите её. Закажите тестовый VPS, восстановите на него снапшот, поднимите тот же файл Compose поверх восстановленного каталога данных, загрузите дамп базы данных, направьте на него запись в hosts-файле и войдите в систему. Засеките время на всё это. Именно это число — а не сам факт наличия задания резервного копирования — и есть ваша реальная позиция по восстановлению, и у каждого, кто проделывал это упражнение, в первый раз находилась хотя бы одна вещь, пропущенная в списке включения.

# restic keeps absolute paths, so the stack reappears under the target.
restic restore latest --target /srv/restore
cd /srv/restore/srv/forgejo

docker compose up -d db                # empty volume: the entrypoint creates the database
docker compose exec -T db pg_restore -U forgejo -d forgejo \
  --clean --if-exists --no-owner < db.dump

docker compose up -d                   # then sign in and walk the issue tracker

Обновления, кратко. Закрепляйте образ за мажорной версией, а не за :latest, чтобы автоматический pull не перенёс вас через breaking change, пока вы спите. Читайте release notes перед пересечением мажорной границы, сначала делайте снапшот и помните, что миграция базы данных запускается при первом старте новой версии — а это дверь в один конец. Автообновление в стиле Watchtower — неплохая идея для статического сайта и плохая для машины, которая хранит все ваши ветки.

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