Почему мы выбрали GitFlic

Опыт команды: как инфраструктурный проект на 16 серверов живёт на GitFlic уже несколько лет. Что именно дал нам GitFlic и почему мы рекомендуем его похожим проектам.

Что мы построили

Starter — программа, которая на чистой машине разворачивает всю инфраструктуру. Клонирует репозитории, генерирует docker-compose, поднимает сеть с отдельной подсетью, запускает сервисы и обновляет сама себя.

16 типов серверов на 16 репозиториях. Каждый сервер — отдельный репозиторий, отдельный Docker Compose стек, изолированная подсеть:

Ключевое отличие от обычного проекта: Starter не хранит код — он его исполняет на машине пользователя в момент установки. Код из репозитория запускается с правами администратора, поднимает сеть, сервисы и проверяет результат.

Именно поэтому мы выбрали платформу, которую можно развернуть самому.

Три причины, которые всё решили

1. Мы подняли GitFlic у себя

Это то, что закрыло нашу главную потребность.

GitFlic разворачивается как обычный стек — сам GitFlic, PostgreSQL, Redis, RabbitMQ. Поднять его на своём сервере — вопрос часа, а не проекта на месяц.

Сейчас наш код общается именно с self-hosted инстансом:

// Jobs/ForControlProjects/checkNewCommits.php
$url = 'gitflic.myidon.site/rest-api';

// Installer/DockerConfGeneratorController.php
$response = Http::get(
    'http://gitflic.myidon.site/project/adminuser/docker/blob/raw?file=.env.example'
);

Что это дало в работе:

• Инфраструктура не зависит от чужого SaaS — работает, даже когда публичная платформа недоступна
• Один и тот же клиент работает и с self-hosted, и с публичным GitFlic — один формат ответов, никакого дублирования кода
• Git, REST API и вебхуки — из одного источника
• Полный контроль над данными — всё в своей юрисдикции

Последний пункт для инфраструктурных проектов важнее, чем кажется.

2. Свой реестр Docker-образов

GitFlic — не только код. Это ещё и registry для контейнерных образов. Мы публикуем свои образы туда же, где лежит код:

# CLIENTv2/docker/docker-compose.yml
image: registry.gitflic.ru/project/impor/client/vpn-other:0.0.1

И написали отдельный build-инструментарий, который собирает и публикует образы в этот реестр автоматически.

Что это даёт на практике:

• Код и образы в одном месте — один хостинг, один аккаунт, один бэкап
• Одна аутентификация вместо двух: Git-токен и registry-токен в одном
• Меньше точек отказа — не нужно держать и синхронизировать внешний Docker Hub и приватный registry
• Версионирование рядом с исходниками — тег образа и коммит видно рядом

3. Автообновления, которые просто работают

Starter проверяет обновления и обновляет сам себя — с приоритетами на три ветки:

# starter/files/configs/starter_repos.py
STARTER_REPOSITORIES = [
    {'name': 'Основной',  'branch': 'master',  'priority': 1},
    {'name': 'Резервный', 'branch': 'main',    'priority': 2},
    {'name': 'Dev',       'branch': 'develop', 'priority': 3},
]

Дополнительно при обновлении каждого сервера:

• git pull --ff-only — безmerge-коммитов и неожиданных расхождений
• health-check 12 попыток с интервалом 5 секунд
• автооткат, если после обновления что-то сломалось
• таймауты на каждый этап, чтобы зависший шаг не блокировал всё

Когда инфраструктура обновляется сама и откатывается сама — про это забываешь. Это лучший комплимент инфраструктурному коду.

Как это выглядит в коде

Весь реестр серверов — один декларативный словарь. Добавить сервер — это добавить запись:

# starter/files/configs/server_types.py
'embeddings': {
    'name': 'Генератор векторов',
    'default_port': 5000,
    'order': 2,
    'strategy': UPDATE_PYTHON,
    'repository': {
        'url': 'https://gitflic.ru/project/impor/embeddings.git',
        'branch': 'master',
    },
    'update': {
        'pull_mode': '--ff-only',
        'health_check': {'enabled': True, 'retries': 12, 'interval': 5},
        'rollback_on_failure': True,
    },
},

Никакой отдельной логики под каждый сервер: стратегия обновления, проверка здоровья и откат описаны один раз и применяются ко всем.

Программное управление — 16 REST-эндпоинтов, которыми пользуются AI-агенты:

GET    /api/v1/servers                     POST   /api/v1/servers/install
GET    /api/v1/servers/types               POST   /api/v1/servers/<id>/start
GET    /api/v1/servers/<id>                POST   /api/v1/servers/<id>/stop
GET    /api/v1/servers/<id>/config         POST   /api/v1/servers/<id>/update
PUT    /api/v1/servers/<id>/config         DELETE /api/v1/servers/<id>/remove
GET    /api/v1/servers/<id>/update/plan    POST   /api/v1/servers/update-clients
GET    /api/v1/servers/<id>/update/preflight
GET    /api/v1/status  ·  /drives  ·  /folders

Стек

Раскрываем наш стек — вдруг кому-то пригодится для своего проекта:

ИИ-слой — отдельная находка: 8 агентов (StarterAgent, ChatAgent, DroneAgent, TaskSchedulerAgent, IoTGatewayAgent, PhoneAgent, RoomManagerAgent, GardenAgent) проходят пятиуровневый пайплайн pre → router → inter → agent → post. Агенты умеют вызывать REST API оркестратора, поэтому установка сервера — это обычный текстовый запрос.

Рекомендация

GitFlic — хороший выбор, если:

• ✅ вы хотите поднять хостинг самим и не зависеть от чужого SaaS
• ✅ вам важно, чтобы код и Docker-образы лежали рядом
• ✅ вы работаете внутри команды и discoverability не главный фактор
• ✅ вам нужен стабильный REST API для автоматизации
• ✅ вы цените, что платформа выросла из российских и живёт рядом с вами

Для open-source-проекта, которому нужна широкая аудитория и звёзды, или если вы хотите Copilot — GitHub остаётся разумным выбором. Задачи у платформ разные, и обе отлично справляются со своими.

Спасибо

Спасибо команде GitFlic за то, что продукт можно развернуть самому, за Container Registry в одном месте с кодом, и за API, который стабильно отвечает.

Если вы делаете что-то похожее — расскажите в комментариях, как у вас устроено. Интересно сравнить.

Открыт к PR: идеи по структуре статьи, поправки в тексте или уточнения по цифрам — присылайте, поправим.

Лицензия

Текст — CC BY-SA 4.0. Код в примерах можно свободно использовать со ссылкой на источник.