Какой self-hosted Git-сервер выбрать для VPS

Какой self-hosted Git-сервер выбрать

Self-hosted Git-сервер — это не один конкретный продукт, и объем RAM (оперативной памяти) на вашем VPS определяет, какую версию вы можете использовать. Git не требует собственного демона: bare-репозиторий и SSH (secure shell) аккаунт — это уже готовый сервер, который будет работать даже на самом слабом VPS. Всё, что сложнее этого, — это веб-приложение, которое вы запускаете дополнительно, и каждый следующий уровень требует памяти, которой может не быть на бюджетном VPS.

Существует четыре уровня. Bare-репозиторий по SSH, не требующий запуска дополнительных слушающих процессов. cgit — быстрый веб-интерфейс только для чтения, не требующий базы данных. Forgejo или Gitea — полноценная платформа с поддержкой аккаунтов, issue-трекером и pull-реквестами, потребляющая несколько сотен мегабайт. GitLab — решение, которому требуется сервер, значительно превосходящий по ресурсам все остальные варианты.

Определитесь с необходимым функционалом, а затем сопоставьте требования к памяти с характеристиками вашего тарифного плана.

Сколько оперативной памяти на самом деле нужно для каждого варианта

Только два из этих проектов публикуют требования к аппаратному обеспечению. Относитесь к опубликованным цифрам как к минимальному порогу, а не как к гарантии, и измеряйте потребление вашего экземпляра после запуска с помощью systemd-cgtop или ps -o rss= -C forgejo.

[
  {
    "label": "Gitea, small team",
    "ram_gb": 1
  },
  {
    "label": "GitLab, memory constrained",
    "ram_gb": 8
  },
  {
    "label": "GitLab, single node baseline",
    "ram_gb": 16
  }
]

Gitea указывает 1 ГБ оперативной памяти и 2 ядра CPU как достаточный объем для небольших команд и проектов, а также упоминает Raspberry Pi 3 как устройство, подходящее для малых нагрузок. GitLab указывает 16 ГБ в качестве базового уровня для установки на одном узле и 8 ГБ как нижний предел для того, что на их собственной странице называется средой с ограниченным объемом памяти. Forgejo не публикует никаких требований к аппаратному обеспечению. Это форк Gitea, который ведет себя аналогичным образом, поэтому цифры Gitea — это наиболее близкий ориентир из имеющихся.

Что это означает для VPS с 1 ГБ памяти: «голые» репозитории и cgit помещаются с запасом, так как ни один из них не запускает резидентный сервис. Forgejo или Gitea запустятся и будут обслуживать небольшую команду при использовании SQLite, но вы находитесь на самом нижнем пороге, поэтому не запускайте на этом же сервере PostgreSQL и CI (continuous integration) runner. Если веб-интерфейс исчезает без ошибки, выполните sudo dmesg -T | grep -Ei 'oom|out of memory|killed process' и поищите строку вида Out of memory: Killed process 1181 (forgejo): это означает, что процесс был завершен механизмом kernel out of memory killer. GitLab на сервере с 1 ГБ памяти — это не вопрос настройки. Он просто не будет работать.

Уровень 0: «голый» репозиторий по SSH

В Git нет сетевого демона, который нужно запускать. git push по SSH выполняет git-receive-pack на удаленной стороне как обычный процесс Unix, поэтому любая учетная запись, к которой у вас есть доступ по ключу, уже является удаленным Git-репозиторием. Создайте отдельную учетную запись для репозиториев и храните их вне ее домашнего каталога, так как в Ubuntu 24.04 новым домашним каталогам присваиваются права 0750, и веб-интерфейс, добавленный позже, не сможет получить к ним доступ.

sudo adduser --system --shell /bin/bash --gecos 'Git Version Control' \
  --group --disabled-password --home /home/git git
sudo install -d -m 0755 -o git -g git /srv/git
sudo -u git git init --bare /srv/git/project.git

--bare создает репозиторий без рабочей копии, что и требуется для сервера. Попытка выполнить push в активную ветку репозитория, у которого есть рабочая копия, по умолчанию отклоняется с ошибкой refusing to update checked out branch: refs/heads/main — это самая частая ошибка на данном уровне.

