OpenClaw Gateway на Linux VPS в 2026: GitLab CI/CD автовыкладка против чистого SSH — матрица решений и FAQ по подводным камням пайплайна

На типичном Linux VPS OpenClaw Gateway живёт рядом с reverse proxy, unit’ами systemd и томами с токенами каналов. Вопрос 2026 года не «нужен ли Git», а кто и как переносит новый образ или бинарь на хост: GitLab CI/CD с защищёнными ветками и переменными или администратор по SSH с блокнотом команд. Автоматизация снижает дрейф и bus factor, но добавляет собственный класс отказов — runner не подобрался, deploy job завис в ожидании ручного gate, токен реестра не совпал с окружением. Для HTTPS, онбординга и поуровневого отката держите общий runbook: 2026: OpenClaw Gateway в продакшене — openclaw onboard, openclaw doctor / openclaw fix, HTTPS (Nginx/Caddy) и откат на Linux VPS. Если вы масштабируете CI и временные узлы, полезен соседний чеклист по токенам и сети: Короткий цикл CI в 2026: всплеск сборок и новый облачный Mac — регистрация Runner, сеть и минимальные токены за 30–60 минут (чеклист и FAQ).

Матрица решений: GitLab CI/CD против чистого SSH

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

Подводные камни пайплайна GitLab (короткий FAQ)

Deploy job не стартует. Чаще всего виноваты protected branches: пользователь CI не имеет права писать в целевую ветку или deploy разрешён только maintainers. Проверьте также теги runner’а — job с tags: [shell-prod] молча зависнет, если свободен только docker runner без этого тега.

401 к Container Registry. Разведите deploy token, project access token и CI_JOB_TOKEN: у последнего узкое окно прав и оно зависит от настроек «доступ к реестру». Для кросс-проектных pull’ов иногда проще отдельный read-only token с явным сроком.

Два параллельных pipeline на один VPS. Без mutex через resource group или внешнюю блокировку второй job может перезаписать compose в середине health-check первого. Для шлюза с открытыми сессиями это особенно болезненно.

«Всё зелёное», но шлюз не поднялся. Убедитесь, что deploy stage действительно ждёт готовности процесса (health через loopback или проверка unit’а), а не завершается на успешном docker compose up до старта приложения.

Маскирование переменных. GitLab скрывает значения в логах, но не отменяет утечку через артефакты или отладочные echo в дочерних скриптах. Держите deploy-ключи и пароли реестра в отдельных переменных с scope только на production environment и запретите наследование в дочерних pipeline fork’ов, если репозиторий публичный.

Воспроизводимый каркас GitLab → Linux VPS

Минимальная последовательность: сборка и push образа с семантическим тегом и digest, затем отдельный stage с SSH на VPS под ограниченным пользователем, pull по digest, compose up -d, дымовой health. Секреты — только в CI variables; на диск VPS кладите сжатый env-файл вне Git с правами 0600.

# build: docker build + push с тегом коммита
# deploy:
script:
  - ssh deploy@$PROD_HOST "cd /srv/openclaw && echo $GATEWAY_DIGEST > .digest && docker compose pull && docker compose up -d"
  - ssh deploy@$PROD_HOST "curl -fsS http://127.0.0.1:PORT/health"

Чистый SSH: когда он оправдан

Ручной режим уместен на этапе прототипа, при редких релизах и когда вы активно калибруете systemd, firewall и пути томов. Зафиксируйте digest каждого pull’а в локальном versions.txt, храните предыдущий compose рядом и документируйте две команды отката — иначе ночной SSH превращается в импровизацию.

Короткие ответы

Нужен ли отдельный runner на том же VPS, что и Gateway?

Необязательно, но избегайте сборки тяжёлых образов на слабом прод-узле: вынесите build в shared runner или отдельный builder, а на VPS оставьте только pull и перезапуск.

Заменяет ли GitLab Review Apps этот сценарий?

Review Apps хороши для веб-сервисов; для шлюза с долгоживущими токенами и webhook часто достаточно staging environment с теми же mount-путями, что и прод, но изолированными секретами.

Нужны ли merge trains для деплоя Gateway?

Только если вы регулярно сливаете несколько merge request подряд в одну защищённую ветку и готовы к более длинной очереди и дополнительным билдам. Для типичного одиночного production branch чаще хватает правила «один активный deploy» через resource_group или ручной gate в environment, чтобы два job не переписали друг другу compose на одном хосте.