VibeOS — Docker

Существует два различных способа взаимодействия Docker с VibeOS:

1. Запуск VibeOS В Docker — сам агент работает внутри контейнера (основная тема этой страницы)
2. Docker как терминальный бэкенд — агент работает на вашем хосте, но выполняет каждую команду внутри единого постоянного изолированного контейнера Docker, который сохраняется между вызовами инструментов, /new и сабагентами на всё время жизни процесса VibeOS (см. Конфигурация → Docker Backend)

Эта страница описывает вариант 1. Контейнер хранит все пользовательские данные (конфигурацию, ключи API, сессии, навыки, воспоминания) в едином каталоге, смонтированном с хоста в /opt/data. Образ сам по себе не имеет состояния и может быть обновлён путём загрузки новой версии без потери какой-либо конфигурации.

Быстрый старт

Если вы запускаете VibeOS впервые, создайте каталог данных на хосте и запустите контейнер в интерактивном режиме для прохождения мастера настройки:

Избегайте браузерных консолей VPS для команд установки

Некоторые провайдеры VPS (Hetzner Cloud и ряд других) предлагают браузерную консоль для управления хостами. Эти консоли некорректно передают специальные символы — : может прийти как ;, @ может быть отображён неверно, а неанглийские раскладки клавиатуры работают ещё хуже — что незаметно портит аргументы docker run такие как -v ~/.vibeos:/opt/data, -e KEY=value и вставленные ключи API / токены.

Подключайтесь через SSH (ssh root@<host>) для безопасного ввода команд копированием. Если вы вынуждены использовать браузерную консоль, вводите команды вручную вместо вставки и дважды проверяйте каждый символ :, @, = и / в результате перед нажатием Enter.

mkdir -p ~/.vibeos
docker run -it --rm \
  -v ~/.vibeos:/opt/data \
  nousresearch/vibeos-agent setup

Это запустит мастер настройки, который запросит ваши ключи API и запишет их в ~/.vibeos/.env. Вам нужно сделать это только один раз. Настоятельно рекомендуется на этом этапе настроить чат-систему для работы шлюза.

подсказка

Внутри контейнера выполните vibeos setup --portal один раз — токен обновления сохраняется в смонтированном томе ~/.vibeos. См. Nous Portal.

Запуск в режиме шлюза

После настройки запустите контейнер в фоновом режиме как постоянный шлюз (Telegram, Discord, Slack, WhatsApp и т.д.):

docker run -d \
  --name vibeos \
  --restart unless-stopped \
  -v ~/.vibeos:/opt/data \
  -p 8642:8642 \
  nousresearch/vibeos-agent gateway run

Порт 8642 открывает API-сервер, совместимый с OpenAI и эндпоинт проверки здоровья шлюза. Он необязателен, если вы используете только чат-платформы (Telegram, Discord и т.д.), но необходим, если вы хотите, чтобы панель управления или внешние инструменты могли обращаться к шлюзу.

Шлюз работает под наблюдением

Внутри официального Docker-образа gateway run автоматически контролируется s6-overlay: если процесс шлюза аварийно завершается, он перезапускается в течение пары секунд без потери контейнера, а панель управления (когда установлен VIBEOS_DASHBOARD=1) контролируется вместе с ним. Сам процесс CMD gateway run — это sleep infinity, который поддерживает контейнер в живых, пока s6 управляет фактическим процессом шлюза — так что docker stop по-прежнему корректно всё останавливает, но docker logs показывает вывод контролируемого шлюза.

Вы увидите однострочную «хлебную крошку» в docker logs, подтверждающую обновление. Чтобы отказаться — и получить прежнюю семантику «шлюз — главный процесс контейнера, выход из шлюза = выход из контейнера» — передайте --no-supervise или установите VIBEOS_GATEWAY_NO_SUPERVISE=1. Отказ полезен для CI-дымовых тестов, которые хотят, чтобы контейнер завершался с кодом возврата шлюза; для production-развёртываний контролируемый режим по умолчанию строго лучше.

Это поведение относится только к образу на основе s6. Более ранние (на основе tini) образы по-прежнему запускают gateway run как основной процесс переднего плана.

Куда попадают логи шлюза

См. раздел Куда попадают логи ниже для полной карты маршрутизации (шлюзы по профилям, панель управления, согласователь при загрузке, docker logs всего контейнера).

Жёсткие остановки цикла инструментов для unattended-шлюзов

