Альтернативи Open WebUI для VPS: що обрати

Яка альтернатива Open WebUI підходить для VPS

Альтернативи Open WebUI майже завжди порівнюють на ноутбуці, де оперативна пам’ять дешева, а жоден сервіс не слухає публічну адресу. VPS змінює обидва факти, тому змінюється і рейтинг. Open WebUI залишається оптимальним вибором, щойно входить друга людина, оскільки він підтримує повноцінні облікові записи користувачів і панель адміністратора. Легші проєкти виграють, коли інтерфейс конкурує з моделлю за останній гігабайт оперативної пам’яті. Ціна цієї переваги — автентифікація: у них її немає.

Усе наведене нижче взято з документації відповідних проєктів, опрацьованої в August 2026. Чотири критерії — це саме ті аспекти, які стають важливими, коли сервер доступний з інтернету.

Чотири аспекти, які мають значення лише для публічної IP-адреси

• Пам’ять поруч із моделлю. Сервер моделі — найбільш ресурсоємний процес на сервері. Кожен мегабайт, який використовує інтерфейс, — це мегабайт, недоступний моделі.
• Автентифікація. Деякі з цих проєктів мають облікові записи користувачів і ролі. Інші припускають, що це єдиний застосунок на вашому ноутбуці, тому взагалі не мають входу.
• Віддалений inference. UI, який може підключатися лише до 127.0.0.1:11434, змушує розміщувати модель на тому самому сервері, що й інтерфейс.
• Підтримка. Один контейнер із файлом SQLite — це інше завдання, ніж шість контейнерів із MongoDB і vector database за ними.

Скільки оперативної пам’яті модель залишає для інтерфейсу

Інтерфейс не є найбільшим споживачем ресурсів на сервері. Ним є модель. Опублікований розмір завантаження визначає мінімальну потребу, оскільки ваги мають залишатися в пам’яті, поки модель формує відповіді. Фактичне споживання пам’яті вище за розмір завантаження після виділення кешу контексту.

[
  {
    "label": "llama3.2:3b",
    "download_gb": "2.0"
  },
  {
    "label": "qwen3:4b",
    "download_gb": "2.5"
  },
  {
    "label": "gemma3:4b",
    "download_gb": "3.3"
  },
  {
    "label": "qwen3:8b",
    "download_gb": "5.2"
  }
]

Це показники, які сторінки бібліотеки Ollama показували в August 2026. Це опубліковані розміри, а не результати вимірювань. На VPS із 4 GB qwen3:4b розміром 2.5 GB залишає менше ніж 1.5 GB для операційної системи та всього іншого. Кеш контексту додатково споживає пам’ять у міру зростання діалогу. qwen3:8b розміром 5.2 GB на цьому сервері взагалі не поміститься. Огляди ноутбуків ніколи не розглядають цю ситуацію. Саме тут chat-інтерфейс, який займає кілька сотень мегабайтів, визначає, чи запуститься модель. Якщо ви підбираєте сервер для моделі, яка значно перевищує ці теги, розрахунок для моделі 27B на VPS лише з CPU показує, як швидко інтерфейс перестає бути параметром, що визначає можливість запуску.

Вимірюйте фактичне споживання, а не довіряйте будь-яким цифрам в оглядах, зокрема наведеним тут. Запустіть docker stats --no-stream через годину реальної роботи, а не через одну хвилину після запуску контейнера, оскільки потрібна пам’ять виділяється під час першого використання.

Open WebUI: досі типовий вибір для кількох користувачів

Open WebUI запускається з одного образу та зберігає дані в одному томі.

docker run -d -p 127.0.0.1:3000:8080 -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main

Команда в README проєкту публікує -p 3000:8080, який прослуховує всі інтерфейси. Префікс 127.0.0.1: залишає сервіс доступним лише через loopback. На VPS цей префікс важливіший за будь-яку іншу частину рядка, оскільки Docker створює власні правила iptables, а опублікований порт ігнорує правила заборони ufw.

Відкрийте сторінку через тунель або проксі, описані нижче, а потім створіть перший обліковий запис. Цей обліковий запис стане адміністратором. Подальші реєстрації створюються з роллю pending, яка є задокументованим типовим значенням DEFAULT_USER_ROLE, тому сторонній користувач, який отримає доступ до сторінки, все одно не зможе використовувати вашу модель, доки адміністратор не схвалить його обліковий запис.

