Перейти к содержанию

Как устроен RemoteHangar

Страница для технического директора и инженера по безопасности: из чего состоит платформа, где лежат данные, как агент работает в песочнице и как устанавливаются обновления.

Архитектура

RemoteHangar — один процесс Node.js под systemd и база SQLite. Команда работает в браузере. Веб-консоль можно поставить на телефон как приложение.

Главная единица платформы — бей (от английского bay, «отсек ангара»). Бей — рабочее место одного агента: рабочий каталог, домашний каталог, подключённые репозитории, переменные окружения и очередь задач. У пользователя может быть несколько беев.

На каждый ход агента платформа запускает отдельный процесс в песочнице. Процесс обращается к API провайдера модели и к MCP-серверам, которые подключены к бею.

Коннектор на Go устанавливается на ваши тестовые и боевые серверы и подключается к платформе по mTLS. Через него агенты выполняют там файловые и shell-инструменты, а вы получаете терминал, логи и состояние сервера.

Архитектура RemoteHangarБраузер обращается к nginx по HTTPS и WSS. nginx передаёт запросы единственному сервису RemoteHangar на вашем хосте: REST API, WebSocket, SSE, запуск сессий, диспетчер очереди, подтверждения и база SQLite. На каждый ход агента сервис запускает процесс бея в песочнице; процесс сам обращается к API провайдера модели, а к трекерам и другим системам — через MCP-серверы плагинов.Браузер разработчикаSPA / PWA · чат, очередь, админкаHTTPS · WSSnginx · TLSREMOTEHANGAR — ОДИН СЕРВИС НА ВАШЕМ ХОСТЕREST API/api/* · /v1/*WebSocketчат-стрим · терминал · событияSSEпотоковые ответы Public APIЗапуск сессийзапускает процессы беев и следит за нимиДиспетчер очередиодна задача на бей за разРазрешенияподтверждение действий агентаSQLite · WALпользователи · сессии · очередь задач · учётные данные · аудитодин файл на диске, снапшот перед каждым обновлениемпроцесс на каждый ходБей · песочницасвои пространства имён, корень только для чтения, свой HOMEпроцесс агентаживёт один ходMCP-серверы плагиновstdio; встроенные — в сервисеAPI · MCPВнешние системыAPI провайдера моделиТрекеры задачGit-хостыВаши серверы (mTLS)Метрики · трейсыУведомления

Песочница

Каждый процесс агента запускается внутри bubblewrap — песочницы на пространствах имён ядра Linux.

Внутри песочницы корень файловой системы смонтирован только для чтения. Запись открыта в рабочий и домашний каталог бея, в каталог /home, в кэши вложений и плагинов и в каталог памяти агента. Каталог /tmp у каждого процесса свой.

Повысить права агент не может: юнит systemd запрещает это флагом NoNewPrivileges, sudo нет, системные каталоги защищены флагом ProtectSystem=strict. Сам сервис видит /home только для чтения (ProtectHome=read-only), но песочница агента отдельно открывает /home на запись — это ограничение есть в списке на странице «Безопасность».

Чтение между беями пока не изолировано: корень файловой системы смонтирован только для чтения, но не скрыт. Закрыть чтение между беями — в планах.

  • Docker внутри бея включается отдельно, флагом --with-docker. Все беи делят один сокет Docker, а он даёт доступ к хосту.
  • Терминал администратора работает вне песочницы, от имени сервиса.
Изоляция беевДва бея на одном Linux-сервере. Процесс агента работает в собственных пространствах имён: рабочий каталог, свой HOME и общие кэши доступны на запись; каталог администратора и остальной хост смонтированы только для чтения; повышение привилегий закрыто. Сеть открыта намеренно. Песочница живёт один ход, состояние сессии остаётся в базе на вашем диске.ОДИН LINUX-СЕРВЕР · СЕРВИС ПОД ОДНИМ СИСТЕМНЫМ ПОЛЬЗОВАТЕЛЕМbay · aliceпроцесс агента в своих пространствах имёнrwрабочий каталог беярепозитории, которые правит агентrwсвой HOMEконфиг агента, локальные пакетыrwобщие кэшивложения и кэш плагиновroнавыки · плагины · агентыобщий каталог, который ставит админroостальной хосттолько для чтения, но не скрыт; /home открыт на запись✕sudo и повышение привилегийзакрыты на уровне ядра (no_new_privs)bay · bobто же устройство, отдельный процессrwрабочий каталог беясвои репозитории и веткиrwсвой HOMEсвой конфиг и пакетыrwобщие кэшите же кэши, что у всех беевroнавыки · плагины · агентытот же каталог, только чтениеroостальной хоствключая другие беи · изоляция чтения: в планах✕sudo и повышение привилегийзакрыты для каждого беяСеть не изолируется — это осознанный выборАгенту нужны API провайдера модели, ваши MCP-серверы и git remote.Одна песочница на ходсообщениезапуск процессаответ агентапроцесс завершёнсостояние сессии остаётся в базе на вашем диске

Очередь задач

У каждого бея своя очередь. Задачу ставит человек: пишет её текстом или добавляет ссылку на тикет YouTrack, Jira или Notion. Из трекера платформа задачи не забирает.

Бей выполняет задачи по одной. Задача остаётся в работе столько ходов, сколько нужно. Завершает её агент — отметкой done или blocked — или человек кнопкой «Готово».

Отметка blocked ставит очередь на паузу: агенту нужен ответ человека. Ходы очереди идут от имени владельца бея, даже если задачу поставил администратор.

Лимиты: 10 новых задач в минуту на пользователя и 200 незавершённых задач на бей.

СостояниеЧто значит
queuedЖдёт в очереди
runningАгент работает над задачей
doneАгент или человек отметил задачу выполненной
blockedАгенту нужен человек, очередь на паузе
errorЗадача или бей упали, очередь на паузе
cancelledЗадачу отменили
skippedЗадачу пропустили
Жизненный цикл задачи в очередиЧеловек добавляет задачу, она ждёт в статусе queued. Диспетчер запускает её: running, не больше одной на бей. Агент отмечает done или blocked, либо человек нажимает Done; сбой после трёх попыток — error. Stop или сбой с повтором возвращают задачу в queued; ответ владельца в чате продолжает задачу в blocked; Retry возвращает blocked или error в queued; Skip и Cancel пропускают задачу.enqueueдиспетчерStop · сбой с повторомагент отметил done · или кнопка Doneагент: не может закончитьвладелец ответил в чате3 попытки исчерпаныSkip · CancelRetry → обратно в queuedqueuedждёт очереди · можно правитьrunningне больше одной на бейdoneитог и артефакты в карточкеblockedагент не может закончить · паузаerrorпопытки исчерпаны · паузаcancelledотменил человекskippedпропустил человек1 · Задача не закрывается сама: агент отмечает done или blocked, либо человек нажимает Done.2 · Ходы очереди всегда идут от имени владельца бея.

Где лежат данные

Все данные платформы лежат в четырёх каталогах на вашем сервере. Рабочие каталоги беев — в корнях, которые вы указали при установке, например /opt/repos и /home.

КаталогЧто в нём
/opt/remote-hangarУстановленные версии платформы и ссылка current на текущую
/var/lib/remote-hangarБаза SQLite, история сессий, навыки и плагины, логи
/etc/remote-hangarФайл настроек config.env и мастер-ключ шифрования в каталоге credentials
/var/cache/remote-hangarКэши вложений и плагинов

Public API v1

API запускает агента из CI, бота или внутреннего сервиса. Описание OpenAPI и Swagger открываются по адресу /docs вашей установки.

  • Сессии: создать, отправить промпт, прервать, закрыть. Ответ приходит потоком SSE.
  • Одноразовый запуск POST /v1/oneshot: платформа создаёт временный бей на один ответ.
  • Ответ по JSON-схеме: в строгом режиме на /v1/oneshot платформа проверяет ответ по схеме и повторяет запрос до трёх раз.
  • Ключи идемпотентности живут 24 часа.
  • Токены со скоупами. По умолчанию токен живёт 90 дней, в базе хранится только его хеш SHA-256.
  • Лимиты на каждый API-токен и на весь сервер. Три вида тайм-аутов: на весь ход, до первого события и на тишину в ответе.
  • Файлы бея можно скачать списком или архивом tar.gz.
curl -N https://hangar.example.ru/v1/oneshot \
  -H "Authorization: Bearer $HANGAR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"prompt": "Найди в репозитории неиспользуемые зависимости", "idempotency_key": "deps-2026-09-24"}'

Обновления и откат

Таймер systemd запускает remote-hangar update --if-idle. Обновление устанавливается только в окно обслуживания, которое вы задали, и только когда агенты свободны. Что агенты свободны, сервер проверяет дважды.

Манифест релиза подписан minisign. Ключа подписи нет на сервере, который раздаёт релизы. Перед установкой ваш сервер проверяет подпись и контрольные суммы. Если утилиты проверки на сервере нет, установщик только предупреждает; флаг --require-signature делает проверку обязательной.

Перед обновлением платформа снимает копию базы. Если после обновления сервис не прошёл проверку работоспособности, код и схема базы возвращаются к прежней версии автоматически.

Если выпущенная версия оказалась плохой, мы возвращаем канал обновлений на прежнюю версию, и серверы, которые ещё не обновились, её не получат. Версию можно закрепить, а автообновление — выключить.

Требования

Скрипт установки выдаём участникам пилота.

  • Ubuntu 22.04, процессор x64, systemd, права root для установки. На Ubuntu 24.04 песочнице мешают ограничения пространств имён.
  • Память: база плюс около 350 МБ на каждый одновременный ход агента. По умолчанию сервису выделено 3 ГБ — это четыре одновременных хода.
  • Диск: около 250 МБ на скачивание каждой версии, после распаковки больше; прежние версии остаются для отката. Ещё 127 МБ на поиск по коду и место под браузеры для тестов.
  • Доступ в сеть к провайдеру модели и к серверу обновлений. HTTPS-прокси поддерживается.

Проверим на вашем сервере

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

Обсудить пилот