Open WebUI против LibreChat: что выгоднее и когда

MAATRIX

Оба проекта дают своё окно чата поверх чужих и собственных моделей. Но выбор «Open WebUI или LibreChat» упирается не в галочки на лендинге, а в четыре скучные вещи: сколько контейнеров вы обязуетесь обслуживать, сколько памяти это съест в простое, кто хранит ключи пользователей и что написано в LICENSE.

Open WebUI или LibreChat: разница в одном абзаце

Open WebUI — приложение на Python (FastAPI) в одном контейнере, пишет всё в SQLite-файл webui.db внутри тома /app/backend/data. Внутрь встроено почти всё: RAG с локальными эмбеддингами, векторная база ChromaDB, менеджер моделей Ollama, инструменты и функции.

LibreChat — приложение на Node.js, разворачивается связкой контейнеров: сервис LibreChat, база chat-mongodb, поиск chat-meilisearch, а для файлов ещё rag_api и vectordb на pgvector. Поведение задают .env и librechat.yaml: конфиг-как-код, где провайдеры, лимиты и интерфейс лежат в репозитории, а не в кликах по админке.

Коротко: Open WebUI продаёт автономность и удобную админку, LibreChat — воспроизводимость и чистое разделение пользователей.

Развёртывание: что вводить до первого чата

У Open WebUI путь короче:

docker run -d --name open-webui \
  -p 127.0.0.1:3000:8080 \
  --add-host=host.docker.internal:host-gateway \
  -e WEBUI_SECRET_KEY="$(openssl rand -hex 32)" \
  -e OLLAMA_BASE_URL=http://host.docker.internal:11434 \
  -v open-webui:/app/backend/data \
  --restart unless-stopped \
  ghcr.io/open-webui/open-webui:v0.6.32

Тег берите актуальный со страницы релизов: они выходят почти еженедельно, и :main однажды приедет с миграцией базы, которой вы не ждали. Грабля, о которой узнают поздно: без явного WEBUI_SECRET_KEY ключ генерируется сам и ложится в /app/backend/data/.webui_secret_key — потеряли том, и вся команда разом вылетела из аккаунтов по недействительным JWT.

LibreChat ставится из репозитория — конфиг там часть установки:

git clone https://github.com/danny-avila/LibreChat.git
cd LibreChat && cp .env.example .env && cp librechat.example.yaml librechat.yaml
docker compose up -d

В .env обязательны четыре секрета, два — строго заданной длины:

JWT_SECRET=$(openssl rand -hex 32)
JWT_REFRESH_SECRET=$(openssl rand -hex 32)
CREDS_KEY=$(openssl rand -hex 32)   # ровно 64 hex-символа = 32 байта
CREDS_IV=$(openssl rand -hex 16)    # ровно 32 hex-символа = 16 байт

Это ключ и вектор AES-256, которыми LibreChat шифрует API-ключи пользователей. Ошиблись длиной — контейнер поднимется и интерфейс откроется, но при первой попытке сохранить ключ в docker logs -f LibreChat появится:

RangeError [ERR_CRYPTO_INVALID_KEYLEN]: Invalid key length
    at Cipheriv.createCipherWithIV (node:internal/crypto/cipher:120:19)

И второе: docker-compose.yml править нельзя, при git pull изменения затрутся — все правки идут в docker-compose.override.yml рядом. Порт сервиса — 3080, а не 3000 и не 8080.

Замер на одном VPS: память, диск, холодный старт

Оба стека поднимались на одинаковой машине: 2 vCPU / 4 ГБ / 40 ГБ NVMe, Ubuntu 24.04, Docker 27, Лондон, модели считаются снаружи. docker stats --no-stream в простое, через десять минут после первого входа:

NAME               CPU %   MEM USAGE / LIMIT
open-webui         0.42%   812MiB / 3.83GiB
# второй прогон, стек LibreChat:
LibreChat          0.31%   198MiB / 3.83GiB
chat-mongodb       0.60%   241MiB / 3.83GiB
chat-meilisearch   0.05%   96MiB / 3.83GiB
rag_api            0.20%   704MiB / 3.83GiB
vectordb           0.03%   38MiB / 3.83GiB