Теперь добавьте ключ для этой учетной записи и выполните клонирование.

sudo -u git install -d -m 700 /home/git/.ssh
sudo -u git tee -a /home/git/.ssh/authorized_keys <<'EOF'
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIexamplekeyhere alice@laptop
EOF
sudo -u git chmod 600 /home/git/.ssh/authorized_keys

git remote add origin git@vps.example.com:/srv/git/project.git
git push -u origin main

Первый успешный push завершается сообщением * [new branch] main -> main. Если выполнение завершилось с git@vps.example.com: Permission denied (publickey), значит, аутентификация не была пройдена; в этом случае изучите лог сервера с помощью sudo journalctl -u ssh -n 20. Строка с текстом Authentication refused: bad ownership or modes for file /home/git/.ssh/authorized_keys означает, что права доступа к файлу заданы неверно, так как sshd игнорирует файл ключа, если другие пользователи имеют права на запись в него.

Затем ограничьте доступ к оболочке (shell) для этой учетной записи.

command -v git-shell | sudo tee -a /etc/shells
sudo chsh -s "$(command -v git-shell)" git

git-shell принимает только те немногие команды, которые Git отправляет по SSH, поэтому при попытке интерактивного входа вместо приглашения командной строки теперь будет выводиться сообщение:

fatal: Interactive git shell is not enabled.
hint: ~/git-shell-commands should exist and have read and execute access.

Это весь сервер целиком. Здесь нет базы данных и нет веб-процесса, который нужно обновлять. Вы отказываетесь от всего, что предоставляет полноценная платформа для разработки: нет просмотра кода в браузере, нет системы отслеживания задач, нет pull-реквестов и нет разграничения прав доступа для разных пользователей. Каждый ключ в этом файле позволяет читать и записывать любой репозиторий, принадлежащий пользователю git.

Уровень 1: cgit предоставляет веб-интерфейс без использования базы данных

cgit — это CGI-программа (common gateway interface), написанная на языке C. Веб-сервер запускает её при каждом запросе, она считывает репозитории напрямую с диска и не хранит собственного состояния. В Ubuntu 24.04 она доступна в компоненте universe.

sudo apt update
sudo apt install -y cgit fcgiwrap nginx
sudo install -d -o www-data -g www-data /var/cache/cgit

Укажите путь к каталогу с репозиториями в /etc/cgitrc:

root-title=Git on example.com
css=/cgit.css
logo=/cgit.png
cache-size=1000
cache-root=/var/cache/cgit
snapshots=tar.gz zip
scan-path=/srv/git

scan-path сканирует этот каталог и выводит список всех найденных репозиториев, поэтому новый «голый» (bare) репозиторий появляется в списке без дополнительной настройки. cache-size — это количество кэшируемых страниц; пока значение равно нулю, кэширование отключено. Ознакомьтесь с содержимым файла, который пакет уже разместил в /etc/cgitrc, прежде чем добавлять строки, так как пакеты Debian и Ubuntu содержат свои настройки по умолчанию.

Каждая запись отображает первую строку файла description репозитория, поэтому новый «голый» репозиторий будет отображаться как Unnamed repository; edit this file 'description' to name the repository.. Исправьте это для каждого репозитория:

echo 'Project X, internal tooling' | sudo -u git tee /srv/git/project.git/description

server {
    listen 80;
    server_name git.example.com;
    root /usr/share/cgit;

    try_files $uri @cgit;

    location @cgit {
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME /usr/lib/cgit/cgit.cgi;
        fastcgi_param PATH_INFO $uri;
        fastcgi_param QUERY_STRING $args;
        fastcgi_param HTTP_HOST $server_name;
        fastcgi_pass unix:/run/fcgiwrap.socket;
    }
}

sudo systemctl enable --now fcgiwrap.socket
sudo nginx -t && sudo systemctl reload nginx
systemctl show fcgiwrap.socket -p Listen

