Open WebUI в Docker запускается одной командой: контейнер публикует веб-интерфейс на выбранном порту, а чаты, пользователи и настройки лежат в томе, который переживает обновления. Поднять контейнер легко, сложнее сделать чат пригодным для компании: заранее надо решить, где лежат данные, кто входит и как обновляться без потери переписки. Материал рассчитан на небольшой отдел; многосерверные установки с балансировкой решаются другими средствами.
Контейнер и порт
Контейнер Open WebUI публикует интерфейс на порту сервера, хранит данные в отдельном томе и перезапускается вместе с сервером; от публикации в сеть до готового рабочего контура остаётся настроить доступы и порядок обновления.
Базовая команда из быстрого старта проекта задаёт имя контейнера, соответствие порта сервера порту приложения, том для данных, секретный ключ и политику автоматического перезапуска. Проект обновляется быстро, поэтому точную команду и имя образа копируйте из текущей документации Open WebUI: старая команда из статьи может устареть.
| Параметр запуска | Что делает |
|---|---|
| Порт вида 3000:8080 | Публикует интерфейс приложения на порту сервера, который вы выбираете сами |
| Том open-webui, подключённый к /app/backend/data | Хранит чаты, пользователей и настройки отдельно от контейнера |
| Переменная WEBUI_SECRET_KEY | Постоянный секретный ключ, без которого пересоздание контейнера разлогинивает всех |
| Политика always для перезапуска | Поднимает контейнер после перезагрузки сервера |
| Тег образа | Версия приложения; документация советует закреплять номер релиза, а main включает свежие сборки с возможными ломающими изменениями |
Модель к интерфейсу подключается отдельно. Чаще всего это локальный сервер моделей, о запуске которого в контейнере рассказывает статья Ollama в Docker: сервер, модель и хранение данных. В Open WebUI адрес этого сервера указывают в настройках соединений либо в переменной окружения контейнера; Ollama на том же сервере приложение, по документации, находит через адрес хоста host.docker.internal. Общий файл Docker Compose для двух контейнеров удобнее: оба поднимаются, останавливаются и обновляются вместе.
Общий взгляд на то, зачем компании такой чат, дан в материале Open WebUI: корпоративный чат поверх локальных моделей. Здесь разбирается только контейнерная сторона.
Хранение данных
Контейнер без подключённого тома теряет чаты, пользователей и настройки при пересоздании. Перед первым запуском убедитесь, что том назван и подключён к каталогу данных приложения.
После запуска полезно открыть журнал контейнера и убедиться, что приложение стартовало без ошибок: первые строки показывают, нашёлся ли сервер моделей и создалась ли база. Первая загрузка образа занимает время и место на диске: в основном образе много зависимостей, а облегчённый вариант с тегом slim рассчитан только на работу через API. Новички нередко запускают контейнер без тома, неделю им пользуются и узнают, что данные лежали внутри контейнера и пропали при первом обновлении. Внутри тома лежат база пользователей, история диалогов, загруженные файлы и векторные данные базы знаний. Эти данные принадлежат компании, и обращаться с ними нужно как с любой внутренней базой: резервные копии, ограниченный доступ, срок хранения.
- Резервная копия тома по расписанию с понятными именами файлов, а перед каждым обновлением внепланово.
- Хранение копий вне сервера: диск, который выходит из строя вместе с сервером, копией считать нельзя.
- Проверка восстановления: раз в квартал развернуть копию на тестовом контейнере и открыть чат.
- Размер тома под контролем: загруженные файлы растут быстро, а заполненный диск останавливает всё.
- Срок хранения переписки согласован с юристами, особенно если сотрудники вводят рабочие данные.
Отдельно решите, нужна ли история вообще. Для некоторых задач ответ приемлем без сохранения: тогда сотрудников просят удалять чувствительные диалоги, а администратор настраивает правила очистки. Правила обращения с данными в локальных контурах разобраны в статье локальный ИИ для конфиденциальных данных.
Первый вход и роли
Бывает, что администратор в спешке регистрируется под личной почтой, а потом выясняется, что передать права некому. Служебную учётную запись заведите заранее. Первый вход определяет, кто станет администратором: по документации проекта, первая учётная запись управляет пользователями и всеми общими настройками. Поэтому первым регистрируется ответственный сотрудник, и делать это нужно до публикации адреса в сети.
- Ограничьте регистрацию: переменная ENABLE_SIGNUP включает или выключает создание учётных записей, а роль по умолчанию pending оставляет новичка в ожидании до активации администратором.
- Различайте роли: администратор, обычный пользователь и ожидающий активации.
- Выдайте доступ к моделям и базам знаний группами, и персональные исключения остаются редкостью.
- Для повседневных вопросов используйте обычную учётную запись, а административную берите только для настроек.
- Раз в неделю просматривайте список пользователей и убирайте тех, кто ушёл из компании.
Секретный ключ приложения задайте один раз и сохраните: по документации, без постоянного ключа каждое пересоздание контейнера разлогинивает всех пользователей, а значит, так будет после каждого обновления. Ключ хранят в хранилище секретов, и в файле из репозитория ему делать нечего.
Кто в вашей компании будет пользоваться внутренним чатом?
Обновление образа
Обновление — регулярная работа, и разовым событием оно служит только на старте, поэтому закрепите ответственного и календарь. Проект выпускает обновления часто, и отставание на несколько версий превращается в проблемы безопасности и совместимости. Слепое автоматическое обновление опасно с другой стороны: новая версия иногда меняет интерфейс или формат данных, а откат контейнера, по документации, возврат базы данных к прежней схеме исключает.
- Сделайте резервную копию тома и запишите текущий тег образа; документация советует закреплять номер релиза, а тег main принимает любые свежие сборки.
- Прочитайте заметки к выпуску: изменения в данных и настройках перечислены там.
- Загрузите новый образ, остановите и удалите старый контейнер и создайте новый с тем же томом и теми же переменными, включая секретный ключ.
- Откройте интерфейс, войдите администратором и проверьте чаты, модели и базы знаний.
- При проблеме верните прежний образ и восстановите том из копии: одной заменой образа обойтись нельзя, если новая версия уже изменила базу.
Автоматические обновления через вспомогательные сервисы документация проекта тоже описывает, но предупреждает: релиз с ломающими изменениями или миграцией базы может сломать установку. Для рабочего чата выбирайте ручное обновление по расписанию в удобное окно после проверки на копии. Сторонний сервис обновления проверьте на поддержку: заброшенные проекты перестают работать с новыми версиями Docker.
Проверка входа
Отдельно проверьте ресурсы сервера: память и диск, ведь интерфейс работает рядом с моделью, и нехватка памяти выглядит как зависший чат. После каждого изменения (запуск, смена настроек, обновление) проходите короткий чек-лист: он ловит поломки раньше, чем их заметят сотрудники.
| Проверка | Как выполнить | Признак успеха |
|---|---|---|
| Доступность | Открыть адрес с рабочего компьютера и с телефона во внутренней сети | Страница входа загружается |
| Вход | Войти обычным пользователем и администратором | Сессия открывается, роли различаются |
| Модель | Отправить тестовый вопрос | Ответ приходит, модель названа верно |
| Данные | Открыть вчерашний диалог | История на месте |
| Закрытость | Открыть адрес снаружи сети | Доступа нет или он ограничен по плану |
Результаты проверки записывайте в журнал изменений рядом с версией образа: через полгода по нему видно, когда и что обновлялось, и поиск причины сбоя занимает минуты. Последняя строка важнее остальных: контейнер, случайно опубликованный в интернет без защиты, становится открытым чатом с вашими моделями и данными. Перед выходом за пределы офисной сети поставьте перед ним веб-сервер с шифрованием и ограничьте доступ по адресам или через VPN. Для подключения внутренних сервисов к чату по интерфейсу программ смотрите Open WebUI API: подключение внутренних сервисов.
Если вам нужен готовый внутренний чат с ролями, резервными копиями и регламентом обновлений, мы настраиваем его в рамках проектов по внедрению ИИ в компании. Начните с тестового стенда и одного отдела и переходите в рабочий контур, когда чек-лист проходит без замечаний.