Как установить Open WebUI на Ubuntu Server 24.04 и подключить несколько ИИ для сотрудников

Open WebUI — это веб-интерфейс для работы с разными моделями искусственного интеллекта через браузер. Его можно развернуть на своём сервере, подключить сторонние ИИ через API и дать доступ нескольким сотрудникам.

Такой вариант удобен для небольшой компании: сотрудники заходят в один общий интерфейс, выбирают нужную модель и работают с ИИ без установки отдельных программ на каждый компьютер.

Open WebUI на Ubuntu Server 24.04 можно развернуть как единый веб-интерфейс для работы сотрудников с разными моделями искусственного интеллекта. Сервис устанавливается через Docker Compose и позволяет подключать сторонние ИИ через API.

В этой инструкции разберём установку Open WebUI на чистый Ubuntu Server 24.04, создание администратора, подключение внешних API-провайдеров и настройку доступа для сотрудников. Ollama и локальные модели использовать не будем.

Что такое Open WebUI и зачем он нужен

Open WebUI — это удобная веб-панель для работы с ИИ-моделями. По смыслу это похоже на собственный внутренний чат с ИИ для компании.

Через Open WebUI можно:

• подключить разные ИИ-модели;
• создать пользователей для сотрудников;
• управлять доступом к моделям;
• хранить историю чатов;
• использовать единый интерфейс для всей команды;
• не передавать сотрудникам API-ключи напрямую.

Например, можно подключить OpenAI, OpenRouter или другой OpenAI-compatible API-провайдер. В итоге сотрудник открывает в браузере адрес локального сервера, авторизуется и работает с ИИ через Open WebUI.

Схема получается такая:

Сотрудник
  → Open WebUI на локальном сервере
    → сторонний API-провайдер ИИ
      → модель искусственного интеллекта

В этой инструкции мы не будем устанавливать Ollama и локальные модели. Это отдельный сценарий. Здесь рассматриваем именно подключение сторонних ИИ через API.

Что понадобится для установки

Для тестового стенда достаточно:

• чистый Ubuntu Server 24.04;
• доступ по SSH;
• пользователь с правами sudo;
• доступ в интернет с сервера;
• Docker;
• Docker Compose plugin.

Желательно заранее понимать, кто будет пользоваться системой: только администратор или несколько сотрудников. Если сотрудников несколько, лучше сразу включить режим, при котором новые пользователи не получают доступ автоматически, а ждут подтверждения администратора.

Подготовка Ubuntu Server 24.04 к установке Open WebUI. Установка Docker

Сначала обновим систему:

sudo apt update
sudo apt upgrade -y
sudo reboot

После перезагрузки снова подключаемся к серверу по SSH.

Устанавливаем необходимые пакеты:

sudo apt install -y ca-certificates curl gnupg lsb-release nano htop ufw openssl

Удаляем старые версии Docker, если они вдруг были установлены:

for pkg in docker.io docker-doc docker-compose docker-compose-v2 podman-docker containerd runc; do
  sudo apt remove -y $pkg
done

Добавляем ключ Docker:

sudo install -m 0755 -d /etc/apt/keyrings

sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc

sudo chmod a+r /etc/apt/keyrings/docker.asc

Добавляем официальный репозиторий Docker:

echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

Обновляем список пакетов:

sudo apt update

Устанавливаем Docker Engine и Docker Compose plugin:

sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Проверяем установку:

sudo docker --version

sudo docker compose version

sudo systemctl status docker

Можно также выполнить тестовый запуск контейнера:

sudo docker run hello-world

Если команда отработала без ошибок, Docker установлен правильно.

Подготовка папки для Open WebUI

Создадим отдельную папку для проекта:

sudo mkdir -p /opt/openwebui
cd /opt/openwebui

Сгенерируем секретный ключ для Open WebUI:

openssl rand -base64 32

Команда выдаст строку примерно такого вида:

abcDEF1234567890abcDEF1234567890abcDEF12=

Скопируйте этот ключ. Он понадобится в файле docker-compose.yml.

Создание docker-compose.yml

Создаём файл:

sudo nano /opt/openwebui/docker-compose.yml

Вставляем содержимое:

