Прямой ответ
Gitea — легковесный self-hosted git-хостинг (репозитории, PR, issues, Actions) в одном бинарнике или контейнере. На ноутбуке он поднимается одной командой и потребляет 150–300 МБ RAM и доли процента CPU в покое — дешевле одного контейнера Elasticsearch. Сценарии: приватные pet-проекты и эксперименты без облака, локальный «origin» для чувствительного кода, учебный стенд для команды, офлайн-зеркало рабочих репозиториев. Установка через Docker:
docker run -d --name gitea -p 3000:3000 -p 2222:22 \
-v gitea-data:/data --memory 512m \
-e USER_UID=1000 -e USER_GID=1000 gitea/gitea:latest
Веб-интерфейс — ` мастер установки при первом входе.
Зачем свой сервер, если есть GitHub?
Три честные причины и одна нечестная. Честные: приватность — код не покидает вашу машину (важно для NDA-экспериментов и данных); независимость — репозитории живут у вас при любом состоянии интернета и лимитов облака; учебный стенд — CI/CD, хуки, веточные политики можно ломать и чинить без риска для рабочих проектов. Нечестная причина — «полная замена GitHub»: экосистема (Actions-маркетплейс, код-ревью-инструменты, интеграции, social-слой) у облака богаче; Gitea закрывает базу, но не всё.
Практичная схема для разработчика: Gitea локально как первичный origin + push-зеркало в приватный GitHub/GitLab репозиторий (в Gitea это встроенная функция mirror). Так приватность по умолчанию сочетается с облачным бэкапом.
Установка и первая настройка
Docker-вариант выше — рабочий минимум; данные в именованном volume gitea-data (внутри — репозитории, база, конфиг). Для постоянного использования добавьте compose-файл с СУБД вместо встроенной SQLite (Postgres из статьи про локальный PostgreSQL) — на десятках репозиториев разница заметна.
Ключевые решения мастера установки:
- Админ-аккаунт создайте сразу — иначе первого зарегистрировавшегося сделает админом.
- Требуется вход для просмотра (DISABLE_REGISTRATION + REQUIRE_SIGNIN) — для личного сервера обязательно, особенно при пробросе наружу.
- SSH-порт 2222 — чтобы не конфликтовать с sshd хоста; клонирование тогда
ssh://git@localhost:2222/user/repo.git. - LFS включите, если планируете бинарники; хранилище LFS тоже живёт в /data.
Подключение репозитория:
git remote add home ssh://git@localhost:2222/me/project.git
git push home main
Ресурсы и обслуживание
Потребление Gitea скромнее большинства dev-сервисов: 150–300 МБ RAM, диск — сумма ваших репозиториев + ~10% на служебное. Встроенные задачи (обновление статистики, чистка) работают по cron внутри контейнера и не заметны. Обслуживание сводится к обновлению образа (docker pull && recreate) раз в месяц и контролю размера gitea-data. В бюджете локального стека Gitea — «бесплатный» сосед: сравнение лимитов и профилей — в статье про Compose-стек.
Бэкап — штатной командой:
docker exec -u git gitea gitea dump -c /data/gitea/conf/app.ini -f /data/backup.zip
Дамп включает репозитории, базу и конфиг; восстанавливается на чистой установке. Храните копию вне ноутбука — правила обращения с секретами и ключами внутри бэкапа описаны в статье про .env и секреты.
Безопасность: локальный не значит защищённый
- Не публикуйте порт 3000/2222 в интернет без VPN: Gitea — полноценная цель для атак; домашний роутер с проброшенным портом — частый источник компрометаций.
- Доступ из домашней сети — нормально; извне — только через WireGuard/Tailscale-подобный VPN или reverse proxy с TLS.
- SSH-ключи для git-операций вместо паролей; пароль админа — из менеджера паролей.
- Обновления ставьте своевременно: git-хостинг — привлекательная цель, CVE появляются регулярно.
- Если используете Gitea Actions (совместимый с GitHub Actions раннер), учтите: раннер исполняет код из репозиториев — держите его в контейнере и не давайте ему доступов к хосту; настройка раннера разбирается в статье про self-hosted CI.
FAQ
Gitea или «голый» git-сервер по SSH?
Голый сервер (git daemon/sshd + bare-репозитории) проще и легче, но без веб-интерфейса, PR и issues. Gitea стоит своих 200 МБ, если нужна хоть какая-то совместная работа или история обсуждений.
Gitea или GitLab CE? GitLab CE — полноценный DevOps-комбайн, но на ноутбуке он требует 4+ ГБ RAM. Gitea покрывает git+PR+issues+базовый CI при потреблении в 15 раз меньше.
Можно ли переехать с Gitea обратно на GitHub?
Да: репозитории — обычный git (git push --all + --tags в новый remote), issues/PR переносятся только вручную или скриптами API. Поэтому зеркалирование в облако держите включённым.
Потянет ли Gitea Raspberry Pi вместо ноутбука? Да, это типовое размещение (1–2 ГБ RAM достаточно). Ноутбук удобнее для разработки рядом; Pi — для постоянно включённого домашнего сервера.
Зеркалирование и перенос репозиториев
Штатный механизм Gitea — Migration: в веб-интерфейсе «New Migration» принимает URL репозитория с GitHub/GitLab (с токеном при приватности) и переносит ветки, теги, issues и wiki одной операцией. Обратное направление — зеркалирование наружу: в настройках репозитория включается push-mirror с расписанием, и каждый ваш коммит уезжает в облачную копию. Эта пара механизмов закрывает главный риск self-hosted решения — потерю единственного хранилища: локальный ноутбук может сломаться, а зеркало в облаке останется.
Для полного переноса без веб-интерфейса работает чистый git: git clone --mirror <старый> && cd <repo>.git && git push --mirror <gitea> — переносятся все refs. Проверяйте результат сравнением git ls-remote на обоих remote: расхождение по тегам — типичная мелочь, которую забывают. Если в репозитории использовался LFS, переносите и LFS-объекты (git lfs fetch --all + git lfs push --all) — без них история cloning у коллег встанет на первом же checkout бинарника.
Как обновить Gitea без потери данных?
Все данные в volume gitea-data: обновление — docker pull gitea/gitea:latest, затем docker rm -f gitea && docker run ... с теми же параметрами. Мажорные версии читайте release notes (иногда нужна миграция БД — она выполняется автоматически при старте, но дамп перед обновлением обязателен).
Хватит ли Gitea для команды из 5–10 человек? Да, это её типичный масштаб: PR-ревью, веточная защита, issues, wiki и Actions покрывают повседневный цикл. Ограничения начинаются на десятках активных разработчиков и сотнях репозиториев — тогда смотрят в сторону GitLab, но для домашней и малой командной разработки Gitea закрывает задачи при потреблении в сотни мегабайт.
Источники: документация Gitea (Docker-установка, backup), Pro Git (ссылки в шапке).