Если увеличить масштаб интерфейса Open WebUI, сохранится ли он после перезапуска? А если изменить параметр в файле проекта, почему приложение иногда продолжает работать по-старому? Ответ зависит от того, где меняется настройка и что именно мы перезапускаем.
После первого входа и базовой настройки доступа у нас уже есть учётная запись и открывающийся интерфейс. Этого достаточно для проверки: подключённая языковая модель пока не требуется.
Найдём личные настройки и раздел Admin
Даже у единственного пользователя, который сам управляет сервером, есть личные и административные настройки. Откроем их через аватар профиля → Settings, как показано в руководстве Open WebUI.
Выберем место по тому, что хотим изменить:
| Что мы хотим изменить | Где это настраивается | Кого затронет изменение |
|---|---|---|
Масштаб интерфейса (UI Scale) для удобного чтения | Аватар профиля → Settings → Interface | Только вашу текущую учётную запись |
| Подключение к серверу моделей | Аватар профиля → Settings → Admin → Connections | Весь экземпляр Open WebUI |
| Параметры запуска контейнера и секретный ключ | Файлы проекта в вашей папке установки вне браузера | Процесс приложения при его создании и запуске |
Личная область доступна каждому зарегистрированному участнику, а раздел Admin видят только администраторы. Персональные переключатели работают в тех границах, которые разрешены на уровне сервера: если администратор отключил какую-то возможность для всего экземпляра, отдельный пользователь не включит её у себя в профиле.
Default Interface Settings работает иначе: задаёт исходные значения интерфейса, которые пользователь может изменить для себя. Место настройки определяет, кого она затронет; сохранение зависит от того, где приложение хранит её значение.
Отделим сохранённые значения от параметров запуска
В уроке про установку через Docker Compose мы передавали процессу параметры запуска из файлов проекта. Рабочие данные Open WebUI вынесли в постоянный том open-webui_open-webui, подключённый к каталогу /app/backend/data. Файлы запуска и сохранённые данные приложения решают разные задачи.
В стандартной установке курса база данных находится в каталоге данных и хранит сохраняемую конфигурацию приложения. Её поведение описано в справочнике переменных окружения Open WebUI, который указывает версию v0.12.1. По документации Docker, том существует независимо от контейнера.
В разговоре о сохранении настроек стоит различать три операции:
| Операция | Что происходит с контейнером и процессом | Откуда берётся значение UI Scale |
|---|---|---|
| Обновить вкладку в браузере | Контейнер продолжает работать без остановки | Загружается для вашего аккаунта с работающего сервера |
| Перезапустить существующий контейнер без правки файлов | Процесс внутри того же контейнера останавливается и запускается заново | Читается из сохранённых данных аккаунта |
| Пересоздать контейнер с подключением прежнего тома | Старый контейнер заменяется новым, но к нему монтируется прежнее хранилище | Читается из прежних данных аккаунта, если подключён тот же постоянный том |
Здесь примером служит масштаб интерфейса (UI Scale): документация прямо связывает его хранение с аккаунтом. У других личных параметров способ хранения может отличаться.
Разберём, почему новое env может оставить старое поведение
Если после правки переменной окружения в файле поведение Open WebUI осталось прежним, обычно нужно различить две независимые причины.
Новое значение должно попасть в окружение процесса
Правка файла на компьютере сама по себе не меняет окружение уже созданного контейнера. По справке Docker, команда docker compose restart перезапускает существующие контейнеры и не применяет изменения Compose, включая новые переменные окружения.
Если понадобится изменить конфигурацию запуска, вернитесь к разделу управления проектом в уроке про Docker Compose. Для нашей проверки достаточно существующего сервиса без правки файлов.
Для ConfigVar может действовать сохранённое значение
Даже новое окружение процесса не всегда определяет итоговое значение. По справочнику Open WebUI, в стандартном режиме ENABLE_PERSISTENT_CONFIG=True сохранённые в базе значения параметров с меткой ConfigVar имеют приоритет над переменными окружения. Обычные переменные без этой метки читаются при запуске процесса.
Например, ENABLE_SIGNUP отвечает за регистрацию новых пользователей и отмечена как ConfigVar. Если значение уже сохранено в базе, новая строка в файле окружения не обязана его перезаписывать. Когда такая настройка доступна в интерфейсе, штатное место её изменения — раздел Admin. Здесь это только пример: регистрацию оставим прежней.
Если ENABLE_PERSISTENT_CONFIG имеет значение False, правки в панели администратора могут действовать в текущем сеансе, но теряться после перезапуска. Этот режим оставим без изменений и проверим сохранение на личной настройке.
Проверим сохранение на UI Scale
По документации Open WebUI, UI Scale хранится с аккаунтом. Ожидаем, что выбранный масштаб сохранится после обновления вкладки. Проверим это в своём браузере, сохранив права доступа, секретный ключ и подключения прежними:
- Откроем свой сервер Open WebUI (для локальной установки из курса это
http://127.0.0.1:3000) и убедимся, что вошли в нужную учётную запись. - Нажмём на аватар профиля, перейдём в Settings → Interface и найдём параметр UI Scale (названия пунктов могут немного отличаться в зависимости от установленной версии).
- Запишем исходное значение, чтобы вернуть его после проверки.
- Умеренно изменим масштаб. Если в форме есть кнопка сохранения, нажмём её.
- Обновим вкладку браузера и снова откроем Settings → Interface.
Если выбранный масштаб вернулся к прежнему уже после обновления вкладки, перезапуск сервера здесь ни при чём: сначала стоит проверить, была ли нажата кнопка сохранения и не открыт ли другой адрес или аккаунт.
Если вы проходили установку через Docker Compose, можно дополнительно проверить, как та же настройка ведёт себя при перезапуске контейнера без изменения файлов проекта:
- Откроем тот же терминал, который использовали при установке: терминал Ubuntu в WSL2 для Windows, приложение «Терминал» в macOS или обычный терминал Ubuntu Linux.
- Перейдём в папку проекта:
- Перезапустим существующий сервис командой
docker compose restart(в Ubuntu Linux добавьте в началеsudo, если ранее работали с Docker черезsudo):
- Дождёмся, пока веб-интерфейс снова начнёт отвечать в браузере, и проверим значение UI Scale в том же аккаунте.
При другом способе установки можно ограничиться обновлением вкладки. Эта проверка показывает сохранение после обновления страницы, а не после перезапуска сервера.
Завершив наблюдение, вернём UI Scale к записанному исходному значению и сохраним форму. Поскольку масштаб интерфейса привязан к учётной записи, перезапуск контейнера с прежними данными не должен сбрасывать его к стартовому виду. Если в вашей среде настройка повела себя иначе, не нужно удалять том или сбрасывать базу данных: для будущей диагностики достаточно записать, после какого именно шага изменилось значение и какая версия образа используется.
Дальше подключим к Open WebUI языковую модель по одному из двух маршрутов: в уроке про подключение локальной Ollama или через подключение OpenAI-совместимого API.