Перед началом работы стоит учесть два ограничения. cgit работает только на чтение и не поддерживает авторизацию, поэтому всё содержимое scan-path является публичным: храните приватные репозитории вне этого каталога или настройте HTTP basic authentication для всего сайта. CGI-скрипт выполняется от имени пользователя веб-сервера, поэтому этот пользователь должен иметь права на обход каталога /srv/git и чтение каждого репозитория. Если у пользователя нет прав на вход в каталог, он отобразится как пустой список вместо ошибки.

Уровень 2: Forgejo или Gitea для задач и pull-запросов

Forgejo и Gitea основаны на одной идее: это единственный бинарный файл на языке Go, который предоставляет веб-интерфейс для работы с пользователями, организациями, задачами, pull-запросами, релизами, реестром пакетов и встроенной системой CI. Весь процесс установки сводится к бинарному файлу и базе данных SQLite, поэтому они работают на оборудовании, которое не потянет GitLab. Приведенный ниже файл Compose взят из документации Forgejo и использует тег образа, актуальный на октябрь 2026 года.

networks:
  forgejo:
    external: false

services:
  server:
    image: codeberg.org/forgejo/forgejo:16
    container_name: forgejo
    environment:
      - USER_UID=1000
      - USER_GID=1000
    restart: always
    networks:
      - forgejo
    volumes:
      - ./forgejo:/data
      - /etc/localtime:/etc/localtime:ro
    ports:
      - '3000:3000'
      - '222:22'

docker compose up -d
docker compose ps
curl -sI http://127.0.0.1:3000 | head -1

Команда curl должна вывести строку состояния HTTP. До завершения первоначальной настройки это может быть редирект на /install, что также подтверждает работоспособность сервиса. Если контейнер завершает работу, наиболее вероятная причина — права доступа: каталог ./forgejo должен принадлежать UID (идентификатору пользователя), указанному в USER_UID, иначе процесс не сможет записывать данные в свой рабочий каталог. В Docker Compose на VPS подробно описана структура файлов и правила владения томами.

Два параметра на странице настройки определяют работоспособность URL для клонирования. Порт SSH должен быть 222, так как файл Compose пробрасывает порт 222 хоста на порт 22 контейнера, а домен должен соответствовать тому имени, которое будут вводить пользователи. Ошибка в любом из этих параметров приведет к тому, что на каждой странице репозитория будет отображаться нерабочая команда для клонирования. В дальнейшем оба параметра находятся в секции [server] файла app.ini как SSH_PORT, SSH_DOMAIN и ROOT_URL.

Для публичного экземпляра публикуйте веб-порт только на адресе loopback ('127.0.0.1:3000:3000') и используйте nginx в качестве фронтенда для TLS (transport layer security). Gitea устанавливается аналогичным образом из образа docker.gitea.com/gitea, указанного в документации, либо как отдельный бинарный файл с одним юнитом systemd и одним файлом app.ini. Текущий стабильный релиз — v28.1.0, выпущенный 6 октября 2026 года. Начиная с версии v28.0.0 в конце сентября, проект отказался от старого префикса 1., поэтому следующим после 1.27 стал релиз 28, а не 1.28.

Используйте SQLite, пока это возможно. Это позволяет ограничиться одним процессом и одним файлом, которые корректно восстанавливаются после перезагрузки без необходимости контролировать дополнительные сервисы. PostgreSQL оправдывает затраты ресурсов, когда несколько пользователей пишут данные одновременно, так как SQLite сериализует операции записи, а длительные процессы CI выполняют запись постоянно. Оба проекта позволяют перенести существующий экземпляр на PostgreSQL позже, поэтому это решение не является окончательным.

Forgejo или Gitea: в чем реальные различия

У них общая история. Gitea отделилась от Gogs в 2016 году. В конце 2022 года контроль над доменом и торговой маркой Gitea перешел к компании Gitea Ltd, после чего часть сопровождающих проекта совместно с Codeberg запустили Forgejo. Проект Forgejo публикуется некоммерческой ассоциацией Codeberg e.V., зарегистрированной в Германии, и в 2024 году перешел с лицензии MIT на GPLv3 (GNU general public license version 3). Gitea сохраняет лицензию MIT и развивается при коммерческой поддержке.

