Self-hosted: развёртывание

Минимальные требования

Linux-хост с Docker и Docker Compose (v2, поддержка docker compose -f a.yml -f b.yml).
Публичное DNS-имя, указывающее на хост, и открытые порты 80/443, если TLS терминирует встроенный Caddy.
Исходящий доступ хоста в интернет — для образов и сертификатов Let’s Encrypt.
Для ИИ-воркеров: /var/run/docker.sock на том же хосте (его использует супервизор) и доступный LLM-эндпоинт с OpenAI-совместимым API (в конфигурации по умолчанию — LiteLLM).

Control plane не обновляет себя сам и не обращается к машинам: агенты сами подключаются к нему по WebSocket. Поэтому входящих портов на машинах открывать не нужно.

Стек docker compose

Эталонный стек лежит в deploy/docker/docker-compose.yml:

Сервис	Назначение
`control-plane`	Сервер: HTTP/WS API, аутентификация, чат, память, аудит; отдаёт SPA из `/app/dist`. Слушает `18181`.
`postgres`	Postgres 15. Используется, если включить `NYTHRONIX_STORAGE=postgres`; по умолчанию сервер хранит состояние в JSON-файлах тома `nythronix_state`.
`redis`	Объявлен в стеке; сервер подключает его через `NYTHRONIX_REDIS_URL` для временных токенов загрузки.
`minio` + `minio-init`	S3-совместимое хранилище бандлов релизов; bucket `nythronix-bundles` создаётся автоматически.
`supervisor`	Реконсайлер воркеров: единственный сервис с доступом к docker.sock, без входящих портов. Запускает и останавливает контейнеры воркеров по желаемому состоянию из control plane.

Первый запуск:

cd deploy/docker
cp .env.example .env
$EDITOR .env               # секреты, публичный URL, LLM
echo '{}' > llm-profiles.json
docker compose up --build -d

При каждом старте контейнера выполняется preflight (NYTHRONIX_REQUIRE_PREFLIGHT=true). Слабый pepper, отсутствующий публичный URL или http:// без NYTHRONIX_ALLOW_HTTP_FOR_STAGING=true держат контейнер в перезапуске, пока вы не исправите .env.

Проверка:

curl -fsS http://127.0.0.1:18181/api/healthz   # {"status":"ok"} — процесс жив
curl -fsS http://127.0.0.1:18181/api/readyz    # {"status":"ready"} — хранилище доступно, bootstrap выполнен

Ключевые переменные окружения

Переменная	Значение
`NYTHRONIX_MODE`	`self-hosted` (по умолчанию) или `saas`. В self-hosted доступны NX-эндпоинты и bootstrap администратора из env.
`NYTHRONIX_PUBLIC_URL`	Публичный адрес control plane (`https://cp.example.com`, без завершающего `/`). Должен точно совпадать с адресной строкой браузера: по нему проверяется `Origin` WebSocket-соединений, формируется канонический `/agent/ws` для агентов и URL для супервизора.
`NYTHRONIX_EXTRA_ORIGINS`	Дополнительные origin через запятую, например `https://app.cp.example.com`, если кабинет обслуживается с отдельного хоста.
`NYTHRONIX_PASSWORD_PEPPER`	Секрет для Argon2, минимум 32 символа. Потеря pepper делает все пароли непроверяемыми.
`NYTHRONIX_BOOTSTRAP_EMAIL`, `NYTHRONIX_BOOTSTRAP_PASSWORD`	Первый администратор; используются только на пустом хранилище.
`NYTHRONIX_RUNTIME_TOKEN`	Общий секрет control plane и супервизора. Не задан — runtime API отключён и воркеры не запускаются.
`LITELLM_BASE_URL`, `LITELLM_API_KEY`, `LITELLM_MODEL`	LLM по умолчанию для воркеров; читает супервизор, не control plane.
`NYX_LLM_PROFILES_FILE`, `NYX_POOL`, `NYX_WORKER_NETWORK`, `NYX_HUNG_GRACE_SECS`	Настройки супервизора: профили LLM по организациям, имя пула, изолированная сеть воркеров, порог «зависшего» воркера.
`NYTHRONIX_SMTP_URL`, `NYTHRONIX_SMTP_FROM`, `NYTHRONIX_BETA_NOTIFY_TO`	Исходящая почта для уведомлений о заявках на бету: `smtps://user%40example.com:pass@smtp.example.com:465` (неявный TLS) или `smtp://…:587` (STARTTLS). `@` в логине кодируйте как `%40`.
`NYTHRONIX_STORAGE`, `NYTHRONIX_DATABASE_URL`	`json` (по умолчанию) или `postgres` с DSN.
`NYTHRONIX_HOST_PORT`	Порт хоста для control plane, по умолчанию `18181`.

