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 fakty, co wpływa na ranking. Open WebUI pozostaje domyślnym wyborem w momencie, gdy loguje się druga osoba, ponieważ oprogramowanie to dostarcza obsługę kont użytkowników oraz panel administratora. Lżejsze projekty wygrywają, gdy interfejs rywalizuje z modelem o ostatni gigabajt pamięci RAM. Ceną tego zwycięstwa jest uwierzytelnianie: projekty te go nie posiadają.

Wszystkie poniższe informacje pochodzą z dokumentacji poszczególnych projektów, zweryfikowanej w sierpniu 2026. Cztery osie oceny to te, które stają się istotne dopiero wtedy, gdy serwer jest dostępny z poziomu Internetu.

Cztery kluczowe aspekty przy korzystaniu z publicznego adresu 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 i nie oferują żadnego mechanizmu logowania.
• Zdalna inferencja. Interfejs ograniczony wyłącznie do 127.0.0.1:11434 wymusza uruchomienie modelu na tej samej maszynie, na której działa interfejs.
• Utrzymanie. Pojedynczy kontener z bazą SQLite wymaga znacznie mniej pracy niż sześć kontenerów 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 model. Publikowane rozmiary plików do pobrania określają jedynie wartość minimalną, ponieważ wagi muszą znajdować się w pamięci podczas generowania odpowiedzi przez model, a rzeczywiste zużycie pamięci jest wyższe niż rozmiar pliku po przydzieleniu pamięci podręcznej kontekstu (context cache).