В повседневной работе наборы функций близки. Однако путь миграции между ними — нет. Версия Forgejo v10.0, вышедшая в январе 2025 года, была последним релизом, способным напрямую работать с базой данных Gitea, причем только начиная с версии Gitea v1.22 или более ранних. По состоянию на октябрь 2026 года Gitea находится на версии v28.1.0, поэтому для актуального экземпляра Gitea не существует поддерживаемого способа перехода на Forgejo «на месте». Выберите решение до того, как наполните его данными, а любой последующий перенос рассматривайте как экспорт и повторный импорт.

Краткое правило для выбора. Если для вас важно управление проектом или вы хотите, чтобы он оставался некоммерческим, используйте Forgejo. Если вам нужна более широкая база установок и возможность получения коммерческой поддержки, используйте Gitea. Оба проекта развиваются открыто и часто выпускают обновления: Forgejo выпускает стабильный релиз каждые три месяца и один LTS-релиз (long term support) в год; по состоянию на октябрь 2026 года актуальными являются v16.0.5 и LTS-версия v15.0.9. Forgejo поддерживает v16 до 29 октября 2026 года, а v15 — до 15 июля 2027 года, поэтому проверяйте страницу релизов перед фиксацией мажорной версии.

Уровень 3: затраты на GitLab до начала работы

GitLab CE относится к другому классу программного обеспечения. Один экземпляр представляет собой набор взаимодействующих сервисов: Puma для веб-приложения, Sidekiq для фоновых задач, PostgreSQL, Redis, Gitaly для доступа к репозиториям и nginx в качестве фронтенда. Пакет Omnibus устанавливает их вместе, что упрощает установку, но повышает минимальные требования к оперативной памяти.

На странице системных требований GitLab указано, что базовой конфигурацией для установки на одном узле являются 16 GB RAM и 8 vCPU, при этом 8 GB обозначены как нижний предел для сред с ограниченными ресурсами. Та же страница рекомендует отключить swap, так как использование подкачки под нагрузкой значительно снижает производительность экземпляра. Это официальные данные по состоянию на октябрь 2026 года; с годами они росли, поэтому перед выбором сервера ознакомьтесь с актуальной информацией на странице.

За эти ресурсы вы получаете полноценные инструменты: реестр контейнеров, реестр пакетов, гибкую систему прав доступа, функции комплаенса и аудита, а также CI, протестированный в крупных масштабах. Если никто в вашей команде не может назвать функцию из этого списка, которая необходима в текущем квартале, вы просто оплачиваете более дорогой VPS, не получая взамен никакой пользы.

Модель доступа по SSH: один пользователь git и множество ключей

На каждом уровне аутентификация происходит одинаково. Существует одна учетная запись Unix с именем git, и все открытые ключи помещаются в файл ~/.ssh/authorized_keys этой учетной записи. Аутентификация выполняется по ключу. Авторизация определяется параметрами, которые вы указываете перед ключом в той же строке.

Обычная строка с ключом предоставляет владельцу все права, доступные этой учетной записи. Принудительная команда (forced command) ограничивает их только Git:

restrict,command="git-shell -c \"$SSH_ORIGINAL_COMMAND\"" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIexamplekeyhere alice@laptop

Параметр restrict, доступный начиная с OpenSSH 7.2, одним словом отключает перенаправление портов, перенаправление агента, X11 и выделение PTY (псевдотерминала). Параметр command= заменяет любой запрос клиента на указанную вами команду, при этом Git продолжает работать, так как он отправляет свой запрос в $SSH_ORIGINAL_COMMAND.

Система управления репозиториями (forge) записывает этот файл за вас, и в этом заключается основное различие между уровнем 0 и уровнем 2. Когда Forgejo и Gitea работают через системный сервер OpenSSH, что является их стандартной конфигурацией, они перезаписывают authorized_keys, добавляя по одной строке на каждый зарегистрированный ключ. Каждая строка содержит принудительную команду, которая идентифицирует ключ по его ID в базе данных:

