Gitea на своём сервере

Gitea — лёгкий Git-сервер для команд, которым не нужна вся тяжесть GitLab

Gitea — это open source платформа для хранения Git-репозиториев с веб-интерфейсом, issues, pull request и базовым CI (через встроенный Actions или интеграцию с внешними системами), написанная на Go и рассчитанная на минимальное потребление ресурсов. Там, где GitLab требует несколько гигабайт памяти даже для небольшой команды, Gitea комфортно работает на VPS с 1 ГБ памяти, сохраняя привычный веб-интерфейс, знакомый пользователям GitHub и GitLab.

Для команд, которым не нужны встроенные CI/CD пайплайны, реестр контейнеров и десятки других функций корпоративной DevOps-платформы, а важны только надёжное хранение кода, code review через pull request и трекер задач, Gitea даёт всё необходимое без избыточной сложности администрирования и без требований к дорогому серверу.

Установка и администрирование: минимум движущихся частей

Gitea распространяется единственным бинарным файлом или Docker-образом, а в качестве базы данных может использовать как полноценный PostgreSQL или MySQL, так и встроенный SQLite для небольших команд — это сокращает число компонентов, которые нужно устанавливать, настраивать и поддерживать в актуальном состоянии, по сравнению с более тяжёлыми платформами, состоящими из полудюжины взаимосвязанных сервисов.

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

Issues, pull request и code review: всё необходимое для командной разработки

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

Встроенный wiki для каждого репозитория позволяет хранить техническую документацию проекта рядом с самим кодом, а поддержка webhooks даёт возможность интегрировать Gitea с внешними системами уведомлений, CI/CD или чат-ботами команды, реагирующими на события в репозитории — push, создание pull request, закрытие issue.

Встроенный CI/CD через Gitea Actions

Начиная с относительно недавних версий Gitea включает собственную систему CI/CD — Gitea Actions, совместимую по синтаксису конфигурации с GitHub Actions, что заметно упрощает миграцию существующих пайплайнов и снижает порог входа для разработчиков, уже знакомых с экосистемой GitHub. Это закрывает одно из главных прежних отличий Gitea от GitLab — отсутствие встроенной автоматизации сборки и тестирования.

Для более сложных или ресурсоёмких пайплайнов сборки Gitea также хорошо интегрируется с внешними CI-системами через стандартные webhooks и статусы коммитов, что даёт гибкость выбора инструмента автоматизации без привязки исключительно к встроенному решению, если у команды уже есть предпочтения или существующая инфраструктура CI.

Миграция с GitHub или GitLab на Gitea

Gitea предоставляет встроенные инструменты для миграции репозиториев вместе с историей issues, pull request, меток и вех напрямую из GitHub, GitLab, Bitbucket и других популярных платформ, что позволяет перенести не только код, но и накопленный контекст обсуждений проекта, не начиная историю трекера задач с нуля на новой платформе.

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

Сколько ресурсов нужно для Gitea

Для команды до 10-15 разработчиков с умеренной активностью более чем достаточно VPS с 1 ГБ памяти — это один из самых экономичных по требованиям к ресурсам сервисов в нашем каталоге, что делает Gitea привлекательным выбором для стартапов и небольших команд, которым важно минимизировать расходы на инфраструктуру без потери базовой функциональности Git-платформы.

При росте команды и активном использовании встроенного CI через Gitea Actions стоит закладывать дополнительные ресурсы именно под выполнение сборочных заданий — сами раннеры Actions потребляют ресурсы отдельно от веб-интерфейса Gitea, и при интенсивной сборке разумно выносить их на отдельный сервер по тому же принципу, что и раннеры GitLab.

Безопасность и резервное копирование Git-сервера

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

Резервное копирование Gitea сводится к сохранению базы данных и директории с репозиториями и загруженными файлами — встроенная команда dump создаёт единый архив со всеми необходимыми данными для полного восстановления сервера, что делает процесс резервного копирования и последующего восстановления предсказуемым и хорошо документированным.

Развёртываем Gitea на VPS: с чего начать

Установка Gitea через Docker Compose с отдельным контейнером PostgreSQL занимает считаные минуты благодаря готовым официальным образам и подробной документации проекта — это один из самых быстрых для развёртывания сервисов в нашем каталоге, что делает его удобной отправной точкой для команд, впервые переходящих на self-hosted Git-платформу.

Мы поможем развернуть Gitea под ключ с настроенным SSL-сертификатом, резервным копированием и, при необходимости, интеграцией с существующей системой единого входа компании — от личного репозитория для одного разработчика до полноценной Git-платформы для растущей команды.

Организации и команды: управление доступом на растущем сервере

Gitea поддерживает организации с вложенными командами и гибкой настройкой прав доступа к каждому репозиторию отдельно — владелец, администратор, автор с правом пуша, читатель без права изменений, — что позволяет точно настроить, кто из сотрудников может вносить изменения в конкретный проект, а кто имеет только доступ на чтение для ознакомления с кодом. Для компаний с несколькими независимыми командами разработки такая структура организаций удобно отражает реальное разделение ответственности внутри компании.

Публичные и приватные репозитории сосуществуют на одном сервере без конфликтов: команда может использовать Gitea одновременно как площадку для внутренних закрытых проектов и как витрину для собственных open source библиотек, открытых для внешних контрибьюторов — оба сценария поддерживаются штатными средствами платформы без дополнительной настройки.

Gitea против GitHub и GitLab: когда выбор в пользу лёгкой альтернативы оправдан

Основной довод в пользу Gitea — контраст между избыточной функциональностью крупных платформ и реальными потребностями конкретной команды: если команде нужны репозитории, issues и pull request без глубокой автоматизации CI/CD, реестра контейнеров и десятков интеграций корпоративного уровня, Gitea даёт всё необходимое при кратно меньшем расходе ресурсов сервера и куда более простом администрировании одного бинарного файла вместо целого стека взаимосвязанных сервисов.

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

Runners для Gitea Actions: своё окружение сборки без внешних сервисов

Раннеры Gitea Actions — отдельные процессы, выполняющие сами шаги пайплайна (установку зависимостей, сборку, прогон тестов) — можно установить как на том же сервере, что и сам Gitea, для небольших и нечастых сборок, так и на отдельных, специально выделенных серверах для изоляции ресурсоёмких задач сборки от основного веб-интерфейса, доступного пользователям для повседневной работы с кодом.

Поддержка нескольких раннеров с разными метками (например, отдельно для сборки под разные архитектуры процессора или для задач, требующих специфичного окружения) даёт гибкость, сопоставимую с более тяжёлыми CI-системами, при значительно более простой начальной настройке, что особенно ценно для небольших команд, которым не требуется вся сложность enterprise-инструментов автоматизации сборки. Регистрация раннера на отдельном, менее нагруженном сервере занимает буквально одну команду, что упрощает горизонтальное масштабирование мощностей сборки по мере роста числа проектов команды и числа параллельно выполняемых сборочных заданий.

Пакетный реестр Gitea: не только Git-репозитории

Помимо хранения кода Gitea включает встроенный реестр пакетов, поддерживающий распространённые форматы — npm, Docker-образы, Maven, PyPI, NuGet и ряд других, — что позволяет использовать один и тот же сервер и для хранения кода, и для внутренних зависимостей команды, не разворачивая для этого отдельный специализированный сервис управления пакетами.

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