Black Hole-серверы и Галактики Битрикс24: безопасный деплой VibeCode-приложений

Black Hole-серверы и Галактики Битрикс24 решают задачу, которая раньше требовала либо опытного DevOps-специалиста, либо мирились с открытыми портами: как запустить приложение быстро, дёшево и так, чтобы оно не стало точкой входа для атаки. Ниже - полный разбор инфраструктуры VibeCode от архитектуры до чек-листа безопасного деплоя.

Что такое сервер Black Hole

Обычный облачный сервер виден в интернете по IP-адресу - его можно просканировать, атаковать напрямую или перехватить ключи доступа. Сервер Black Hole работает иначе:

• нет публичного IP - сервер не слушает входящие соединения извне,
• невидим для сканеров - его невозможно обнаружить в открытой сети,
• соединение поднимается изнутри - через зашифрованный туннель Битрикс24 Вайбкод,
• адрес приложения имеет вид https://app-xxxxxxxx.vibecode.bitrix24.tech/ - уникальный, но доступный только авторизованным пользователям.

Когда кто-то пытается открыть приложение без доступа, платформа показывает страницу авторизации Битрикс24 - войти в обход неё невозможно, потому что Вайбкод проверяет права до того, как открыть соединение с сервером.

Три классических уязвимости облачного сервера, которые Black Hole закрывает:

Это особенно важно при вайбкодинге: ИИ-агент пишет код послушно, но не всегда предсказуемо - Black Hole изолирует любые ошибки от внешнего мира.

Деплой за 2-3 минуты: как это работает

Развернуть приложение на Black Hole-сервере можно двумя способами: автоматически (агент сам создаёт сервер по ключу - команда «задеплой на сервер») или вручную через интерфейс на vibecode.bitrix24.tech.

Под капотом деплой проходит 9 шагов:

stop → clean → download → runtime → install → env → systemd → start → healthcheck

Несколько важных деталей, которые экономят время:

• Healthcheck по умолчанию стучится на / и ждёт HTTP 200. Если ваше приложение отвечает 200 не на корне (например, API живёт на /api/...) - обязательно указывайте параметр healthPath, иначе деплой завершится ошибкой DEPLOY_FAILED.
• cleanDeploy=true включён по умолчанию - старые файлы не накапливаются.
• Среда исполнения (Python, Node.js, PostgreSQL и др.) устанавливается автоматически под ваш стек.

Сравнение с ручным деплоем по SSH:

Как агент получает ключ, отправляет команду деплоя в платформу VibeCode, которая разворачивает приложение на Black Hole-сервере и устанавливает туннель для доступа пользователей через Битрикс24.

flowchart LR
    DEV[Разработчик / ИИ-агент] -->|ключ + команда деплоя| VIBE[VibeCode Platform]
    VIBE -->|9 шагов: stop→healthcheck| BH[Black Hole-сервер]
    BH -->|зашифрованный туннель| B24[Битрикс24-портал]
    B24 -->|авторизация + доступ| USER[Пользователь]
    BH -.->|нет публичного IP| INTERNET((Интернет))

Галактики: ~25 приложений по цене одного сервера

Раньше каждое приложение требовало отдельную виртуальную машину. Галактика (Galaxy Black Hole) - это хост, который уплотняет много Black Hole-серверов на одном железе.

Ключевые параметры (на момент публикации):

Как включить: Настройки портала → тумблер «Галактики» → создать галактику вручную. Рекомендуется выбирать СРЕДНИЙ тариф сервера (больше оперативной памяти под десятки приложений). Режим both позволяет использовать галактики и обычные серверы одновременно.

Галактики - функция в активном тестировании (на момент публикации), концепция развивается в направлении «уплотнения и апгрейда».

Сон, пробуждение и поминутная тарификация

Если приложением не пользуются - сервер переходит в спящий режим и тарифицируется по ночному тарифу (фактически только за место на диске). При переходе по ссылке сервер просыпается и поднимает туннель - занимает пару минут.

Галактики, в отличие от одиночных серверов, обычно не засыпают - они постоянно принимают трафик от десятков приложений.

OPEN-режим позволяет получить SSH и прямой доступ к серверу (свой nginx, HTTPS, собственный домен). Из него можно вернуться обратно в режим «чёрной дыры». На момент публикации переключение в OPEN временно отключалось - уточняйте актуальный статус в документации платформы.

Тарификация поминутная: дневной и ночной тариф. Выключенный сервер обходится значительно дешевле работающего.

Депонирование исходников: код не потеряется

При каждом успешном деплое платформа автоматически сохраняет исходники - никаких дополнительных действий не нужно. Это закрывает несколько болезненных сценариев:

• Откат в один клик - к любой прошлой версии прямо из интерфейса.
• Смена ноутбука или ИИ-сессии - наработки не исчезают.
• Передача между разработчиками - новый человек или агент открывает сохранённую версию без потерь.