Open WebUI споживає більше пам’яті, ніж наведені нижче проєкти, оскільки має більше функцій. На власній сторінці проєкту щодо продуктивності Open WebUI названо компоненти, які потребують цієї пам’яті. Типовий рушій embedding завантажує модель sentence-transformers усередині контейнера. У документації зазначено, що для кожного worker process це потребує близько 500 MB. Налаштування RAG_EMBEDDING_ENGINE=ollama передає це завдання серверу моделей, який ви вже запустили. AUDIO_STT_ENGINE=webapi не дає завантажувати локальну модель speech-to-text. У SQLite, якщо DATABASE_POOL_SIZE не задано, пул використовує велике внутрішнє значення за замовчуванням, а кожне з’єднання створює власний page cache і memory map. Тому на невеликому сервері задайте DATABASE_POOL_SIZE=8 і DATABASE_SQLITE_PRAGMA_MMAP_SIZE=0. ENABLE_AUTOCOMPLETE_GENERATION=False припиняє надсилання запиту на completion до моделі, поки користувач ще вводить текст.

LibreChat: для кількох користувачів, зі стеком за ним

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

Інтерфейс доступний на порту 3080. LibreChat варто обрати, якщо вам потрібна система ідентифікації, а не лише форма входу: він підтримує вхід через LDAP і OAuth2 та містить панель адміністратора для керування користувачами й ролями. Ця можливість потребує стека.

[
  {
    "label": "OrionChat",
    "containers": 0,
    "notes": "static files, served by a web server you already run"
  },
  {
    "label": "Hollama",
    "containers": 1,
    "notes": "one container serving a browser app"
  },
  {
    "label": "Open WebUI",
    "containers": 1,
    "notes": "application and SQLite in one image"
  },
  {
    "label": "LibreChat",
    "containers": 6,
    "notes": "api, admin panel, MongoDB, Meilisearch, pgvector, RAG API"
  }
]

Файл compose за замовчуванням запускає 6 сервіси: api, admin panel, MongoDB, Meilisearch, pgvector, RAG API. Жоден із них не є моделлю. MongoDB і pgvector потребують окремої пам’яті, а на сервері з 4 GB це пам’ять, потрібна моделі.

Оновлення виконуються як операція git. Саме тут найчастіше припускаються помилок.

docker compose down
git pull
docker compose pull
docker compose up -d

git pull завершується конфліктом, якщо ви редагували відстежуваний docker-compose.yml, після чого оновлення застосовується лише частково. Зберігайте власні зміни у docker-compose.override.yml, який проєкт передбачає саме для цього, а секрети — у .env. Обидва файли не відстежуються, тому git pull їх не змінює.

Укажіть для LibreChat власний сервер моделей через custom endpoint у librechat.yaml.

endpoints:
  custom:
    - name: "Ollama"
      apiKey: "ollama"
      baseURL: "http://model-host:11434/v1/"
      models:
        default: ["llama3.2"]
        fetch: true
      titleConvo: true
      titleModel: "current_model"
      modelDisplayLabel: "Ollama"

Замініть model-host адресою сервера, на якому працює Ollama. Поле apiKey має бути присутнім, хоча Ollama ігнорує його значення, тому можна вказати будь-який заповнювач. Якщо LibreChat працює в Docker, а Ollama — на тому самому сервері, localhost усередині контейнера означає сам контейнер, тому замість нього використовуйте host.docker.internal.

Hollama та OrionChat: браузер виконує всю роботу

Hollama надає браузерний застосунок з одного невеликого контейнера. Чати зберігаються у сховищі браузера, а не на сервері.

docker run -d --restart unless-stopped -p 127.0.0.1:4173:4173 --name hollama ghcr.io/fmaclen/hollama:latest

У версії цієї команди з README використовується --rm. Цей параметр видаляє контейнер після його зупинки, тому після перезавантаження інтерфейс більше не запускається. За reverse proxy додайте -e VITE_ALLOWED_HOSTS='chat.example.com', оскільки image дозволяє лише host localhost. Для будь-якого іншого hostname він повертає помилку blocked-host замість застосунку.

OrionChat іде далі та взагалі не має серверного компонента. Клонуйте repository і надайте цю папку через web server, який уже запущено, або відкрийте index.html з диска. API keys зберігаються у localStorage браузера, історія чатів залишається у браузері, а застосунок видаляє найстаріші чати, коли їхня кількість перевищує 512.

Жоден із цих проєктів не має login, оскільки в них немає сервера, який міг би його перевіряти. На laptop цього достатньо. На VPS це означає, що сторінку не можна публікувати на 0.0.0.0. Є також важливий нюанс: model викликає браузер, а не сервер.

Саме цей факт визначає, де можна використовувати ці два проєкти. Браузер має напряму підключатися до Ollama, тому Ollama має слухати не лише loopback. Ollama не має жодної автентифікації. З цього випливають два правила для браузера. Сторінка, яку подано через HTTPS, не може викликати звичайний HTTP endpoint, а в консолі буде виведено Mixed Content: The page at 'https://chat.example.com/' was loaded over HTTPS, but requested an insecure resource 'http://203.0.113.10:11434/api/tags'. This request has been blocked.. Виклик до будь-якого іншого origin відхиляється з has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource, доки ви не дозволите цей origin.