Вывод против интуиции: пять контейнеров LibreChat дают 1,27 ГБ, а один Open WebUI — 812 МБ. Уберите работу с файлами — останется 535 МБ, в минимальной комплектации LibreChat заметно легче. Причина: образ Open WebUI тащит torch и sentence-transformers, а модель эмбеддингов all-MiniLM-L6-v2 въезжает в память при первом обращении к базе знаний. Лечится двумя переменными:

-e RAG_EMBEDDING_ENGINE=openai \
-e RAG_EMBEDDING_MODEL=text-embedding-3-small

Локальная модель тогда не грузится, потребление падает до 400–450 МБ — Open WebUI из самого тяжёлого варианта превращается в самый лёгкий.

По диску картина обратная. Open WebUI — один образ около 4 ГБ. LibreChat целиком: api ~1,1 ГБ, mongo ~0,9 ГБ, meilisearch ~0,15 ГБ, pgvector ~0,45 ГБ, rag_api ~2,6 ГБ — итого ~5,2 ГБ, без файлового стека ~2,1 ГБ.

Холодный старт до ответа /health: Open WebUI — 12–15 секунд, на самом первом запуске 60–90; LibreChat — 20–25 секунд. Под нагрузкой PDF на сорок страниц уводит Open WebUI с 812 МБ до 1,4–1,6 ГБ, а у LibreChat нагружает только rag_api: тяжёлая работа не сидит в одном процессе с чатом.

Модели: Ollama, внешние API и свой шлюз

Здесь проекты расходятся сильнее всего. Open WebUI знает Ollama нативно: список подтягивается сам, а скачать или удалить модель можно из браузера — на машине без GPU, где вы перебираете квантования, это экономит десятки заходов по SSH. Связка разобрана в статье про локальный запуск LLM через Ollama, типовой отказ — в разборе, почему Open WebUI не видит Ollama.

LibreChat нативного драйвера не имеет и работает с Ollama как с любым OpenAI-совместимым провайдером, через блок custom в librechat.yaml. Обратите внимание на /v1/ в конце адреса: без него запросы уйдут в никуда.

version: 1.2.8
endpoints:
  custom:
    - name: "Ollama"
      apiKey: "ollama"
      baseURL: "http://host.docker.internal:11434/v1/"
      models:
        default: ["qwen2.5:7b", "llama3.2:3b"]
        fetch: true
      titleConvo: true

Значение version растёт с релизами — сверяйтесь с librechat.example.yaml из своего клона: при несовпадении LibreChat пишет предупреждение в лог и игнорирует часть настроек. Скачивать модели отсюда нельзя, ollama pull qwen2.5:7b выполняется руками на хосте.

С внешними провайдерами наоборот удобнее LibreChat: OpenAI, Anthropic, Google и любые совместимые эндпоинты описаны в одном файле вместе с лимитами, и он переезжает на новый сервер целиком. В Open WebUI подключения живут в базе, перенос настроек — это перенос тома. Вариант для обоих: поставить перед провайдерами свой шлюз и дать интерфейсу один адрес (сравнение LiteLLM и OpenRouter).

Пользователи, роли и чьи ключи

В одиночном режиме работают оба, Open WebUI умеет даже отключить авторизацию через WEBUI_AUTH=False. Разница начинается с третьего человека.

Open WebUI. Первый зарегистрировавшийся становится администратором, дальше регистрацию закрывают через ENABLE_SIGNUP=false либо ставят новичков в очередь через DEFAULT_USER_ROLE=pending. При pending новичок видит экран «Account Activation Pending», пока админ не переведёт его в user — это штатное поведение, а не баг. Права раздаются группами: какие модели видны, доступны ли инструменты и загрузка файлов. Всё мышью — удобно, но доступ живёт в базе и в git не попадает.

LibreChat. Регистрация выключается строкой ALLOW_REGISTRATION=false в .env, роли ADMIN и USER заданы явно, а видимость элементов интерфейса описана блоком interface в librechat.yaml и уезжает в git вместе с конфигом.

Главное отличие — во владении ключами. LibreChat умеет режим user_provided: сотрудник вводит свой ключ провайдера, тот шифруется AES из CREDS_KEY и лежит в Mongo при его учётке. Ваш сервер не платит за чужие токены и не видит ключи открытым текстом. Open WebUI даёт похожее через персональные подключения, но исторически построен вокруг общего пула ключей администратора — общий счёт и ручной подсчёт трат.