История хранится по схеме: последние версии + ежедневные срезы + еженедельные срезы. Опубликованные версии хранятся бессрочно. Если код между деплоями не изменился - лишней версии не создаётся (сравнение идёт по содержимому).

Посмотреть все версии можно в реестре «Исходники приложений».

По нашему опыту, именно депонирование спасает при сценарии «ИИ переписал рабочий код, а старая версия нигде не сохранена». Это важнее, чем кажется на старте.

События портала без поллинга

Раньше, чтобы узнать о событии в Битрикс24 (новая задача, изменение сделки), приложение вынуждено было периодически опрашивать event.get по таймеру. Платформа VibeCode решает это иначе: регистрирует обработчик на стороне Битрикс24 и доставляет каждое событие в Black Hole-приложение через туннель - публичный адрес при этом не нужен.

Пример подписки на событие добавления задачи:

curl -X POST https://vibecode.bitrix24.tech/v1/infra/servers/SERVER_ID/event-subscriptions \
  -H "X-Api-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"event":"ONTASKADD","appPath":"/api/webhooks/b24"}'

Приложение получает событие обычным POST на appPath. Важно: проверяйте auth[application_token] и отвечайте кодом 2xx. Если приложение спало - платформа разбудит его перед доставкой.

Для работы требуется сервер на OAuth-приложении с application_token; event.bind - только на коммерческом тарифе портала. Подробнее о вебхуках смарт-процессов - в отдельном гайде.

Управление доступом и безопасность ключей

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

Принцип минимальных прав: для аналитики и ИИ-агентов используйте read-only ключи - это страхует от случайной массовой перезаписи данных CRM. Данные клиентов, сделки и переписка остаются только в вашем Битрикс24; на серверы Black Hole передаются только данные, нужные для конкретного ответа, и не хранятся дольше необходимого.

Если ключ скомпрометирован:

1. Раздел API-ключи → Три точки (...) → Деактивировать (или Удалить, если ключ не нужен).
2. Откройте вкладку Журнал на сервере - проверьте подозрительную активность.
3. Выпустите новый ключ и обновите его во всех приложениях.
4. При необходимости поставьте приложение на паузу целиком.

Деактивация вступает в силу мгновенно. Удаление необратимо - сначала отвяжите серверы от ключа, если они активны.

Чек-лист безопасного деплоя

Перед тем как запустить приложение в работу, пройдитесь по этому списку:

• Выбран правильный тип ключа: API-ключ для личных задач, ключ авторизации - для приложений с доступом коллег
• Для ИИ-агентов и аналитики настроен read-only ключ
• Указан healthPath, если приложение отвечает 200 не на /
• Настроен уровень доступа к приложению (только нужные сотрудники)
• Проверено, что исходники задепонированы (раздел «Исходники приложений»)
• При необходимости включён режим сна - чтобы не платить за простаивающий сервер
• Если планируете много лёгких приложений - включены Галактики (СРЕДНИЙ тариф хоста)
• Настроена подписка на события портала вместо поллинга (если приложение реагирует на изменения в CRM)
• В журнале сервера нет подозрительных обращений после первого деплоя

Для масштабных проектов, где несколько приложений взаимодействуют с одним порталом, имеет смысл заранее продумать структуру ТЗ на доработку - это сэкономит время при передаче между разработчиками.

АС Проект помогает внедрить VibeCode

АС Проект - Платиновый партнёр Битрикс24 - помогает ИТ-командам и интеграторам настроить инфраструктуру VibeCode, выстроить безопасный деплой и собрать первые приложения. Если вы только начинаете работу с VibeCode или планируете масштабировать существующие решения - свяжитесь с нами.

Галактики и бэкапы: что изменилось к июлю 2026

🌌 Галактики - основной способ деплоя: на одном хосте-галактике живут десятки приложений, а приложение в галактике не тарифицируется за место (платите за хост, а не за каждый сервер).

💾 Полные бэкапы серверов. Теперь можно снять бэкап диска целиком - код + данные + файлы - по кнопке или по расписанию, и восстановиться из него. После инцидента 29 июня (сбой при очистке неактивных серверов, затронул <0,1% и компенсирован 5000 вайбов за сервер) автобэкапы включили для всех.

⚠️ Коды ошибок деплоя (актуальны в периоде):

• GALAXY_HOST_UNREACHABLE - хост галактики недоступен во время сборки (перенос шлюза); дождаться reconnect, не перезапускать деплой - исходный build живёт на VM (иначе EXEC_BUSY).
• EXEC_BUSY - одна операция на сервер за раз; lock может висеть на уровне галактики.
• MAX_SERVERS_REACHED - лимит серверов (по умолчанию 5, поднимается админом портала).
• Gateway HTTP 413 - превышен лимит тела запроса при деплое (фактический потолок ~780 КБ). Обход: передавать архив через source.url - агент забирает по ссылке, размер не важен.

Данные на июль 2026 - платформа VibeCode в активной бете, цифры (квоты, цены, версии) меняются. Сверяйтесь с документацией VibeCode.

Частые вопросы