Alternatywy dla Open WebUI na VPS - porównanie

Która alternatywa dla Open WebUI jest odpowiednia na VPS

Alternatywy dla Open WebUI są niemal zawsze porównywane w kontekście laptopa, gdzie pamięć RAM jest tania, a żadna usługa nie nasłuchuje na publicznym adresie IP. VPS zmienia oba te założenia, co wpływa na ranking. Open WebUI pozostaje domyślnym wyborem, gdy z systemu korzysta więcej niż jedna osoba, ponieważ oferuje obsługę kont użytkowników oraz panel administratora. Lżejsze projekty zyskują przewagę, gdy interfejs rywalizuje z modelem o ostatni gigabajt pamięci RAM. Ceną tego zwycięstwa jest brak uwierzytelniania: projekty te go nie posiadają.

Poniższe informacje pochodzą z dokumentacji poszczególnych projektów, stan na sierpień 2026. Cztery kryteria oceny dotyczą aspektów, które stają się istotne dopiero wtedy, gdy serwer jest dostępny z poziomu Internetu.

Cztery kluczowe aspekty przy wystawianiu usługi na publiczny adres IP

• Pamięć operacyjna dostępna dla modelu. Serwer modelu jest najbardziej zasobożernym procesem na serwerze. Każdy megabajt zajęty przez interfejs to megabajt, którego nie może wykorzystać model.
• Uwierzytelnianie. Niektóre projekty posiadają systemy kont użytkowników i ról. Inne zakładają, że działają lokalnie na laptopie i nie oferują żadnego mechanizmu logowania.
• Zdalna inferencja. Interfejs, który może łączyć się tylko z 127.0.0.1:11434, wymusza uruchomienie modelu na tej samej maszynie, co interfejs użytkownika.
• Utrzymanie. Pojedynczy kontener z plikiem SQLite to znacznie prostsze zadanie niż zarządzanie sześcioma kontenerami z MongoDB i bazą wektorową w tle.

Ile pamięci RAM model pozostawia dla interfejsu

Interfejs nie jest najbardziej zasobożernym elementem na serwerze. Jest nim sam model. Publikowane rozmiary plików do pobrania określają jedynie wartość minimalną, ponieważ wagi muszą znajdować się w pamięci operacyjnej podczas generowania odpowiedzi, a rzeczywiste zużycie pamięci jest wyższe niż rozmiar pliku po przydzieleniu pamięci podręcznej kontekstu.

[
  {
    "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"
  }
]

Są to wartości podane na stronach biblioteki Ollama w sierpniu 2026 roku. Są to rozmiary publikowane, a nie zmierzone. Na serwerze VPS z 4 GB pamięci RAM, qwen3:4b o rozmiarze 2.5 GB pozostawia mniej niż 1.5 GB dla systemu operacyjnego i pozostałych procesów, a pamięć podręczna kontekstu uszczupla ten zasób w miarę rozwoju konwersacji. Model qwen3:8b o rozmiarze 5.2 GB w ogóle nie zmieści się na takiej maszynie. Jest to sytuacja, której zestawienia dla laptopów nigdy nie uwzględniają i to właśnie tutaj interfejs czatu zajmujący kilkaset megabajtów decyduje o tym, czy model w ogóle zadziała. Jeśli dobierasz parametry serwera dla modelu znacznie większego niż te wskazane, obliczenia dla modelu 27B na serwerze VPS działającym wyłącznie na CPU pokazują, jak szybko interfejs przestaje być wartością decydującą o czymkolwiek.

Należy mierzyć, zamiast ufać jakiejkolwiek liczbie w zestawieniu, w tym również tej. Uruchom docker stats --no-stream po godzinie rzeczywistego użytkowania, a nie minutę po starcie kontenera, ponieważ pamięć, która ma znaczenie, jest przydzielana przy pierwszym użyciu.

Open WebUI: nadal domyślne rozwiązanie dla wielu użytkowników

Open WebUI uruchamia się z jednego obrazu i przechowuje dane w jednym wolumenie.

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