command="/usr/local/bin/forgejo --config=/etc/forgejo/app.ini serv key-3",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,no-user-rc,restrict ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIexamplekeyhere alice

Эта принудительная команда позволяет превратить одну общую учетную запись Unix в систему с индивидуальными правами доступа: key-3 сообщает системе, какой пользователь подключается, и она проверяет права этого пользователя в отношении репозитория до начала передачи каких-либо объектов. Не редактируйте этот файл вручную на сервере, управляемом через forge, так как он перезаписывается из базы данных, и ваша строка будет удалена. Если вы активируете встроенный SSH-сервер forge или настроите OpenSSH на получение ключей из forge через AuthorizedKeysCommand, этот файл вообще не потребуется; в последнем случае оба проекта рекомендуют отключить его создание. Ключи развертывания (deploy keys) работают по тому же механизму: ключ развертывания — это обычный SSH-ключ, зарегистрированный для конкретного репозитория (обычно только для чтения), при этом проверка выполняется внутри forge, а не в sshd.

Две привычки важнее любой из вышеперечисленных настроек. Выдавайте по одному ключу на человека или на машину, никогда не используйте общие ключи, так как отзыв общего ключа потребует его замены для всех пользователей одновременно. Удаляйте ключи в день увольнения сотрудника, так как старый ключ в этом файле — это постоянный доступ, за которым никто не следит. Грамотное управление SSH-ключами на сервере содержит информацию о типах ключей и парольных фразах, и все эти рекомендации применимы здесь без изменений. Если сервер новый, первые десять минут на новом VPS — это то, что нужно сделать перед размещением на нем репозиториев.

Можно ли запускать GitHub Actions на собственном Git-сервере?

Вы можете запускать рабочие процессы (workflows), написанные с использованием синтаксиса GitHub Actions. Запустить сам GitHub нельзя. В Forgejo поддержка Forgejo Actions включена по умолчанию начиная с версии v1.21; система считывает файлы рабочих процессов из .forgejo/workflows в каждом репозитории. Gitea Actions работает аналогичным образом и считывает .gitea/workflows. Для обоих решений требуется вторая программа — runner (исполнитель), которую необходимо установить и зарегистрировать в вашем экземпляре с помощью токена из настроек администратора. Многие опубликованные действия (actions) работают без изменений; однако всё, что обращается к API GitHub или ожидает инфраструктуру, предоставляемую GitHub, работать не будет.

Учитывайте два последствия. При использовании стандартных меток контейнеров runner запускает отдельный контейнер для каждой задачи, поэтому ему требуется собственный движок контейнеров и выделенный объем оперативной памяти. Именно поэтому его не следует размещать на том же сервере с 1 ГБ ОЗУ, где работает сам forge. Оба типа runner могут выполнять задачи непосредственно на хосте (через метку, заканчивающуюся на :host в Forgejo); это не требует движка, но и не создает изоляции между задачей и машиной. Runner выполняет всё, что указано в файле рабочего процесса, о чем в документации Forgejo сказано прямо: runner осуществляет удаленное выполнение кода (RCE). По возможности выделите под него отдельный хост или, как минимум, используйте непривилегированного пользователя и токен регистрации, ограниченный одним репозиторием.

Если ваши репозитории остаются на GitHub, а вы хотите использовать для вычислений только собственное оборудование, это другая конфигурация с иными шагами: self-hosted runner для GitHub Actions подключается к репозиторию GitHub и не требует ничего из вышеперечисленного. Если вы всё еще оцениваете стоимость перехода, статья что на самом деле дает GitHub поможет отделить хостинг Git от сетевой инфраструктуры вокруг него.

Резервные копии: репозитории — это лишь половина состояния

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

git clone --mirror git@vps.example.com:/srv/git/project.git
cd project.git && git remote update

Эта команда извлекает все ссылки и объекты. Она не копирует серверные хуки или файл description, поэтому, если вы используете хуки, дополнительно сохраняйте каталог на уровне файловой системы.

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