Документований спосіб Ollama змінити будь-яке з цих налаштувань — створити override для systemd.

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"
Environment="OLLAMA_ORIGINS=https://chat.example.com"

sudo systemctl daemon-reload
sudo systemctl restart ollama
sudo ss -lntp | grep 11434

ss тепер має виводити 0.0.0.0:11434 там, де раніше виводило 127.0.0.1:11434. Виконуйте цю зміну лише тоді, коли доступ до порту вже контролює firewall або proxy з автентифікацією, оскільки відкритий 11434 — це відкритий model server, а mass scanners швидко знаходять новий публічний порт. Наведений нижче SSH tunnel повністю усуває цю проблему: сторінка працює з origin localhost, який Ollama дозволяє за замовчуванням, а порт не виходить за межі сервера.

Чи може кожен із них використовувати віддалену кінцеву точку Ollama або vLLM

Open WebUI може, причому підключення встановлюється на стороні сервера. OLLAMA_BASE_URL=http://model-host:11434 вказує його на Ollama. Для vLLM або будь-якого іншого OpenAI-сумісного сервера задайте OPENAI_API_BASE_URL=http://model-host:8000/v1 із непорожнім OPENAI_API_KEY і збережіть суфікс /v1, який є обов’язковим. OPENAI_API_BASE_URLS приймає кілька бекендів, розділених крапками з комою.

LibreChat може використовувати її через baseURL користувацької кінцевої точки, наведеної вище. Цей запит також виходить із сервера, тому правила для браузера не застосовуються. Той самий базовий URL і той самий ключ-заповнювач працюють і поза вікном чату. Цього достатньо, щоб підключити coding agent до моделі, яку ви вже розмістили.

Hollama та OrionChat можуть підключатися до будь-якої кінцевої точки, яку ви введете в їхніх налаштуваннях, але запит виходить із вашого браузера. Усе, що описано в попередньому розділі, стосується їх і більше нічого в цьому розділі.

Розділення інтерфейсу та моделі — найкорисніша перевага віддаленої кінцевої точки. Розмістіть інтерфейс на невеликому сервері, а модель — там, де достатньо оперативної пам’яті. Саме на цьому етапі слід вирішити, чи має Ollama або vLLM обробляти запити, оскільки за одночасної роботи кількох користувачів із моделлю вони поводяться дуже по-різному. Якщо сервера моделі ще немає, почніть із запуску Ollama на VPS, а для сервера лише з CPU перед вибором runner прочитайте порівняння Ollama з llama.cpp.

Не публікуйте chat UI без автентифікації на 0.0.0.0

На сторінці з hardening Open WebUI зазначено, що проєкт «призначений для приватних довірених мереж, як і інша self-hosted інфраструктура: бази даних, container registry та CI-сервери». Також там рекомендовано розміщувати його за VPN або reverse proxy з автентифікацією. Проєкт, у якому взагалі немає входу, потребує щонайменше такого самого захисту.

Перевірте, які служби прослуховують порти, перш ніж довіряти цій конфігурації.

sudo ss -lntp | grep -E ':(3000|3080|4173|11434)'

Рядок 127.0.0.1:3000 — це потрібний результат. Рядок 0.0.0.0:3000 означає, що ваш chat interface доступний у публічному інтернеті. На власному комп’ютері відповідь curl -sI http://YOUR.VPS.IP:3000 на HTTP/1.1 200 OK повідомляє те саме ще пряміше.

Вимкнення входу в Open WebUI за допомогою WEBUI_AUTH=False — це налаштування для одного користувача на комп’ютері, до якого ніхто інший не має доступу. Воно також не застосовується до інсталяції, у якій уже є облікові записи. У такому разі з’являється повідомлення You can't turn off authentication because there are existing users.

Варіант 1: прив’яжіть сервіс до loopback і підключайтеся через SSH. Публікуйте кожен порт на 127.0.0.1, а потрібний порт перенаправляйте за допомогою ssh -N -L 3000:127.0.0.1:3000 you@vps.example.com і відкривайте http://localhost:3000 на ноутбуці. Нічого не опубліковано, тому ніщо не можна просканувати. Для Hollama або OrionChat перенаправте порт моделі тією самою командою за допомогою -L 11434:127.0.0.1:11434 і залиште Ollama на loopback. Цей підхід настільки надійний, наскільки надійно налаштовано SSH, тому використовуйте його разом із SSH лише за ключами та посиленою конфігурацією sshd.