Polecenie zawarte w pliku README projektu publikuje -p 3000:8080, co powoduje nasłuchiwanie na wszystkich interfejsach. Prefiks 127.0.0.1: ogranicza działanie do interfejsu loopback. Na serwerze VPS ten prefiks jest ważniejszy niż jakikolwiek inny element wiersza, ponieważ Docker tworzy własne reguły iptables, a opublikowany port ignoruje reguły deny w ufw.

Uzyskaj dostęp do strony przez tunel lub proxy (oba rozwiązania opisano poniżej), a następnie utwórz pierwsze konto. To konto staje się administratorem. Kolejne rejestracje tworzone są z rolą pending, co stanowi udokumentowane ustawienie domyślne DEFAULT_USER_ROLE. Dzięki temu osoba niepowołana, która uzyska dostęp do strony, nie może korzystać z modelu, dopóki administrator nie zatwierdzi jej konta.

Open WebUI zużywa więcej pamięci niż wymienione poniżej projekty, ponieważ oferuje szerszą funkcjonalność, a wbudowana strona wydajności wskazuje elementy generujące największe obciążenie. Domyślny silnik osadzeń (embedding engine) ładuje model sentence-transformers wewnątrz kontenera, co według dokumentacji wymaga około 500 MB na proces roboczy. Ustawienie RAG_EMBEDDING_ENGINE=ollama przekazuje to zadanie do serwera modelu, który już działa. AUDIO_STT_ENGINE=webapi pozwala uniknąć ładowania lokalnego modelu zamiany mowy na tekst. W przypadku SQLite, gdy DATABASE_POOL_SIZE nie jest ustawione, pula wraca do dużego rozmiaru wewnętrznego, a każde połączenie zwiększa własną pamięć podręczną stron i mapę pamięci. Dlatego na małych jednostkach należy ustawić DATABASE_POOL_SIZE=8 oraz DATABASE_SQLITE_PRAGMA_MMAP_SIZE=0. ENABLE_AUTOCOMPLETE_GENERATION=False zapobiega wysyłaniu przez interfejs zapytań o uzupełnienie do modelu w trakcie, gdy użytkownik jeszcze pisze.

LibreChat: obsługa wielu użytkowników i stos technologiczny

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

Interfejs nasłuchuje na porcie 3080. LibreChat jest rozwiązaniem, które należy rozważyć, gdy wymagany jest system tożsamości, a nie tylko proste okno logowania: dokumentacja obejmuje logowanie przez LDAP i OAuth2, a wbudowany panel administracyjny pozwala zarządzać użytkownikami i rolami. Ta funkcjonalność wymaga wdrożenia całego stosu.

[
  {
    "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"
  }
]

Domyślny plik compose uruchamia 6 usług: api, admin panel, MongoDB, Meilisearch, pgvector, RAG API. Żadna z nich nie jest modelem. MongoDB oraz pgvector wymagają własnych zasobów pamięci, co na serwerze z 4 GB RAM ogranicza pamięć dostępną dla modelu.

Aktualizacje wykonuje się za pomocą operacji git, co jest elementem często wykonywanym nieprawidłowo.

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

git pull kończy się błędem konfliktu, jeśli edytowano śledzony plik docker-compose.yml, co prowadzi do częściowego zastosowania aktualizacji. Własne zmiany należy umieszczać w pliku docker-compose.override.yml, który jest do tego przeznaczony, a dane uwierzytelniające w .env. Oba pliki nie są śledzone, więc git pull pomija je podczas aktualizacji.

Skieruj LibreChat na własny serwer modelu, definiując niestandardowy punkt końcowy w 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"

Zastąp model-host adresem serwera, na którym działa Ollama. Pole apiKey musi być obecne, nawet jeśli Ollama ignoruje jego wartość, więc można w nim wpisać dowolny ciąg znaków. Jeśli LibreChat działa w Dockerze, a Ollama na tej samej maszynie, localhost wewnątrz kontenera odnosi się do samego kontenera, dlatego należy użyć host.docker.internal.

Hollama i OrionChat: przeglądarka wykonuje pracę

Hollama udostępnia aplikację przeglądarkową z jednego małego kontenera. Czaty są przechowywane w pamięci przeglądarki, a nie na serwerze.

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