Параметр tool_loop_guardrails.hard_stop_enabled по умолчанию имеет значение false, что разумно для интерактивных сессий CLI и TUI, где человек может видеть повторяющиеся предупреждения о вызовах инструментов. В unattended-развёртываниях шлюза или сервера одних предупреждений может быть недостаточно, чтобы остановить агента, застрявшего в повторяющемся цикле вызовов инструментов. Операторы, желающие получить поведение автоматического выключателя, должны явно включить жёсткие остановки в config.yaml профиля:

tool_loop_guardrails:
  hard_stop_enabled: true
  hard_stop_after:
    exact_failure: 5
    idempotent_no_progress: 5

Примечание: API-сервер включается через API_SERVER_ENABLED=true. Чтобы открыть к нему доступ за пределами 127.0.0.1 внутри контейнера, также установите API_SERVER_HOST=0.0.0.0 и API_SERVER_KEY (минимум 8 символов — сгенерируйте с помощью openssl rand -hex 32). Пример:

docker run -d \
  --name vibeos \
  --restart unless-stopped \
  -v ~/.vibeos:/opt/data \
  -p 8642:8642 \
  -e API_SERVER_ENABLED=true \
  -e API_SERVER_HOST=0.0.0.0 \
  -e API_SERVER_KEY="$(openssl rand -hex 32)" \
  -e API_SERVER_CORS_ORIGINS='*' \
  nousresearch/vibeos-agent gateway run

Открытие любого порта на машине, имеющей выход в интернет, представляет угрозу безопасности. Не делайте этого, если вы не понимаете риски.

Запуск панели управления

Встроенная веб-панель управления работает как контролируемый сервис s6-rc вместе со шлюзом в том же контейнере. Установите VIBEOS_DASHBOARD=1, чтобы включить её:

docker run -d \
  --name vibeos \
  --restart unless-stopped \
  -v ~/.vibeos:/opt/data \
  -p 8642:8642 \
  -p 9119:9119 \
  -e VIBEOS_DASHBOARD=1 \
  nousresearch/vibeos-agent gateway run

Панель управления контролируется s6 — если она аварийно завершается, s6-supervise автоматически перезапускает её после короткой паузы. Вывод stdout/stderr панели управления перенаправляется в docker logs <container> (без префикса; собственный вывод шлюза теперь находится в файле s6-log для каждого профиля — см. Куда попадают логи ниже — так что два потока не конфликтуют).

Переменная окружения	Описание	По умолчанию
VIBEOS_DASHBOARD	Установите в 1 (или true / yes), чтобы включить контролируемый сервис панели управления	(не установлена — сервис зарегистрирован, но остановлен)
VIBEOS_DASHBOARD_HOST	Адрес привязки для HTTP-сервера панели управления	0.0.0.0
VIBEOS_DASHBOARD_PORT	Порт для HTTP-сервера панели управления	9119
VIBEOS_DASHBOARD_INSECURE	Устарело / не используется. Ранее обходил шлюз аутентификации; начиная с ужесточения безопасности в июне 2026 года больше не отключает аутентификацию. Привязка не к loopback всегда требует провайдера аутентификации	(игнорируется — вместо этого настройте провайдера)

Панель управления внутри контейнера по умолчанию привязывается к 0.0.0.0 — без этого опубликованный порт -p 9119:9119 не был бы доступен с хоста. Чтобы ограничить привязку loopback-интерфейсом контейнера (для настроек с sidecar / обратным прокси), установите VIBEOS_DASHBOARD_HOST=127.0.0.1.

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

1. Хост привязки не является loopback (например, значение по умолчанию 0.0.0.0 внутри контейнера), и
2. Зарегистрирован плагин DashboardAuthProvider.

Существует три встроенных способа удовлетворить второе условие:

• Имя пользователя / пароль — самый простой для самостоятельного / локального / домашнего контейнера в доверенной сети или за VPN: установите VIBEOS_DASHBOARD_BASIC_AUTH_USERNAME + VIBEOS_DASHBOARD_BASIC_AUTH_PASSWORD (и VIBEOS_DASHBOARD_BASIC_AUTH_SECRET для стабильных сессий после перезапуска). Не подходит для прямого доступа из публичного интернета.
• OAuth (Nous Portal) — для хостинговых / публичных развёртываний: провайдер dashboard_auth/nous активируется всякий раз, когда установлен VIBEOS_DASHBOARD_OAUTH_CLIENT_ID.
• Самостоятельный OIDC — для аутентификации через собственного провайдера удостоверений по стандарту OpenID Connect: провайдер dashboard_auth/self_hosted активируется, когда установлены VIBEOS_DASHBOARD_OIDC_ISSUER + VIBEOS_DASHBOARD_OIDC_CLIENT_ID.

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

