Пошаговая инструкция · Самостоятельная установка
Как установить Gitea на сервер
Пошаговая инструкция для самостоятельной установки. Развернём собственный Git-сервер: с закрытыми репозиториями, задачами и pull request. Настроим HTTPS для браузера и отдельный SSH-порт для Git, затем проверим сохранность данных.
Что подготовить и как читать инструкцию #
Эта инструкция рассчитана на один сервер для небольшой команды. Gitea хранит код и настройки, PostgreSQL — пользователей, задачи и связи между ними, Nginx принимает подключения по HTTPS. Рабочие данные вынесены из контейнеров. Исполнитель CI сюда не входит: задания сборки требуют отдельного runner и собственных ресурсов.
Для начала достаточно ориентироваться на 2 vCPU, 4 ГБ RAM и SSD от 40 ГБ; крупные репозитории, LFS и пакеты быстро увеличивают расход места. Оцените свой объём по статье как выбрать сервер для Gitea. Возможности продукта описаны на странице Gitea.
Команды выполняйте в терминале сервера после подключения по SSH, если шаг не указывает другое место. sudo даёт команде права администратора. Действия в браузере выполняйте на своём компьютере. Домены, IP-адреса и значения ВАШ_ПАРОЛЬ из примеров заменяйте своими до выполнения команды.
Двигайтесь по одному шагу и проверяйте результат перед следующим. Блок с <<EOF или другим именем завершения копируйте целиком: он записывает содержимое одного файла. При работе в nano сохраняйте файл клавишами Ctrl+O, Enter и выходите Ctrl+X. Если прервали SSH-сеанс, снова перейдите в указанный каталог; переменные предыдущего сеанса потребуется задать заново.
Установите Nginx и Certbot по подготовке Ubuntu. До завершения первоначальной настройки разрешите TCP 443 только со своего IP в firewall провайдера; TCP 80 оставьте открытым для сертификата. Официальный пример обратного прокси Gitea объясняет сохранение путей.
Дополнительные официальные источники: Почта Gitea, Резервное копирование и восстановление Gitea, Обновление Gitea, Docker на Ubuntu, Релиз PostgreSQL 18.6.
Шаг 1. Создайте каталоги установки от root #
Первая строка открывает административную оболочку: дождитесь приглашения root перед следующими командами. Затем создадим /opt/gitea и постоянный data. UID 1000 — пользователь Gitea внутри выбранного контейнера; ему нужен доступ к репозиториям и вложениям. Позже Git-команды будут отдельно выполняться на вашем компьютере.
sudo -i
install -d -m 0750 /opt/gitea
cd /opt/gitea
install -d -o 1000 -g 1000 -m 0750 dataВы в /opt/gitea от root; data принадлежит указанному UID.
Шаг 2. Создайте пароль PostgreSQL #
Пароль базы попадёт в закрытый .env. Он не является паролем первого пользователя Gitea.
umask 077
printf 'GITEA_DB_PASSWORD=%s\n' "$(openssl rand -hex 32)" > .env
chmod 600 .envGITEA_DB_PASSWORD заполнен, права .env — 600.
Шаг 3. Сохраните Compose #
Откройте nano compose.yaml и сохраните файл ниже. Приложение слушает только 127.0.0.1:3000; его HTTPS обслуживает Nginx на хосте. Git SSH остаётся на порту 2222, отдельно от SSH управления сервером.
name: gitea
services:
db:
image: postgres:18.6
restart: unless-stopped
environment:
POSTGRES_DB: gitea
POSTGRES_USER: gitea
POSTGRES_PASSWORD: ${GITEA_DB_PASSWORD:?set database password}
volumes:
- ./postgres:/var/lib/postgresql
healthcheck:
test: ["CMD-SHELL", "pg_isready -U gitea -d gitea"]
interval: 10s
timeout: 5s
retries: 10
server:
image: docker.gitea.com/gitea:28.0.0
restart: unless-stopped
environment:
USER_UID: "1000"
USER_GID: "1000"
GITEA__database__DB_TYPE: postgres
GITEA__database__HOST: db:5432
GITEA__database__NAME: gitea
GITEA__database__USER: gitea
GITEA__database__PASSWD: ${GITEA_DB_PASSWORD:?set database password}
GITEA__server__DOMAIN: git.example.com
GITEA__server__ROOT_URL: https://git.example.com/
GITEA__server__SSH_DOMAIN: git.example.com
GITEA__server__SSH_PORT: "2222"
GITEA__service__DISABLE_REGISTRATION: "true"
ports:
- "127.0.0.1:3000:3000"
- "2222:22"
volumes:
- ./data:/data
depends_on:
db:
condition: service_healthyФайл сохранён; внешний HTTP-порт контейнера не опубликован на всех интерфейсах.
Шаг 4. Проверьте описание установки #
Проверим YAML и обязательный пароль PostgreSQL перед загрузкой образов.
cd /opt/gitea
docker compose config --quietconfig --quiet завершился без ошибки.
Шаг 5. Загрузите образы #
Скачиваем выбранные версии Gitea, PostgreSQL и прокси; данные ещё не создаются пользователями.
docker compose pullpull завершился успешно.
Шаг 6. Запустите сервисы #
up -d создаёт контейнеры и запускает первоначальную подготовку базы.
docker compose up -dКонтейнеры созданы.
Шаг 7. Проверьте сайт и HTTPS #
Проверим запущенную Gitea через локальный порт сервера. Пока Nginx не настроен, публичного HTTPS ещё нет.
docker compose ps
docker compose logs --tail=100 server
curl -I http://127.0.0.1:3000/Контейнеры db и server работают, локальный HTTP отвечает. При ошибке исправьте приложение до настройки домена.
Шаг 8. Сохраните сайт Nginx #
Установите Nginx и Certbot по подготовке Ubuntu, если ещё не установили. Откройте sudo nano /etc/nginx/sites-available/gitea и вставьте файл ниже. Замените все домены своими. Nginx передаёт приложению домен, адрес клиента и протокол; Upgrade и Connection сохраняют WebSocket. До получения сертификата условие $scheme блокирует обычные HTTP-запросы кодом 403, чтобы вход не происходил без шифрования. URI передаётся без переписывания; это важно для репозиториев, LFS и пакетов.
/etc/nginx/sites-available/giteamap $http_upgrade $gitea_connection_upgrade {
default upgrade;
"" close;
}
server {
listen 80;
server_name git.example.com;
client_max_body_size 512m;
location / {
if ($scheme = http) { return 403; }
proxy_pass http://127.0.0.1:3000;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $gitea_connection_upgrade;
proxy_read_timeout 3600s;
proxy_send_timeout 3600s;
proxy_buffering off;
proxy_request_buffering off;
}
}
Сохраните Ctrl+O, Enter, Ctrl+X. В файле пока нет путей к сертификатам: Nginx сможет проверить его до выпуска HTTPS.
Шаг 9. Подключите сайт и проверьте HTTP #
Ссылка подключает сохранённый сайт. nginx -t проверяет все настройки сервера; && разрешает перечитать их только при успешной проверке. curl проверяет ответ для вашего домена. При ошибке остановитесь, исправьте указанную строку и повторите проверку.
sudo ln -sfn /etc/nginx/sites-available/gitea /etc/nginx/sites-enabled/gitea
sudo nginx -t && sudo systemctl reload nginx
curl -I http://git.example.com/Ожидается successful от nginx -t и HTTP 403 для обычного запроса: до HTTPS это намеренная блокировка. DNS должен указывать на сервер, TCP 80/443 — быть доступен у провайдера. Ничего не вводите в форму входа по HTTP.
Шаг 10. Получите сертификат и включите HTTPS #
Каждое имя из команды должно указывать на этот сервер. Certbot проверит домены, сам добавит сертификат в сайт Nginx и включит перенаправление HTTP → HTTPS. Укажите свою почту при запросе и подтвердите условия Let’s Encrypt. Это отдельное действие после успешной проверки HTTP.
sudo /snap/bin/certbot --nginx -d git.example.com --redirectCertbot сообщил об успешной установке. Откройте HTTPS-адрес со своего компьютера: браузер не должен предупреждать о сертификате. Для закрытой панели используйте разрешённый IP. При ошибке исправьте DNS, в том числе AAAA, либо доступ к TCP 80; не повторяйте запросы выпуска подряд.
Шаг 11. Проверьте продление сертификата #
Certbot из snap создаёт службу автоматического продления. Dry-run выполняет пробное продление: настоящие сертификаты не заменяются. Затем проверьте, что таймер планирует следующий запуск. Сохраняйте доступ к TCP 80 для следующих проверок домена.
sudo /snap/bin/certbot renew --dry-run
systemctl list-timers --all 'snap.certbot.renew*'Пробное продление успешно, у таймера есть следующий запуск. Если тест не прошёл, проверьте /var/log/letsencrypt/letsencrypt.log; сначала исправьте причину. После этого можно создавать учётную запись и приглашать пользователей.
Шаг 12. Создайте администратора #
Откройте свой HTTPS-домен и завершите первый вход по выбранной конфигурации. Создайте административную запись, затем ограничьте свободную регистрацию, если она не нужна. Для ежедневного Git-доступа используйте обычного пользователя.
Вход работает, посторонняя регистрация соответствует установленному правилу.
Шаг 13. Создайте тестовый репозиторий #
В интерфейсе создайте организацию my-team или замените её имя в дальнейших примерах своим. Создайте пустой приватный репозиторий installation-check без README: ниже отправим первый файл с компьютера.
Пустой репозиторий существует и доступен вашему обычному пользователю.
Шаг 14. Добавьте публичный ключ компьютера #
На рабочем компьютере подготовьте SSH-ключ, если его ещё нет. Добавьте только публичную часть в настройки своей учётной записи Gitea → SSH keys. Закрытый ключ остаётся на компьютере.
Ключ сохранён в профиле обычного пользователя.
Шаг 15. Проверьте Git SSH с компьютера #
Эту команду выполняйте на своём компьютере. При первом соединении сверяйте отпечаток сервера. Успех подтверждается приветствием Gitea; интерактивной оболочки у пользователя git не будет.
ssh -T -p 2222 git@git.example.comОтвет приветствует вашу учётную запись.
Шаг 16. Скачайте пустой репозиторий #
Также на компьютере клонируйте репозиторий. Замените my-team на владельца вашего репозитория. Предупреждение о пустом репозитории здесь нормально.
git clone ssh://git@git.example.com:2222/my-team/installation-check.git
cd installation-checkВы в каталоге installation-check на компьютере.
Шаг 17. Создайте первый коммит #
Запишем README и отправим его в локальный коммит. Если Git просит имя/email, в этом репозитории задайте git config user.name "Ваше имя" и git config user.email "ваша-почта"; затем повторите commit.
printf 'Gitea installation check\n' > README.md
git add README.md
git commit -m "Verify Git server"Локальный коммит создан.
Шаг 18. Отправьте коммит на сервер #
Push передаёт локальный коммит в Gitea. Затем откройте репозиторий в браузере, чтобы проверить реальное сохранение.
git push origin HEADВ Gitea видны README и новый коммит.
Шаг 19. Подготовьте согласованную копию #
Вернитесь в root-терминал сервера. Создадим закрытый каталог и остановим Gitea, оставив базу работать. Trap возвращает сервер при завершении оболочки, в том числе после ошибки.
cd /opt/gitea
set -e
BACKUP_DIR="/var/backups/gitea/$(date -u +%Y%m%dT%H%M%SZ)"
install -d -m 0700 "$BACKUP_DIR"
docker compose stop server
trap 'docker compose start server' EXITServer остановлен; BACKUP_DIR задан для следующих команд.
Шаг 20. Скопируйте базу, репозитории и ключи #
Дамп сохраняет базу, files.tar.gz — репозитории и ключи, nginx-tls.tar.gz — сайт и HTTPS. Сертификаты содержат закрытые ключи. Храните все части вместе в закрытом внешнем хранилище.
docker compose exec -T db pg_dump -U gitea -d gitea -Fc > "$BACKUP_DIR/database.dump"
tar -czf "$BACKUP_DIR/files.tar.gz" compose.yaml .env data
sudo tar -czf "$BACKUP_DIR/nginx-tls.tar.gz" /etc/nginx/sites-available/gitea /etc/letsencrypt
chmod 600 "$BACKUP_DIR"/*Дамп и архив созданы и защищены правами 600.
Шаг 21. Верните Gitea в работу #
Запустите server и снимите временный trap. Проверьте чтение README и Git pull с компьютера.
docker compose start server
trap - EXITСайт и Git SSH снова работают.
Шаг 22. Проверьте базу на отдельной машине #
Этот шаг только для нового тестового сервера той же версии. Верните файлы архива в /opt/gitea, запустите базу, дождитесь готовности и замените /path/to/database.dump настоящим путём дампа. Не выполняйте импорт поверх рабочей базы.
cd /opt/gitea
docker compose up -d db
docker compose exec -T db pg_isready -U gitea -d gitea
# Продолжайте после состояния accepting connections.
docker compose exec -T db pg_restore -U gitea -d gitea --exit-on-error < /path/to/database.dumppg_restore завершился без ошибки.
Шаг 23. Проверьте восстановленные репозитории #
На тестовом сервере запустите комплект и выполните штатную проверку Gitea doctor. Откройте README и проверьте клонирование тестовым клиентом.
docker compose up -d
docker compose exec -u git server gitea doctor checkПроверка успешна; репозиторий, права и коммит восстановлены.
Если результат шага отличается #
Вернитесь к проверке того шага, на котором появилась ошибка. Первая ошибка в выводе обычно полезнее последних строк: последующие команды могли не получить нужный файл или работающую службу. Не повторяйте установку целиком поверх частично настроенного приложения.
Если страница не открывается, сначала проверьте домен и входящие порты, затем состояние приложения и его журнал. Если сайт открывается, но отдельное действие не работает, проверьте связанные компоненты — обработчик фоновых задач, почту или права пользователя. Официальные источники в конце статьи относятся к выбранному способу установки.
При восстановлении верните файл Nginx и сертификаты, подключите сайт в sites-enabled, затем проверьте sudo nginx -t и перечитайте службу. На тестовом сервере с другим доменом получите отдельный сертификат; не открывайте рабочие данные и уведомления посторонним.