Wersja tego polecenia z pliku README używa --rm, co powoduje usunięcie kontenera po jego zatrzymaniu, przez co interfejs nie powraca po restarcie. W przypadku działania za reverse proxy należy dodać -e VITE_ALLOWED_HOSTS='chat.example.com', ponieważ obraz zezwala wyłącznie na host localhost i w odpowiedzi na żądanie dla każdej innej nazwy hosta zwraca błąd zablokowanego hosta zamiast aplikacji.

OrionChat idzie o krok dalej i nie posiada żadnego komponentu serwerowego. Należy sklonować repozytorium i udostępnić folder za pomocą już działającego serwera WWW lub otworzyć index.html z dysku. Klucze API są przechowywane w localStorage przeglądarki, historia czatów pozostaje w przeglądarce, a aplikacja usuwa najstarsze czaty po przekroczeniu liczby 512.

Żaden z tych projektów nie posiada logowania, ponieważ żaden nie dysponuje serwerem, który mógłby je zweryfikować. Na laptopie jest to dopuszczalne. Na VPS oznacza to, że strona nigdy nie może zostać opublikowana w 0.0.0.0, co wiąże się z faktem, który łatwo przeoczyć: to przeglądarka wywołuje model, a nie serwer.

Ten jeden fakt decyduje o tym, gdzie te dwa rozwiązania mają zastosowanie. Przeglądarka musi mieć bezpośredni dostęp do Ollama, więc Ollama musi nasłuchiwać na interfejsie innym niż loopback, a Ollama nie posiada żadnego mechanizmu uwierzytelniania. Wynikają z tego dwie zasady dotyczące przeglądarek. Strona serwowana przez HTTPS nie może wywołać zwykłego punktu końcowego HTTP, a konsola wyświetla 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.. Wywołanie do dowolnego innego źródła jest odrzucane z błędem has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource, dopóki nie zezwolisz na to źródło.

Udokumentowanym sposobem Ollama na zmianę tych ustawień jest nadpisanie konfiguracji 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 powinno teraz wyświetlać 0.0.0.0:11434 w miejscu, gdzie wcześniej wyświetlało 127.0.0.1:11434. Zmianę tę należy wprowadzać tylko wtedy, gdy firewall lub uwierzytelniające proxy kontroluje już dostęp do portu, ponieważ otwarty port 11434 oznacza otwarty serwer modelu, a masowe skanery szybko wykrywają każdy nowy publiczny port. Poniższy tunel SSH pozwala uniknąć tego problemu: strona działa wtedy w źródle localhost, na co Ollama zezwala domyślnie, a port nigdy nie opuszcza maszyny.

Czy każda z nich może korzystać ze zdalnego punktu końcowego Ollama lub vLLM

Open WebUI może, a połączenie jest nawiązywane po stronie serwera. OLLAMA_BASE_URL=http://model-host:11434 wskazuje na Ollama. W przypadku vLLM lub dowolnego innego serwera zgodnego z OpenAI, należy ustawić OPENAI_API_BASE_URL=http://model-host:8000/v1 z niepustym OPENAI_API_KEY i zachować przyrostek /v1, który jest wymagany. OPENAI_API_BASE_URLS akceptuje kilka backendów rozdzielonych średnikami.

LibreChat może to robić poprzez baseURL niestandardowego punktu końcowego pokazanego powyżej. To żądanie również wychodzi z serwera, więc nie mają tu zastosowania żadne reguły przeglądarki. Ten sam bazowy adres URL i ten sam klucz zastępczy działają również poza oknem czatu, co jest wszystkim, czego potrzeba, aby skierować agenta programistycznego na model już hostowany.

Hollama i OrionChat mogą wskazywać na dowolny punkt końcowy wpisany w ich ustawieniach, ale żądanie opuszcza przeglądarkę. Wszystko z powyższej sekcji ma zastosowanie do nich i do niczego innego w tym miejscu.