Если ни один провайдер не зарегистрирован, а привязка не является loopback, панель управления завершает работу при запуске с конкретной ошибкой, указывающей на отсутствующую переменную окружения. Больше нет запасного варианта, который обслуживал бы панель управления без аутентификации на публичной привязке: VIBEOS_DASHBOARD_INSECURE=1 теперь является устаревшей неработающей опцией (она выводит предупреждение и игнорируется). Настройте провайдера или привяжите VIBEOS_DASHBOARD_HOST=127.0.0.1 и обращайтесь к панели управления через SSH-туннель / Tailscale.

Почему был удалён --insecure

Неаутентифицированная публичная панель управления была точкой входа для кампании по сохранению MCP-конфигурации в июне 2026 года: интернет-сканеры находили открытые панели управления (и API-серверы OpenAI) и заставляли агента устанавливать бэкдор через SSH-ключ. Шлюз аутентификации теперь обязателен для каждой привязки не к loopback. Для доверенной локальной сети / домашнего сервера встроенный провайдер имени пользователя и пароля (VIBEOS_DASHBOARD_BASIC_AUTH_USERNAME + _PASSWORD) — это способ, не требующий дополнительной инфраструктуры.

Запуск панели управления в отдельном контейнере поддерживается, если этот контейнер использует общее пространство имён PID и сеть хоста (например, network_mode: host, как это делает docker-compose.yml самого репозитория — см. его сервис dashboard). Для обнаружения активности шлюза требуется общее пространство имён PID с процессом шлюза, поэтому ограничение применяется только к панелям управления, запущенным в изолированных контейнерах в bridge-сети без общего пространства имён PID.

Интерактивный запуск (CLI-чат)

Чтобы открыть интерактивную чат-сессию с существующим каталогом данных:

docker run -it --rm \
  -v ~/.vibeos:/opt/data \
  nousresearch/vibeos-agent

Или, если у вас уже открыт терминал в запущенном контейнере (например, через Docker Desktop), просто выполните:

/opt/vibeos/.venv/bin/vibeos

Постоянные тома

Том /opt/data является единственным источником истины для всего состояния VibeOS. Он сопоставляется с каталогом ~/.vibeos/ на вашем хосте и содержит:

Путь	Содержимое
.env	Ключи API и секреты
config.yaml	Вся конфигурация VibeOS
SOUL.md	Личность / идентичность агента
sessions/	История разговоров
memories/	Постоянное хранилище воспоминаний
skills/	Установленные навыки
home/	Домашний каталог для подпроцессов инструментов VibeOS (git, ssh, gh, npm и CLI навыков) для каждого профиля
cron/	Определения запланированных задач
hooks/	Хуки событий
logs/	Журналы выполнения
skins/	Пользовательские оболочки CLI

Неизменяемое дерево установки

В хостинговых и опубликованных Docker-образах /opt/vibeos — это установленное дерево приложения. Оно принадлежит root и доступно только для чтения пользователю времени выполнения vibeos, поэтому действия агента, сессии шлюза, действия панели управления и обычные команды docker exec vibeos vibeos ... не могут редактировать исходный код, встроенный .venv, node_modules или TUI-сборку на месте.

Всё изменяемое состояние VibeOS находится в /opt/data: конфигурация, .env, профили, навыки, воспоминания, сессии, логи, загрузки панели управления, плагины и другие файлы, управляемые пользователем. Образ также отключает запись .pyc во время выполнения и ленивую установку зависимостей VibeOS в /opt/vibeos; дополнительные зависимости платформы, необходимые опубликованному образу, должны быть встроены в образ или установлены через новую сборку образа.

В хостинговых / опубликованных образах самоулучшение агента ограничено навыками, памятью, плагинами и конфигурацией в /opt/data. Установленный исходный код в /opt/vibeos неизменяем; изменения ядра вносятся через PR в репозиторий и поставляются путём обновления образа, а не редактированием работающей установки.

Если оператору необходимо восстановить или проверить файлы за пределами /opt/data, используйте оболочку root намеренно. Прокладка vibeos обычно возвращает docker exec vibeos vibeos ... к пользователю времени выполнения; установите VIBEOS_DOCKER_EXEC_AS_ROOT=1 для однократного вызова root, когда вам явно нужна семантика root.