[
  {
    "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 pomiary. 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. Dlatego ustawiana wartość num_ctx jest decyzją dotyczącą pamięci w takim samym stopniu, jak jakości. Model qwen3:8b o rozmiarze 5.2 GB w ogóle nie zmieści się na takim serwerze. 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 serwer dla modelu znacznie większego niż te wskazane, obliczenia dla modelu 27B na serwerze VPS tylko z procesorem 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. Ollama zwalnia również wagi po pięciu minutach bezczynności, więc odczyt wykonany pomiędzy konwersacjami zaniża wartość szczytową, a kolejna wiadomość ponownie obciąża system, chyba że utrzymasz model w pamięci za pomocą keep_alive.

Open WebUI: nadal ustawienie domyślne dla wielu użytkowników

Open WebUI działa 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 w pliku README projektu publikuje -p 3000:8080, co powoduje nasłuchiwanie na każdym interfejsie. Prefiks 127.0.0.1: ogranicza to działanie do interfejsu loopback. Na serwerze VPS ten prefiks ma kluczowe znaczenie, 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, zgodnie z opisem poniżej, a następnie utwórz pierwsze konto. To konto staje się administratorem. Kolejne rejestracje tworzone są z rolą pending, co jest udokumentowanym ustawieniem domyślnym DEFAULT_USER_ROLE, dzięki czemu osoba niepowołana, która uzyska dostęp do strony, nie może korzystać z modelu, dopóki administrator jej nie zatwierdzi.

Open WebUI zużywa więcej pamięci niż poniższe projekty, ponieważ oferuje szerszą funkcjonalność, a wbudowana strona wydajności wskazuje elementy generujące to obciążenie. Domyślny silnik osadzeń (embedding engine) ładuje model sentence-transformers wewnątrz kontenera, co według dokumentacji zajmuje 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 połączeń przyjmuje duży rozmiar wewnętrzny, a każde połączenie zwiększa własną pamięć podręczną stron i mapowanie pamięci, dlatego na małych maszynach należy ustawić DATABASE_POOL_SIZE=8 oraz DATABASE_SQLITE_PRAGMA_MMAP_SIZE=0. ENABLE_AUTOCOMPLETE_GENERATION=False zapobiega wysyłaniu przez interfejs żądań o dokończenie tekstu 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 odpowiada na porcie 3080. LibreChat to rozwiązanie, które warto rozważyć, gdy wymagany jest system tożsamości, a nie tylko proste pole logowania: dokumentacja obejmuje logowanie przez LDAP i OAuth2, a pakiet zawiera panel administratora do zarządzania 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 maszynie z 4 GB RAM ogranicza pamięć dostępną dla modelu.

Aktualizacje wykonuje się za pomocą operacji git, co jest etapem często przeprowadzanym błędnie.

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

git pull kończy działanie z konfliktem, jeśli zmodyfikowano śledzony plik docker-compose.yml, co powoduje częściowe zastosowanie aktualizacji. Własne zmiany należy umieszczać w pliku docker-compose.override.yml, który jest do tego przeznaczony, natomiast sekrety w .env. Oba pliki nie są śledzone, więc git pull pomija je podczas operacji.

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, mimo że Ollama ignoruje jego wartość, więc można w nim umieścić 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 tam 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 wraca po restarcie. W przypadku użycia reverse proxy należy dodać -e VITE_ALLOWED_HOSTS='chat.example.com', ponieważ obraz zezwala wyłącznie na hosta localhost i w odpowiedzi na żądanie dla każdej innej nazwy hosta zwraca błąd blocked-host zamiast aplikacji.

OrionChat idzie o krok dalej i nie posiada żadnego komponentu serwerowego. Należy sklonować repozytorium i udostępnić folder za pomocą działającego już serwera WWW lub otworzyć index.html bezpośrednio 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 ma serwera, 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, a także wiąże się z faktem, który łatwo przeoczyć: to przeglądarka wywołuje model, a nie serwer.

Ten jeden fakt decyduje o użyteczności obu rozwiązań. 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 na zmianę tych ustawień w Ollama 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. Tę zmianę należy wprowadzać tylko wtedy, gdy firewall lub uwierzytelniające proxy kontroluje dostęp do portu, ponieważ otwarty port 11434 oznacza otwarty serwer modelu, a masowe skanery szybko wykrywają nowe publiczne porty. Poniższy tunel SSH pozwala uniknąć tego problemu: strona działa wtedy w źródle localhost, na co Ollama domyślnie zezwala, 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 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, który już hostujesz.

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

Rozdzielenie interfejsu od modelu to najbardziej użyteczna korzyść płynąca ze zdalnego punktu końcowego. Umieść interfejs na małej maszynie, 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 na maszynie 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 inne elementy infrastruktury self-hosted, takie jak bazy danych, rejestry kontenerów czy serwery CI”. Zaleca się umieszczenie go za VPN lub za odwrotnym proxy z uwierzytelnianiem. Projekt pozbawiony mechanizmu logowania wymaga co najmniej takiego samego traktowania.

Sprawdź, co nasłuchuje, zanim zaufasz konfiguracji.

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

Wiersz zawierający 127.0.0.1:3000 oznacza pożądany stan. Wiersz zawierający 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, która posiada już konta, co skutkuje komunikatem You can't turn off authentication because there are existing users..

Wzorzec pierwszy: powiązanie z interfejsem pętli zwrotnej i dostęp przez SSH. Udostępnij każdy port na 127.0.0.1, a następnie przekaż potrzebne porty: ssh -N -L 3000:127.0.0.1:3000 you@vps.example.com i otwórz http://localhost:3000 na swoim laptopie. Żaden port nie jest publicznie dostępny, 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 pętli zwrotnej. Skuteczność tego wzorca zależy od konfiguracji SSH, dlatego należy połączyć go z uwierzytelnianiem wyłącznie za pomocą kluczy SSH i wzmocnionym sshd.

Wzorzec drugi: odwrotne proxy uwierzytelniające przed przekazaniem żądania do aplikacji. Utrzymuj aplikację na interfejsie pętli zwrotnej, pozwól proxy obsługiwać port 443 i umieść przed nią mechanizm SSO. 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 czterotygodniowy czas JWT_EXPIRES_IN, ponieważ dokumentacja Open WebUI wskazuje, że bez Redis wylogowanie nie unieważnia tokena: pozostaje on aktywny 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, co powoduje błąd czatu. Należy albo skierować punkt końcowy modelu pod tę samą nazwę hosta co stronę, albo zastosować wzorzec pierwszy.

Które rozwiązanie wybrać

Jeśli z narzędzia będzie korzystać ktokolwiek poza Tobą, uruchom Open WebUI. Posiada ono obsługę kont, nowi użytkownicy trafiają do kolejki zatwierdzeń, a twórcy publikują wytyczne dotyczące zabezpieczania systemu, 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 model faktycznie mieszczą się w zasobach, zanim zaczniesz na nim polegać. Jeśli jest to rozwiązanie dla jednej osoby 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łędną decyzją na VPS jest wystawienie któregokolwiek z tych narzędzi 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 poświęcona zabezpieczeniom określa 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 własne reguły iptables Dockera nie otworzyły go na Internet 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 języku Python, 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łasnej maszynie za pomocą docker stats --no-stream, ponieważ zmieniają się one wraz z włączanymi funkcjami.

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

Open WebUI oraz LibreChat mogą to robić, a ich serwer nawiązuje połączenie, 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 przyrostkiem /v1 oraz niepustym kluczem API. Hollama i OrionChat również mogą wskazywać 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 każdy przypadek. Ollama domyślnie nasłuchuje na 127.0.0.1:11434, więc przeglądarka na innej maszynie nigdy 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 jest odrzucana z błędem No 'Access-Control-Allow-Origin' header is present on the requested resource, dopóki to źródło nie zostanie wymienione w OLLAMA_ORIGINS. Jeśli strona korzysta z HTTPS, a punkt końcowy z HTTP, przeglądarka zablokuje wywołanie jako mixed content, zanim Ollama w ogóle je otrzyma. Należy ustawić obie zmienne w nadpisaniu systemctl edit ollama.service lub przekierować port przez SSH, co rozwiązuje problem.