Oddzielenie interfejsu od modelu to największa korzyść, jaką daje zdalny punkt końcowy. Umieść interfejs na małej jednostce, a model tam, gdzie jest pamięć. To również moment na decyzję czy to Ollama, czy vLLM powinny obsługiwać żądania, ponieważ oba rozwiązania zachowują się bardzo różnie, gdy kilka osób rozmawia z modelem jednocześnie. Jeśli serwer modelu jeszcze nie istnieje, zacznij od uruchomienia Ollama na VPS, a w przypadku jednostki z samym CPU przeczytaj jak Ollama wypada w porównaniu z llama.cpp przed wyborem środowiska uruchomieniowego.

Nigdy nie udostępniaj interfejsu czatu bez logowania na 0.0.0.0

Strona dotycząca zabezpieczeń Open WebUI informuje, że projekt jest „stworzony z myślą o prywatnych, zaufanych sieciach, podobnie jak inna infrastruktura self-hosted, taka jak bazy danych, rejestry kontenerów czy serwery CI”. Zaleca się umieszczenie go za VPN lub za reverse proxy z uwierzytelnianiem. Projekt pozbawiony mechanizmu logowania wymaga co najmniej takiego samego traktowania.

Sprawdź, co nasłuchuje na portach, zanim zaczniesz ufać konfiguracji.

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

Wiersz o treści 127.0.0.1:3000 oznacza pożądany stan. Wiersz o treści 0.0.0.0:3000 oznacza, że interfejs czatu jest dostępny w publicznym Internecie. Z poziomu własnej maszyny polecenie curl -sI http://YOUR.VPS.IP:3000 zwracające HTTP/1.1 200 OK komunikuje to samo w sposób bardziej bezpośredni.

Wyłączenie logowania w Open WebUI za pomocą WEBUI_AUTH=False to ustawienie dla jednego użytkownika na maszynie, do której nikt inny nie ma dostępu. Ustawienie to nie zadziała w instalacji, w której istnieją już konta, co skutkuje komunikatem You can't turn off authentication because there are existing users..

Wzorzec pierwszy: powiązanie z interfejsem loopback i dostęp przez SSH. Udostępnij porty na 127.0.0.1, a następnie przekaż potrzebny ruch: ssh -N -L 3000:127.0.0.1:3000 you@vps.example.com, po czym otwórz http://localhost:3000 na swoim laptopie. Żaden port nie jest wystawiony na zewnątrz, więc nic nie może zostać przeskanowane. W przypadku Hollama lub OrionChat przekaż port modelu w tym samym poleceniu za pomocą -L 11434:127.0.0.1:11434, pozostawiając Ollama na interfejsie loopback. Skuteczność tego wzorca zależy od konfiguracji SSH, dlatego należy połączyć go z uwierzytelnianiem kluczem SSH i zabezpieczonym sshd.

Wzorzec drugi: reverse proxy uwierzytelniające przed przekazaniem żądania do aplikacji. Pozostaw aplikację na interfejsie loopback, przypisz proxy do portu 443 i umieść przed nim mechanizm single sign-on. Traefik sterowany etykietami Docker Compose wraz z Authentik jako dostawcą tożsamości zapewnia każdej aplikacji na serwerze jeden punkt logowania i jeden certyfikat. Gdy Open WebUI znajduje się za TLS (transport layer security), ustaw WEBUI_SESSION_COOKIE_SECURE=true oraz WEBUI_SESSION_COOKIE_SAME_SITE=strict. Skróć również domyślny czas JWT_EXPIRES_IN wynoszący cztery tygodnie, ponieważ dokumentacja Open WebUI wskazuje, że bez Redis wylogowanie nie unieważnia tokena: pozostaje on ważny do momentu wygaśnięcia.

Wzorzec drugi nie rozwiązuje problemów projektów działających wyłącznie w przeglądarce. Proxy przed stroną nie chroni punktu końcowego modelu, a żądanie fetch z tej strony do innej nazwy hosta nie przenosi ciasteczka sesji. W rezultacie proxy uwierzytelniające przed Ollama odpowiada przekierowaniem do formularza logowania, a czat przestaje działać. Należy albo skierować punkt końcowy modelu pod tę samą nazwę hosta co stronę, albo zastosować wzorzec pierwszy.

Wybór odpowiedniego rozwiązania