services:
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    restart: always
    ports:
      - "3000:8080"
    volumes:
      - open-webui:/app/backend/data
    environment:
      WEBUI_SECRET_KEY: "ВСТАВЬ_СЮДА_СВОЙ_СЕКРЕТНЫЙ_КЛЮЧ"
      DEFAULT_USER_ROLE: "pending"
      ENABLE_PASSWORD_VALIDATION: "true"
      PASSWORD_VALIDATION_REGEX_PATTERN: "^(?=.*[a-z])(?=.*[A-Z])(?=.*\\d)(?=.*[^\\w\\s]).{8,}$"
      PASSWORD_VALIDATION_HINT: "Минимум 8 символов: большая буква, маленькая буква, цифра и спецсимвол."

volumes:
  open-webui:

В строке:

WEBUI_SECRET_KEY: "ВСТАВЬ_СЮДА_СВОЙ_СЕКРЕТНЫЙ_КЛЮЧ"

нужно вставить ключ, который был получен командой:

openssl rand -base64 32

Обратите внимание: в этом варианте переменные окружения записаны через двоеточие и в кавычках:

ПЕРЕМЕННАЯ: "значение"

Такой формат удобнее, потому что YAML не ломается из-за двоеточий, русских символов или специальных символов в строках.

Сохраняем файл в nano:

Ctrl + O
Enter
Ctrl + X

Перед запуском проверим файл:

cd /opt/openwebui
sudo docker compose config

Если ошибок нет, можно запускать.

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

Запускаем контейнер:

cd /opt/openwebui
sudo docker compose up -d

Проверяем, что контейнер запущен:

sudo docker ps

В списке должен быть контейнер:

open-webui

Посмотреть логи можно командой:

sudo docker logs -f open-webui

Теперь откройте Open WebUI в браузере:

http://IP_ВАШЕГО_СЕРВЕРА:3000

Например:

http://192.168.1.50:3000

IP-адрес сервера можно посмотреть командой:

ip a

Ищите адрес вида 192.168.x.x, 10.x.x.x или другой адрес вашей локальной сети.

Если страница не открывается

Проверьте, запущен ли контейнер:

sudo docker ps

Проверьте логи:

sudo docker logs -f open-webui

Если на сервере включён firewall, разрешите порт 3000:

sudo ufw allow 3000/tcp

Проверить статус firewall:

sudo ufw status

Если Open WebUI должен быть доступен только из локальной сети, лучше ограничить доступ по подсети. Например:

sudo ufw allow from 192.168.0.0/16 to any port 3000 proto tcp

Не рекомендуется открывать Open WebUI напрямую в интернет без HTTPS, обратного прокси и нормальной настройки доступа.

Создание администратора

После первого открытия Open WebUI нужно создать первый аккаунт.

Первый пользователь обычно становится администратором. Поэтому сначала регистрируйте именно свой основной аккаунт администратора, а уже потом сотрудников.

После входа проверьте, что доступна админка:

Admin Panel

Если админка открывается, значит аккаунт администратора создан корректно.

Подключение сторонних ИИ через API

Так как в этой инструкции мы не используем локальные модели, нужно подключить внешний API-провайдер.

Например, можно использовать:

• OpenAI API;
• OpenRouter;
• другой OpenAI-compatible API;
• корпоративный API-шлюз;
• LiteLLM, если нужно объединить несколько провайдеров в одном месте.

В Open WebUI перейдите:

Admin Panel → Settings → Connections

Далее добавьте подключение к API-провайдеру.

Для OpenAI-compatible API обычно указываются два основных параметра:

API Base URL
API Key

Пример для OpenAI:

API Base URL:
https://api.openai.com/v1

API Key:
ваш_api_ключ

Пример для OpenRouter:

API Base URL:
https://openrouter.ai/api/v1

API Key:
ваш_api_ключ_openrouter

После сохранения подключения в Open WebUI должны появиться доступные модели.

Проверить работу можно простым запросом в новом чате:

Напиши короткое описание услуги IT-аутсорсинга для малого бизнеса.

Если модель отвечает, значит подключение работает.

Почему удобно подключать ИИ через Open WebUI

Если сотрудники работают напрямую с разными ИИ-сервисами, быстро появляются проблемы:

• у каждого свой аккаунт;
• сложно контролировать доступ;
• API-ключи могут попасть не туда;
• неудобно менять провайдера;
• нет единого интерфейса для команды.

Open WebUI решает эту задачу как единая внутренняя точка доступа.

Сотрудник заходит в Open WebUI, а администратор уже решает, какие модели ему доступны и через какого провайдера идут запросы.