Полный список с описаниями — в deploy/docker/.env.example; nythronix-server config-show печатает итоговую конфигурацию, nythronix-server preflight --strict проверяет её до запуска.

TLS через Caddy или nginx

Самый короткий путь на свежем VPS — Caddy внутри того же стека с автоматическими сертификатами:

# в .env: NYTHRONIX_DOMAIN=cp.example.com, NYTHRONIX_PUBLIC_URL=https://cp.example.com
docker compose -f docker-compose.yml -f docker-compose.caddy.yml up --build -d

Overlay убирает публикацию порта 18181 на хосте — Caddy становится единственной точкой входа. Закройте прямой порт на файрволе.

Если у вас свой reverse proxy, используйте примеры deploy/caddy/Caddyfile или deploy/nginx/nythronix.conf. Прокси должен пропускать /api/* и /proxy/* (HTTP) и WebSocket-апгрейд для /agent/ws, /nx/ws, /ws/remote, /ws/nx, /ws/relay, /ws/control, а также передавать X-Forwarded-Proto. Caddy делает апгрейд прозрачно; для nginx нужны proxy_set_header Upgrade / Connection. Соединения агентов живут часами — увеличьте таймауты чтения и записи (в примерах 1–2 часа).

Первый администратор

На пустом хранилище сервер создаёт организацию default и оператора с ролью owner из NYTHRONIX_BOOTSTRAP_EMAIL / NYTHRONIX_BOOTSTRAP_PASSWORD. После первого успешного запуска эти переменные можно удалить — на непустом хранилище они игнорируются. В SaaS-режиме bootstrap не выполняется.

Дальнейшее управление операторами — в Администрировании.

Раздача /downloads

Сервер отдаёт как статику всё, что лежит в каталоге SPA. Чтобы раздавать установщик агента для Windows по адресу https://<cp>/downloads/<файл>, смонтируйте каталог в control-plane:

services:
  control-plane:
    volumes:
      - nythronix_state:/var/lib/nythronix
      - ./downloads:/app/dist/downloads:ro

Ссылка Скачать агента для Windows на странице входа и в разделе Агенты ведёт на /downloads/nythronix-agent-setup.exe — положите файл под этим именем. Сам установщик собирается скриптом scripts/build-agent-windows-installer.sh.

Обновления

Два независимых потока.

Control plane не обновляется сам. Пересоберите образ и перезапустите стек:

docker compose -f docker-compose.yml -f docker-compose.caddy.yml up --build -d

Порядок важен: control plane с runtime API должен подняться раньше супервизора и воркеров; супервизор повторяет попытки, поэтому короткая гонка на старте даёт лишь предупреждение в логе.

Агенты, NX-эндпоинты и CLI nx обновляются по каналу связи. Релиз собирается и подписывается на отдельной машине сборки (не на control plane), публикуется скриптом scripts/release.sh, а агенты с политикой auto получают предложение при следующем подключении, проверяют SHA-256 и подпись Ed25519 и перезапускаются в новый бинарник. Подробности — в разделах Администрирование и Модель безопасности.