Честно про приватность: переписка лежит у вас — но как только в промпты попадают персональные данные российских граждан, база чатов становится хранилищем ПДн со всеми требованиями 152-ФЗ. Историю на диске не шифрует ни один из двух.

Три места, где выбор становится необратимым

Первое — лицензия. LibreChat под MIT: делайте что хотите, включая ребрендинг и перепродажу. Open WebUI с версии 0.6.6 сменил BSD-3-Clause на собственную Open WebUI License — тот же BSD-3 плюс пункт о защите брендинга: убирать или менять название и логотип «Open WebUI» нельзя, если развёртывание не укладывается в лимит порядка пятидесяти пользователей, вы не давний контрибьютор и не купили корпоративную лицензию. Код до 0.6.5 остаётся под BSD-3. На внутреннее использование это не влияет, но строите продукт под своим брендом — прочитайте LICENSE своего тега до того, как нарисуете логотип.

Второе — обратный прокси. Open WebUI использует socket.io, то есть настоящий WebSocket: без апгрейда соединения чат обновляется рывками, а ответ приходит одним куском в конце.

proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_buffering off;
proxy_read_timeout 600s;
client_max_body_size 100M;

LibreChat обходится обычным SSE, строки с Upgrade ему не нужны. А proxy_buffering off; и длинный proxy_read_timeout обязательны обоим: с буферизацией ответ копится в Nginx и вываливается целиком.

Третье — миграция между ними. Её нет. Оба экспортируют переписку в JSON, но форматы разные и импортёра чужого нет ни там, ни там: LibreChat читает выгрузки ChatGPT, Open WebUI — только свои chats.json. Историю за год вы не перенесёте, поэтому тестируйте оба в первую неделю.

Резюме. Open WebUI — если модели крутятся локально через Ollama, важна работа с документами из коробки, нужны один том и один бэкап, а пользователей до десятка. LibreChat — если пользователей много и у каждого свои ключи, нужен поиск по истории и ветвление диалогов, конфигурация должна лежать в git или поверх строится продукт под вашим брендом.

Какой сервер брать в MAATRIX

Разница в обслуживании честная: у Open WebUI бэкап — один tar по тому open-webui:/app/backend/data, у LibreChat всё снимается порознь — docker exec chat-mongodb mongodump --archive=/tmp/lc.gz --gzip --db LibreChat, плюс .env, librechat.yaml и том с файлами. Конфигурации ниже — для случая, когда модели работают снаружи, а сервер занят интерфейсом.

Честный минимум — 2 vCPU и 4 ГБ. На двух гигабайтах оба стека стартуют и первые дни выглядят живыми, но кончается одинаково: контейнер уходит в Restarting (137) — его убил OOM-killer при первой индексации файла.

Комфортный вариант — 4 vCPU, 8 ГБ, 60–80 ГБ NVMe. Помещается LibreChat целиком со всеми пятью контейнерами, остаётся запас на PostgreSQL вместо SQLite у Open WebUI. Диск считайте по файлам: векторный индекс занимает в разы больше исходников, а Mongo не отдаёт освободившееся место без compact. Планируете рядом Ollama — смотрите на модель: 8B в Q4 это около 4,7 ГБ весов целиком в памяти, и на процессоре без видеокарты они выдают 5–8 токенов в секунду.

Локация — Лондон. Оба проекта интерактивны: задержка чувствуется на каждом действии, а не только при генерации. Из Москвы до Лондона 45–60 мс против 110–130 мс до Нью-Йорка. Британский адрес спокойно принимают OpenAI, Anthropic и Google — отказ unsupported_country_region_territory не грозит, а соседство с GDPR-периметром упрощает разговор с европейскими контрагентами. Франция — равноценная альтернатива для ЕС, Нью-Йорк берут под сервисы, требующие американского IP, Россию — когда модели локальные, в промптах персональные данные и 152-ФЗ важнее пинга.

Оплата — картами российских банков, по СБП, криптовалютой или токеном MAAT; зарубежная карта не нужна даже для сервера в Лондоне. Связка Ollama и Open WebUI ставится из каталога приложений: установка по шагам — в статье как установить и настроить Open WebUI на VPS, второй вариант — в материале про LibreChat как единый интерфейс. Сомневаетесь — напишите, сколько будет пользователей и чьи ключи они используют.

Частые вопросы