Варіант 2: reverse proxy, який виконує автентифікацію до того, як запит потрапить у застосунок. Залиште застосунок на loopback, передайте проксі порт 443 і розмістіть перед ним single sign-on. Traefik на основі міток Docker Compose разом з Authentik як identity provider надає кожному застосунку на сервері один вхід і один сертифікат. Якщо Open WebUI працює за TLS (transport layer security), встановіть WEBUI_SESSION_COOKIE_SECURE=true і WEBUI_SESSION_COOKIE_SAME_SITE=strict. Також зменште JWT_EXPIRES_IN, встановлене за замовчуванням на чотири тижні, оскільки в документації Open WebUI зазначено: без Redis вихід із системи не робить токен недійсним. Токен залишається придатним до завершення строку його дії.

Варіант 2 не захищає проєкти, які працюють лише в браузері. Проксі перед сторінкою не захищає endpoint моделі. Запит fetch із цієї сторінки до іншого hostname не передає cookie сесії. Тому authenticating proxy перед Ollama відповідає redirect на форму входу, і chat не працює. Або розмістіть endpoint моделі під тим самим hostname, що й сторінка, або використовуйте варіант 1.

Що обрати

Якщо сервіс використовуватимуть інші люди, запускайте Open WebUI. Він підтримує повноцінні облікові записи, а нові користувачі потрапляють до черги на затвердження. Його супроводжувачі також публікують рекомендації з hardening, яких можна дотримуватися. Якщо потрібні LDAP або панель адміністратора, запускайте LibreChat і за допомогою docker stats переконайтеся, що його шість сервісів разом із вашою моделлю справді відповідають доступним ресурсам, перш ніж покладатися на нього. Якщо це один користувач на невеликому сервері, де модель уже використовує більшу частину RAM, надавайте Hollama або OrionChat через SSH-тунель, а стан зберігайте в браузері. Неправильний варіант для VPS — опублікувати будь-який із них через 0.0.0.0 без автентифікації.

FAQ

Чи безпечно безпосередньо відкривати Open WebUI для доступу через публічну IP-адресу?

На сторінці з рекомендаціями щодо hardening Open WebUI описано як програмне забезпечення для приватних довірених мереж, так само як базу даних або CI-сервер. У ньому є повноцінні облікові записи: перший обліковий запис стає адміністратором, а наступні залишаються pending до схвалення. Тому Open WebUI значно безпечніший за інтерфейс без автентифікації. Водночас розміщуйте його за reverse proxy з TLS і, якщо можливо, використовуйте single sign-on. Опублікуйте порт контейнера як 127.0.0.1:3000:8080, щоб власні правила iptables Docker не відкрили його в інтернет без вашого відома.

Яка альтернатива Open WebUI використовує найменше RAM на VPS?

Браузерні варіанти — Hollama та OrionChat, оскільки застосунок працює на клієнті. Сервер надсилає лише статичні файли, а OrionChat взагалі не потребує контейнера застосунку. Open WebUI утримує в пам’яті процес Python, базу даних і, за замовчуванням, локальну embedding model. Для самої embedding model у документації вказано близько 500 MB на worker. Перевірте значення на власному сервері за допомогою docker stats --no-stream, оскільки вони змінюються залежно від увімкнених функцій.

Чи можуть ці chat UI використовувати сервер Ollama на іншому хості?

Open WebUI і LibreChat можуть, причому з’єднання встановлює їхній сервер, тому обмеження браузера не застосовуються. Для Open WebUI задайте OLLAMA_BASE_URL, а для LibreChat — baseURL у custom endpoint. Для vLLM або іншого OpenAI-compatible server використовуйте OPENAI_API_BASE_URL із суфіксом /v1 і непорожнім API key. Hollama та OrionChat також можуть підключатися до будь-якої адреси, але запит надходить із вашого браузера. Тому endpoint має бути доступний і з вашого браузера.

Чому мій browser chat UI не може підключитися до Ollama?

Майже всі випадки пояснюються двома причинами. За замовчуванням Ollama прив’язується до 127.0.0.1:11434, тому браузер на іншій машині не може підключитися до нього, доки не змінено OLLAMA_HOST. Крім того, Ollama приймає cross-origin запити лише з localhost. Тому сторінка, яку подає ваш домен, отримує відмову з помилкою No 'Access-Control-Allow-Origin' header is present on the requested resource, доки це джерело не буде додано до OLLAMA_ORIGINS. Якщо сторінка працює через HTTPS, а endpoint — через HTTP, браузер блокує запит як mixed content, перш ніж Ollama його побачить. Задайте обидві змінні у перевизначенні systemctl edit ollama.service або передайте порт через SSH — тоді проблема зникне.