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

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

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

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

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

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

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

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

[
  {
    "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 для операційної системи та всього іншого. Коли розмова зростає, кеш контексту також використовує пам’ять. Тому встановлене значення num_ctx впливає не лише на якість, а й на потребу в пам’яті. qwen3:8b розміром 5.2 GB на цьому сервері взагалі не запускається. Саме цього зазвичай не охоплюють огляди для ноутбуків. Інтерфейс чату, який використовує кількасот мегабайт, може визначити, чи запуститься модель. Якщо ви розраховуєте сервер для моделі, яка значно перевищує ці значення, розрахунок для моделі 27B на VPS лише з CPU показує, як швидко інтерфейс перестає бути визначальним фактором.

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

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 усередині контейнера. У документації вказано близько 500 MB на робочий процес. Параметр RAG_EMBEDDING_ENGINE=ollama передає це завдання серверу моделей, який ви вже запускаєте. Параметр AUDIO_STT_ENGINE=webapi не дає завантажувати локальну модель перетворення мовлення на текст. Для SQLite, якщо DATABASE_POOL_SIZE не задано, пул використовує велике внутрішнє значення за замовчуванням, а кожне підключення створює власний кеш сторінок і memory map. Тому на невеликому сервері задайте DATABASE_POOL_SIZE=8 і DATABASE_SQLITE_PRAGMA_MMAP_SIZE=0. Параметр ENABLE_AUTOCOMPLETE_GENERATION=False припиняє запити інтерфейсу до моделі щодо завершення, доки користувач ще вводить текст.

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', оскільки образ дозволяє лише хост localhost і на запит до будь-якого іншого імені хоста відповідає помилкою blocked-host замість застосунку.

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

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

Цей факт визначає, де можна використовувати ці два проєкти. Браузер має напряму підключатися до Ollama. Тому Ollama має слухати не лише loopback, а сам Ollama не має жодної автентифікації. Із цього випливають два правила для браузера. Сторінка, завантажена через HTTPS, не може звертатися до кінцевої точки зі звичайним HTTP, а консоль виводить 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.. Виклик до будь-якого іншого джерела буде відхилено з has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource, доки ви не дозволите це джерело.

Документований спосіб 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 означає відкритий сервер моделей, а масовані сканери швидко знаходять новий публічний порт. Наведений нижче SSH tunnel усуває цю проблему: сторінка працює з джерела localhost, яке Ollama дозволяє за замовчуванням, а порт не виходить за межі сервера.

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

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

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

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

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

Ніколи не публікуйте інтерфейс чату без автентифікації на 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 означає, що ваш інтерфейс чату доступний у публічному інтернеті. На власній машині відповідь 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, передайте reverse proxy керування портом 443 і розмістіть single sign-on перед застосунком. Traefik, налаштований через labels 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 не захищає проєкти, які працюють лише в браузері. Reverse proxy перед вебсторінкою не захищає endpoint моделі. Запит fetch із цієї сторінки до іншого hostname не передає cookie сесії. Тому reverse proxy з автентифікацією перед Ollama відповідає перенаправленням на форму входу, і чат не працює. Або розмістіть 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-сервер. Open WebUI має повноцінні облікові записи: перший обліковий запис стає адміністратором, а наступні залишаються pending, доки їх не буде схвалено. Тому Open WebUI значно безпечніший за інтерфейс без автентифікації. Проте все одно розміщуйте його за reverse proxy з TLS і, де можливо, використовуйте single sign-on. Публікуйте порт контейнера як 127.0.0.1:3000:8080, щоб власні правила iptables Docker не відкрили його в інтернет без вашого відома.

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

Найменше RAM використовують браузерні варіанти 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 сервера використовуйте OPENAI_API_BASE_URL із суфіксом /v1 і непорожнім API key. Hollama та OrionChat також можуть підключатися до будь-якого endpoint, але запит надходить із вашого браузера. Тому 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, доки цей origin не буде додано до OLLAMA_ORIGINS. Якщо сторінка працює через HTTPS, а endpoint — через HTTP, браузер блокує запит як mixed content ще до того, як Ollama його побачить. Задайте обидві змінні у override systemctl edit ollama.service або перенаправте порт через SSH — тоді проблема зникне.