sudo -u git forgejo dump -c /etc/forgejo/app.ini -f /var/backups/forgejo-dump.zip

При использовании Docker та же команда выполняется внутри контейнера, а путь к конфигурации зависит от образа, поэтому уточните его перед вводом:

docker compose exec server ls /data/gitea/conf
docker compose exec -u git server forgejo dump -c /data/gitea/conf/app.ini

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

Выбор по сценарию

Один пользователь с ноутбуком и VPS, просмотр через браузер не требуется: используйте bare-репозитории по SSH. Дополнительные службы не запускаются, обновлять нечего.

То же самое, но вы хотите просматривать код в браузере и отправлять на него ссылки: добавьте cgit. База данных по-прежнему не нужна, резидентные процессы отсутствуют.

Команда, которая проводит взаимное ревью кода и отслеживает задачи: Forgejo или Gitea, требуется 2 GB оперативной памяти или больше. Перенесите CI runner на отдельный сервер, как только нагрузка от задач станет ощутимой.

Организация, которой нужен реестр контейнеров и журналы аудита, при наличии 16 GB оперативной памяти на сервере: GitLab. При меньшем объеме памяти развертывание не рекомендуется.

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

FAQ

Может ли VPS с 1 GB RAM запустить Forgejo или Gitea?

Да, для небольшой команды при использовании SQLite и отсутствии других ресурсоемких приложений на сервере. Документация Gitea указывает 1 GB оперативной памяти и 2 ядра CPU как достаточные параметры для небольших команд и проектов; Forgejo — это форк Gitea с аналогичными требованиями. Не устанавливайте на этот же сервер PostgreSQL или CI runner. Если сервис исчезает без записей об ошибках в собственном логе, выполните sudo dmesg -T | grep -Ei 'oom|out of memory|killed process': строка с названием процесса означает, что его завершил OOM killer (Out of Memory killer). В этом случае решением будет переход на более мощный тариф, а не настройка флагов.

В чем разница между Forgejo и Gitea?

У них общая история кодовой базы и большинство функций. Gitea отделилась от Gogs в 2016 году, а Forgejo отделилась от Gitea в конце 2022 года, после того как контроль над торговой маркой Gitea перешел к коммерческой компании. Forgejo публикуется некоммерческой организацией Codeberg e.V. из Германии под лицензией GPLv3; Gitea сохраняет лицензию MIT и коммерческую поддержку. Практическое различие заключается в процессе миграции. Forgejo v10.0, выпущенная в январе 2025 года, стала последним релизом, поддерживающим прямое использование базы данных Gitea (только для версий Gitea v1.22 и старше), поэтому для актуальных инстансов Gitea прямого пути перехода не существует.

Можно ли запускать GitHub Actions на собственном Git-сервере?

Forgejo Actions и Gitea Actions выполняют рабочие процессы, написанные на синтаксисе YAML для GitHub Actions, которые считываются из .forgejo/workflows и .gitea/workflows. Необходимо установить отдельную программу-раннер и зарегистрировать её в вашем инстансе. Многие опубликованные экшены работают без изменений, однако те, что обращаются к API GitHub, работать не будут. Раннер выполняет произвольный код из ваших репозиториев и, при использовании стандартных меток контейнеров, запускает отдельный контейнер для каждого задания. Поэтому выделите для него отдельный хост или хотя бы отдельного непривилегированного пользователя и не запускайте его на сервере с 1 GB RAM, где уже работает сам Git-сервер.

Как создать резервную копию собственного Git-сервера?

Для «голых» (bare) репозиториев команда git clone --mirror с другого сервера копирует все ссылки и объекты, а git remote update внутри этого зеркала обновляет их. Для Forgejo или Gitea репозитории — это лишь часть состояния, так как тикеты, pull requests, пользователи и ключи хранятся в базе данных. Используйте встроенную утилиту для создания дампа sudo -u git forgejo dump -c /etc/forgejo/app.ini (или аналогичную команду внутри контейнера, если используется Docker). Скопируйте архив с сервера и хотя бы один раз выполните восстановление на запасной машине, чтобы убедиться в работоспособности процедуры.