CLI навыков, которые хранят учётные данные в ~, должны быть инициализированы относительно домашнего каталога подпроцесса, а не только корня тома данных. Например, навык xurl хранит состояние OAuth в ~/.xurl; в официальной компоновке Docker вызовы инструментов VibeOS читают это как /opt/data/home/.xurl, поэтому выполняйте ручную аутентификацию xurl с HOME=/opt/data/home и проверяйте с помощью HOME=/opt/data/home xurl auth status.

предупреждение

Никогда не запускайте два контейнера шлюза VibeOS одновременно с одним и тем же каталогом данных — файлы сессий и хранилища памяти не предназначены для одновременной записи.

Поддержка нескольких профилей

VibeOS поддерживает несколько профилей — отдельные подкаталоги ~/.vibeos/, которые позволяют запускать независимых агентов (разные SOUL, навыки, память, сессии, учётные данные) из одной установки. Внутри официального Docker-образа дерево контроля s6 обрабатывает каждый профиль как полноценный контролируемый сервис, поэтому рекомендуемая конфигурация — один контейнер, размещающий все профили.

Каждый профиль, созданный с помощью vibeos profile create <name>, получает:

• Выделенный слот сервиса s6 в /run/service/gateway-<name>/, динамически регистрируемый средой выполнения — без пересборки контейнера.
• Автоматический перезапуск при сбое, управляемый s6-supervise.
• Ротируемые журналы для каждого профиля в ${VIBEOS_HOME}/logs/gateways/<name>/current (10 архивов × 1 МБ каждый).
• Сохранение состояния при перезапусках контейнера: согласователь при загрузке читает gateway_state.json из каталога каждого профиля и поднимает слот обратно только для тех профилей, чьё последнее записанное состояние было running. Только шлюз, который вы явно остановили (vibeos gateway stop), остаётся остановленным после перезапуска — перезапуск контейнера, обновление образа или неожиданный выход оставляют записанное состояние как running, поэтому шлюз автоматически запускается при следующей загрузке.

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

# Создание профиля — регистрирует слот s6 gateway-<name>.
docker exec vibeos vibeos profile create coder

# Запуск / остановка / перезапуск — отправляет s6-svc; жизненный цикл шлюза переживает docker restart.
docker exec vibeos vibeos -p coder gateway start
docker exec vibeos vibeos -p coder gateway stop
docker exec vibeos vibeos -p coder gateway restart

# Статус — сообщает `Manager: s6 (container supervisor)` внутри контейнера.
docker exec vibeos vibeos -p coder gateway status

# Удаление профиля — также удаляет слот s6.
docker exec vibeos vibeos profile delete coder

Под капотом vibeos gateway start/stop/restart внутри контейнера перехватывается и направляется в s6-svc для соответствующего каталога сервиса; вам не нужно изучать команды s6 напрямую. Для просмотра состояния супервизора используйте /command/s6-svstat /run/service/gateway-<name> (обратите внимание, что /command/ находится в PATH только для процессов, порождённых деревом контроля — при вызове из docker exec передавайте абсолютный путь).

Доступ к нескольким профилям извне контейнера

Две разные поверхности обращаются к шлюзу профиля извне, и они ведут себя по-разному — не путайте их:

VibeOS Desktop (и веб-панель управления). Подключение Remote Gateway в приложении Desktop обращается к бэкенду vibeos dashboard (порт по умолчанию 9119, включается VIBEOS_DASHBOARD=1) — не к API-серверу OpenAI. Один бэкенд панели управления обслуживает каждый совместно расположенный профиль: переключатель профилей в приложении отправляет целевой профиль с каждым запросом, и бэкенд открывает VIBEOS_HOME этого профиля на диске. Таким образом, вам не нужен второй порт — или второе подключение — для каждого профиля для Desktop; одно подключение :9119 покрывает их все через переключатель.

Клиенты API, совместимые с OpenAI (Open WebUI, LobeChat, /v1/...). Они обращаются к API-серверу каждого профиля, который привязывается к порту 8642 для каждого профиля (разрешается из API_SERVER_PORT / platforms.api_server.extra.port — нет автоматического выделения и нет ключа config.yaml/gateway.port). Если вы хотите, чтобы клиент обращался к конкретному второму профилю, дайте этому профилю отдельный API_SERVER_PORT в его собственном .env, иначе его шлюз попытается привязать 8642 и будет конфликтовать с профилем по умолчанию:

# Создание профиля (регистрирует его слот s6 gateway-<name>)
docker exec vibeos vibeos profile create work

# Направьте его API-сервер на свободный порт (запись в собственный .env профиля)
cat >> /opt/data/profiles/work/.env <<'EOF'
API_SERVER_ENABLED=true
API_SERVER_PORT=8643
EOF

docker exec vibeos vibeos -p work gateway restart

Храните API_SERVER_PORT в собственном .env каждого профиля, никогда в блоке environment: всего контейнера — глобальное значение заставило бы каждый профиль использовать один и тот же порт, и они бы конфликтовали. При bridge-сети опубликуйте дополнительный порт в docker-compose.yml (- "8643:8643"); с network_mode: host он уже доступен на хосте. Подключение к порту 8642 профиля по умолчанию остаётся нетронутым.

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

До миграции на s6 рекомендовался шаблон «один контейнер на профиль», потому что не было внутриконтейнерного супервизора для управления несколькими шлюзами. С s6 в качестве PID 1 это больше не нужно, и компоновка с одним контейнером проще почти по всем параметрам:

	Один контейнер, много профилей	Один контейнер на профиль
Накладные расходы на диск	Один образ, один встроенный venv, один кеш Playwright	N образов / N кешей
Накладные расходы на память	Общий кеш интерпретатора Python, общие node_modules	Дублируется для каждого контейнера
Создание профиля	docker exec ... vibeos profile create <name> (секунды)	Новый вызов docker run + выделение порта + bind-mount конфигурации
Восстановление после сбоя профиля	s6-supervise автоматический перезапуск	--restart unless-stopped Docker (медленнее, убивает работу соседних)
Логи	Ротируемый файл для каждого профиля через s6-log, плюс журнал аудита загрузки контейнера	docker logs <name> для каждого контейнера — без встроенной ротации
Резервное копирование	Один каталог ~/.vibeos	N каталогов для координации

Профиль по умолчанию (default) всегда регистрируется при первой загрузке, поэтому новый контейнер поставляется с одним контролируемым шлюзом «из коробки». Дополнительные профили добавляются чисто во время выполнения.

Когда вам НУЖЕН отдельный контейнер

Профиль в контейнере — это значение по умолчанию. Запускайте отдельный контейнер для каждого профиля только при наличии конкретной причины:

• Изоляция ресурсов для каждой рабочей нагрузки — например, вышедшая из-под контроля сессия браузерного инструмента в профиле A не должна вызывать OOM в профиле B. Контейнеры дают вам --memory / --cpus для каждого профиля.
• Независимая фиксация версии образа — разные теги upstream-образов для разных рабочих нагрузок.
• Сегментация сети — отдельные сети Docker для каждого профиля (например, один для клиентов, другой для внутреннего использования).
• Соответствие требованиям / радиус взрыва — разные учётные данные никогда не используют общее дерево процессов на уровне ОС.

В этих случаях объявите один сервис для каждого профиля с отдельными container_name, volumes и ports:

services:
  vibeos-work:
    image: nousresearch/vibeos-agent:latest
    container_name: vibeos-work
    restart: unless-stopped
    command: gateway run
    ports:
      - "8642:8642"
    volumes:
      - ~/.vibeos-work:/opt/data

  vibeos-personal:
    image: nousresearch/vibeos-agent:latest
    container_name: vibeos-personal
    restart: unless-stopped
    command: gateway run
    ports:
      - "8643:8642"
    volumes:
      - ~/.vibeos-personal:/opt/data

Предупреждение из раздела Постоянные тома по-прежнему действует: никогда не направляйте два контейнера на один и тот же каталог ~/.vibeos одновременно. Супервизор s6 внутри каждого контейнера управляет своим собственным набором профилей; совместное использование тома данных между контейнерами повреждает файлы сессий и хранилища памяти.

Куда попадают логи

Контейнер s6 имеет четыре различных поверхности логирования, и «почему мой шлюз ничего не показывает в docker logs» — это частый сюрприз. Шпаргалка:

Источник	Куда попадает	Как читать
Шлюз для каждого профиля (vibeos gateway run и шлюзы для каждого профиля под s6)	Направляется в два места: docker logs <container> (в реальном времени, без дополнительного префикса) и ${VIBEOS_HOME}/logs/gateways/<profile>/current (ротируемый, с меткой времени ISO-8601, 10 архивов × 1 МБ каждый)	docker logs -f vibeos или tail -F ~/.vibeos/logs/gateways/default/current на хосте
Панель управления (когда VIBEOS_DASHBOARD=1)	docker logs <container> (без префикса)	docker logs -f vibeos — перемежается со строками шлюза
Согласователь при загрузке (записывает, какие шлюзы профилей были восстановлены при каждом запуске контейнера)	${VIBEOS_HOME}/logs/container-boot.log (журнал аудита с добавлением)	tail -F ~/.vibeos/logs/container-boot.log
Общие логи VibeOS (agent.log, errors.log)	${VIBEOS_HOME}/logs/ (с учётом профиля)	docker exec vibeos vibeos logs --follow [--level WARNING] [--session <id>]

Два практических следствия, о которых стоит знать:

• Копия файла в logs/gateways/<profile>/current — это то, что переживает перезапуски контейнера. docker logs сохраняет вывод только за время жизни текущего контейнера (и очищается при docker rm); ротируемые файлы сохраняются на смонтированном томе.
• Строка аудита согласователя при загрузке имеет вид <iso-timestamp> profile=<name> prior_state=<state> action=<registered|started>, поэтому быстрый grep profile=coder ~/.vibeos/logs/container-boot.log покажет, когда данный профиль был последний раз восстановлен и был ли он автоматически запущен s6.

Пересылка переменных окружения

Ключи API читаются из /opt/data/.env внутри контейнера. Вы также можете передавать переменные окружения напрямую:

docker run -it --rm \
  -v ~/.vibeos:/opt/data \
  -e ANTHROPIC_API_KEY="sk-ant-..." \
  -e OPENAI_API_KEY="sk-..." \
  nousresearch/vibeos-agent

Прямые флаги -e переопределяют значения из .env. Это полезно для CI/CD или интеграций с менеджерами секретов, где вы не хотите хранить ключи на диске.

Ищете Docker как терминальный бэкенд?

Эта страница описывает запуск самого VibeOS внутри Docker. Если вы хотите, чтобы VibeOS выполнял вызовы terminal / execute_code агента внутри изолированного контейнера Docker (один долгоживущий контейнер, общий для процессов VibeOS — см. issue #20561), это отдельный блок конфигурации — terminal.backend: docker плюс terminal.docker_image, terminal.docker_volumes, terminal.docker_forward_env, terminal.docker_env, terminal.docker_run_as_host_user, terminal.docker_extra_args, terminal.docker_persist_across_processes и terminal.docker_orphan_reaper. См. Конфигурация → Docker Backend для полного набора, включая правила жизненного цикла контейнера.

Пример Docker Compose

Для постоянного развёртывания со шлюзом и панелью управления удобен docker-compose.yaml:

services:
  vibeos:
    image: nousresearch/vibeos-agent:latest
    container_name: vibeos
    restart: unless-stopped
    command: gateway run
    ports:
      - "8642:8642"   # API шлюза
      - "9119:9119"   # панель управления (доступна только при VIBEOS_DASHBOARD=1)
    volumes:
      - ~/.vibeos:/opt/data
    environment:
      - VIBEOS_DASHBOARD=1
      # Раскомментируйте для пересылки конкретных переменных окружения вместо использования файла .env:
      # - ANTHROPIC_API_KEY=${ANTHROPIC_API_KEY}
      # - OPENAI_API_KEY=${OPENAI_API_KEY}
      # - TELEGRAM_BOT_TOKEN=${TELEGRAM_BOT_TOKEN}
    deploy:
      resources:
        limits:
          memory: 4G
          cpus: "2.0"

Запустите с помощью docker compose up -d и просматривайте логи с помощью docker compose logs -f. Вывод контролируемого шлюза также направляется в ${VIBEOS_HOME}/logs/gateways/<profile>/current на томе — см. Куда попадают логи для полной карты маршрутизации.

Опционально: аудиомост для Linux Desktop

Голосовой режим в Docker требует двух отдельных вещей для работы: VibeOS должен иметь возможность зондировать аудиоустройства внутри контейнера, и контейнер должен иметь доступ к аудиосерверу вашего хоста. Настройка ниже охватывает аудио-«сантехнику» хоста для Linux Desktop, которые предоставляют совместимый с PulseAudio сокет, включая многие конфигурации PipeWire.

предупреждение

Это обходной путь для Linux Desktop, а не общая функция Docker Desktop. Он полезен, когда у вас уже есть работающее аудио на хосте и вы хотите использовать голосовой режим CLI внутри контейнера VibeOS. Если VibeOS по-прежнему сообщает