«Прокси-агент» — это один контейнер: внутри него и приложение, и интерфейс. Рядом обязательно нужна база PostgreSQL — она хранит модели, ключи, журналы, настройки и расходы. Ничего сверх этого не требуется, поэтому развернуть продукт можно на своём сервере за несколько минут.
Один контейнер и одна база
Контейнер обслуживает и страницы интерфейса, и адреса /api/*, к которым обращаются программы. База — внешняя: её можно поставить на том же сервере или на отдельном. При первом запуске база создаётся сама, если её ещё нет, — вручную ничего готовить не нужно. Эта база — единственная обязательная настройка: без неё приложение не стартует.
Два порта
- Основной порт — страницы интерфейса и адреса моделей. В примерах установки он публикуется как
5000:80— снаружи 5000, внутри 80. - Порт прокси-службы — по умолчанию 5001, для обычного трафика. У него свои правила: подпапка на него не влияет, и публиковать его стоит только тогда, когда он действительно нужен.
Размещение в подпапке
Если продукт должен жить не в корне домена, а в первой подпапке — например, по адресу ваш-домен/proxy, — есть два способа.
- Переменной окружения. Укажите
PROXYAGENT_BASE_PATH=/proxy— и всё внутри будет работать от этой папки. Обращения по неверному адресу продукт перенаправит сам, чтобы адрес был один и тот же, а не два разных. - Передним прокси. Прокси перед приложением сам снимает папку и передаёт продукту заголовок
X-Forwarded-Prefix. При этом продукт остаётся доступен и напрямую, по своему порту в корне домена, — это удобный путь для диагностики.
Три адреса в любом случае всегда живут в корне домена и подпапке не подчиняются: /api/ (к нему обращаются программы), проверка состояния и проверка сертификатов. Так задумано: клиенты указывают адрес от корня, и ломать это подпапкой нельзя.
HTTPS настраивается снаружи
Сам контейнер говорит только по простому HTTP. Защищённое соединение (HTTPS) настраивается перед ним — на переднем прокси или на стороне облака. Так проще менять сертификаты и не пересобирать продукт.
Что важно для переднего прокси
Передний прокси должен пропускать живые соединения (иначе чат сам перейдёт на менее удобный режим), не копить ответ в буфере и не обрывать длинные ответы. Практические значения: таймауты до 3600 секунд и предел размера запроса 100 мегабайт. Если этого не сделать, потоковые ответы моделей и чат будут рваться, а большие запросы — отклоняться.
Где лежат данные
Деловые данные — модели, ключи, журналы, расходы, настройки — живут в PostgreSQL и переживают что угодно, что бы ни случилось с контейнером. Остальное лежит во временной папке контейнера (/tmp/proxyagent):
- сохранённые «размышления» DeepSeek — без тома они пропадут, но восстановятся сами по мере работы;
- хранилище скрытия секретов — соответствия между секретами и обозначениями; без тома они потеряются, и старые обозначения перестанут возвращаться на место;
- ключ подписи сессий входа — без постоянного
JWT_SECRET_KEYили тома все выданные сессии входа перестанут работать после пересоздания контейнера, и всем придётся войти заново.
Вывод простой: к временной папке стоит подключить постоянный том, а ключ подписи задать переменной окружения. Тогда пересоздание контейнера проходит незаметно.
Резервные копии
Для полной копии достаточно двух вещей: обычного дампа PostgreSQL и постоянного тома состояния. В дампе — вся история и настройки, в томе — сохранённые соответствия секретов. Сами журналы живут в базе, поэтому дамп заодно сохраняет и их.
Дальше: как устроен доступ и что стоит сделать для безопасности — в разделе Доступ и безопасность.