Настройка доступа для сотрудников

В нашем docker-compose.yml указана переменная:

DEFAULT_USER_ROLE: "pending"

Это значит, что новые пользователи после регистрации не получают доступ автоматически. Они попадают в ожидание подтверждения.

Это правильный вариант для компании.

Порядок работы такой:

1. Сотрудник открывает Open WebUI.
2. Регистрирует аккаунт.
3. Аккаунт попадает в статус ожидания.
4. Администратор заходит в Admin Panel.
5. Администратор подтверждает пользователя.
6. Пользователь получает доступ к Open WebUI.

Не стоит выдавать сотрудникам роль администратора. Для обычной работы достаточно роли пользователя.

Если в Open WebUI используются группы и права доступа к моделям, можно сделать отдельную группу, например:

Сотрудники

И уже этой группе разрешить только нужные модели.

Что важно учесть по безопасности

Open WebUI не стоит открывать в интернет «как есть». Минимальный безопасный вариант:

• доступ только из локальной сети или через VPN;
• сложные пароли;
• новые пользователи только через ручное подтверждение;
• API-ключи не выдавать сотрудникам напрямую;
• не давать сотрудникам права администратора;
• регулярно обновлять контейнер.

Если нужен внешний доступ, лучше использовать Nginx как обратный прокси и выпустить SSL-сертификат. Но для тестового локального стенда достаточно доступа по локальному IP или через VPN.

Полезные команды для обслуживания

Посмотреть запущенные контейнеры:

sudo docker ps

Посмотреть логи Open WebUI:

sudo docker logs -f open-webui

Остановить Open WebUI:

cd /opt/openwebui
sudo docker compose down

Запустить Open WebUI:

cd /opt/openwebui
sudo docker compose up -d

Перезапустить:

cd /opt/openwebui
sudo docker compose restart

Обновить Open WebUI:

cd /opt/openwebui
sudo docker compose pull
sudo docker compose up -d

Посмотреть итоговую конфигурацию Docker Compose:

cd /opt/openwebui
sudo docker compose config

Эта команда полезна, если Open WebUI не запускается из-за ошибки в docker-compose.yml.

Частая ошибка: unexpected type map[string]interface

Иногда при запуске можно увидеть ошибку вида:

services.open-webui.environment.[4]: unexpected type map[string]interface {}

Чаще всего причина в неправильном формате переменных окружения в docker-compose.yml.

Например, если написать так:

environment:
  - PASSWORD_VALIDATION_HINT=Минимум 8 символов: большая буква, маленькая буква, цифра и спецсимвол.

YAML может неправильно обработать двоеточие в русском тексте.

Чтобы избежать этой проблемы, лучше писать переменные окружения так:

environment:
  PASSWORD_VALIDATION_HINT: "Минимум 8 символов: большая буква, маленькая буква, цифра и спецсимвол."

То есть через двоеточие и в кавычках.

Нужно ли ставить Ollama

Для этой инструкции — нет.

Ollama нужна, если вы хотите запускать локальные модели прямо на своём сервере. Например, Llama, Qwen или Mistral. Но для этого желательно иметь достаточно мощное железо, а лучше видеокарту.

Если задача — дать сотрудникам доступ к сторонним ИИ через API, Ollama не нужна.

Правильная схема для такого варианта:

Сотрудник
  → Open WebUI
    → внешний API-провайдер
      → ИИ-модель

А не такая:

Сотрудник
  → Open WebUI
    → Ollama
      → локальная модель

Для начала лучше запустить Open WebUI без Ollama, подключить один внешний API и проверить работу сотрудников.

Итог

Open WebUI удобно использовать как внутренний интерфейс для работы с разными ИИ-моделями. Его можно быстро развернуть на Ubuntu Server 24.04 через Docker Compose, подключить сторонние API-провайдеры и выдать доступ сотрудникам.

Для тестового стенда достаточно:

Ubuntu Server 24.04
Docker
Open WebUI
сторонний API-провайдер ИИ
несколько пользователей

Такой вариант не требует мощного сервера, потому что сами ИИ-модели работают на стороне API-провайдера. Локальный сервер в этом случае отвечает за веб-интерфейс, пользователей, настройки и историю чатов.

Если в дальнейшем понадобится больше контроля, можно добавить Nginx, HTTPS, VPN-доступ, группы пользователей, ограничения по моделям и отдельный API-шлюз вроде LiteLLM.