Jeśli z narzędzia będzie korzystać ktokolwiek poza Tobą, uruchom Open WebUI. Oferuje ono obsługę kont, nowi użytkownicy trafiają do kolejki zatwierdzeń, a twórcy publikują wytyczne dotyczące zabezpieczania, które można wdrożyć. Jeśli wymagana jest obsługa LDAP lub panel administratora, uruchom LibreChat i upewnij się za pomocą docker stats, czy jego sześć usług oraz wybrany model faktycznie mieszczą się w zasobach, zanim zaczniesz na nim polegać. Jeśli z narzędzia korzysta jedna osoba na małym serwerze, gdzie model zajął już większość pamięci RAM, udostępnij Hollama lub OrionChat przez tunel SSH i pozwól przeglądarce przechowywać stan. Błędnym rozwiązaniem na VPS jest wystawienie któregokolwiek z nich na 0.0.0.0 bez zabezpieczenia logowaniem.

FAQ

Czy Open WebUI jest bezpieczne do wystawienia bezpośrednio na publicznym adresie IP?

Własna strona dokumentacji dotycząca zabezpieczeń opisuje to oprogramowanie jako przeznaczone do prywatnych, zaufanych sieci, w tej samej kategorii co baza danych czy serwer CI. Posiada ono obsługę kont, a pierwsze konto staje się administratorem, podczas gdy kolejne pozostają pending do momentu zatwierdzenia, więc jest znacznie bezpieczniejsze niż interfejs bez logowania. Mimo to należy umieścić je za reverse proxy z TLS oraz, jeśli to możliwe, z single sign-on. Port kontenera należy publikować jako 127.0.0.1:3000:8080, aby reguły iptables zarządzane przez Docker nie otworzyły go na świat bez wiedzy administratora.

Która alternatywa dla Open WebUI zużywa najmniej pamięci RAM na VPS?

Rozwiązania działające w przeglądarce, takie jak Hollama i OrionChat, ponieważ aplikacja uruchamiana jest po stronie klienta. Serwer przesyła jedynie pliki statyczne, a OrionChat w ogóle nie wymaga kontenera aplikacji. Open WebUI utrzymuje proces w Pythonie, bazę danych oraz, domyślnie, lokalny model embeddingów w pamięci, co według dokumentacji zajmuje około 500 MB na proces roboczy dla samego modelu. Wartości te należy zweryfikować na własnym serwerze za pomocą docker stats --no-stream, ponieważ zmieniają się one wraz z aktywowanymi funkcjami.

Czy te interfejsy czatu mogą korzystać z serwera Ollama na innym hoście?

Open WebUI oraz LibreChat mogą to robić, a połączenie nawiązywane jest przez ich serwer, więc ograniczenia przeglądarki nie mają zastosowania. Należy ustawić OLLAMA_BASE_URL dla Open WebUI lub baseURL w niestandardowym punkcie końcowym dla LibreChat. W przypadku vLLM lub innego serwera zgodnego z OpenAI, należy użyć OPENAI_API_BASE_URL z sufiksem /v1 oraz niepustym kluczem API. Hollama i OrionChat również mogą wskazywać na dowolny adres, jednak żądanie pochodzi z przeglądarki, więc punkt końcowy musi być osiągalny również z poziomu przeglądarki użytkownika.

Dlaczego mój interfejs czatu w przeglądarce nie może połączyć się z Ollama?

Dwie przyczyny obejmują niemal wszystkie przypadki. Ollama domyślnie nasłuchuje na 127.0.0.1:11434, więc przeglądarka na innej maszynie nie uzyska połączenia, dopóki nie zostanie zmienione OLLAMA_HOST. Ponadto Ollama akceptuje żądania cross-origin tylko z localhost, więc strona serwowana z własnej domeny otrzymuje odmowę z błędem No 'Access-Control-Allow-Origin' header is present on the requested resource, dopóki dany origin nie zostanie wymieniony w OLLAMA_ORIGINS. Jeśli strona korzysta z HTTPS, a punkt końcowy z HTTP, przeglądarka zablokuje połączenie jako mixed content, zanim Ollama w ogóle je otrzyma. Należy ustawić obie zmienne w pliku systemctl edit ollama.service lub przekierować port przez SSH, co rozwiązuje problem.