Artykuł Technologie

Open WebUI - instalacja i konfiguracja interfejsu do lokalnego LLM

Autor: Piotr Broniewski 7 min czytania

Open WebUI to darmowy, samohostowany interfejs webowy (GUI w stylu ChatGPT) do rozmowy z lokalnymi modelami LLM, najczęściej przez Ollamę. Najszybsza droga: jedno polecenie docker run z mapowaniem portu 3000. Po starcie wchodzisz na localhost:3000, zakładasz lokalne konto admina i wybierasz model.

W skrócie: cała reszta tego poradnika to warianty tej jednej operacji - instalacja przez Docker albo pip, połączenie z Ollamą, podpięcie zewnętrznego API i typowe błędy, gdy coś nie wstaje. Pokażę Ci polecenia i wyjaśnię, co każde z nich robi krok po kroku.

Co to jest Open WebUI

Open WebUI to rozszerzalna, samohostowana platforma AI - frontend, który stawiasz na własnym sprzęcie i przez przeglądarkę rozmawiasz z modelami językowymi. Ma ponad 338 milionów pobrań i społeczność liczącą 443 tysiące osób (dane projektu). Jest open-source, więc nie płacisz licencji - koszt to tylko Twój komputer lub serwer.

Najważniejsze: to nie jest sam model. Open WebUI to warstwa graficzna nad runnerem, który faktycznie liczy odpowiedzi. Domyślnie współpracuje z Ollamą, ale obsługuje też API kompatybilne z OpenAI, a przez nie dostawców takich jak Anthropic, LM Studio, OpenRouter, vLLM, Mistral czy GroqCloud. Jeśli dopiero zaczynasz z lokalnym AI, zajrzyj najpierw do pełnego przewodnika po lokalnym LLM przez Ollamę, Open WebUI dokłada do tego okno czatu, historię rozmów, wgrywanie dokumentów, konta użytkowników i role. W praktyce: Ollama to silnik, Open WebUI to deska rozdzielcza. Trzy funkcje robią tu największą różnicę na starcie: multi-model chat, RAG na własnych plikach oraz rozszerzenia w Pythonie (functions, MCP, plugins).

Wymagania wstępne

Co realnie potrzebujesz, zanim wpiszesz pierwsze polecenie:

  • Działający runner modeli - najczęściej Ollama. To ona pobiera i uruchamia model, a Open WebUI tylko się do niej podłącza. Jeśli jeszcze jej nie masz, zacznij od instrukcji jak zainstalować Ollamę.
  • Zasoby maszyny - sam interfejs jest lekki. Ciężar bierze na siebie model w Ollamie, więc to RAM i ewentualne GPU decydują, jak szybko dostaniesz odpowiedź. Minimalne wymagania zależą od wielkości modelu - dobierasz je pod konkretny model w Ollamie.

W praktyce: najpierw upewnij się, że ollama run działa i model odpowiada w terminalu. Dopiero potem stawiaj GUI. Jeśli silnik nie rusza, interfejs i tak nie będzie miał z czym rozmawiać.

Instalacja przez Docker

Najszybsza droga. Jedno polecenie pobiera obraz, tworzy kontener i wystawia interfejs na porcie 3000. Wariant, gdy Ollama działa już na Twoim komputerze (na hoście):

# pobiera obraz Open WebUI i uruchamia go w tle (-d)
# -p 3000:8080  -> interfejs dostepny na localhost:3000
# --add-host    -> pozwala kontenerowi siegnac do Ollamy na hoscie
# -v open-webui -> trwaly wolumen na dane (konta, historia czatow)
docker run -d -p 3000:8080 \
  --add-host=host.docker.internal:host-gateway \
  -v open-webui:/app/backend/data \
  --name open-webui \
  --restart always \
  ghcr.io/open-webui/open-webui:main

Tag :main to standardowy obraz. Port wewnątrz kontenera to 8080, ale na zewnątrz (po lewej stronie w -p) mapujemy go na 3000 - i pod tym adresem wejdziesz w przeglądarce.

Docker Compose

Jeśli wolisz konfigurację w pliku niż długie polecenie, użyj docker-compose.yaml:

services:
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    ports:
      - "3000:8080"          # interfejs na localhost:3000
    extra_hosts:
      - "host.docker.internal:host-gateway"  # dostep do Ollamy na hoscie
    volumes:
      - open-webui:/app/backend/data         # trwale dane
    restart: always

volumes:
  open-webui:

Uruchamiasz całość poleceniem docker compose up -d. Oficjalny plik compose z opcjonalnym serwisem Ollamy znajdziesz w repozytorium projektu - warto go porównać, bo bywa rozbudowywany o nowe opcje.

Ollama w kontenerze czy na hoście

Trade-off: masz dwie filozofie uruchomienia.

  • Ollama osobno, na hoście - obraz :main plus --add-host, jak wyżej. Open WebUI łączy się z Ollamą działającą obok. Wygodne, gdy już używasz Ollamy z terminala.
  • Ollama w tym samym kontenerze - obraz z tagiem :ollama pakuje runner i interfejs razem. Jedno polecenie, wszystko w środku, dobre na czysty start. Dla akceleracji GPU jest osobny tag :cuda.

Jeśli stawiasz silnik i interfejs w kontenerach osobno, przyda Ci się instrukcja uruchomienia Ollamy w Dockerze | dzieli środowisko z systemem | | Aktualizacja | podmiana obrazu | pip install --upgrade | | Zasoby | narzut na kontener | lżejsze, bez warstwy Dockera | | Dla kogo | większość użytkowników | minimaliści z Pythonem na pokładzie |

Konkret: jeśli nie masz silnych powodów, by trzymać się czystego Pythona, wybierz Docker. Jest szybszy w starcie i łatwiej go posprzątać.

Pierwsze uruchomienie i połączenie z Ollamą

Po starcie kontenera wejdź w przeglądarce na localhost:3000. Przy pierwszym wejściu Open WebUI poprosi o założenie konta administratora - to konto lokalne, dane zostają na Twojej maszynie, nic nie leci do chmury. Pierwszy zarejestrowany użytkownik dostaje rolę admina.

Najważniejsze: po zalogowaniu na liście modeli powinny pojawić się te, które masz pobrane w Ollamie. Wybierasz model z rozwijanej listy, wpisujesz wiadomość w okno czatu i testujesz odpowiedź. Jeśli model odpowiada - gotowe, interfejs jest spięty z silnikiem.

Jeśli coś nie działa i lista modeli jest pusta, to prawie zawsze kwestia połączenia z Ollamą, a nie samego interfejsu. Open WebUI musi wiedzieć, pod jakim adresem nasłuchuje Ollama - służy do tego zmienna OLLAMA_BASE_URL. Przy instalacji w Dockerze, gdy Ollama siedzi na hoście, adresem jest zwykle http://host.docker.internal:11434. Rozwijam ten przypadek w sekcji o błędach niżej. Open WebUI to jeden z kilku interfejsów do Ollamy - jeśli chcesz porównać go z innymi, zajrzyj do zestawienia interfejsów graficznych do Ollamy pozwala wgrać pliki i pytać o ich treść. W praktyce: dorzucasz dokument do rozmowy, a model odpowiada na podstawie jego zawartości, zamiast zgadywać. Przydaje się, gdy chcesz przeszukać własne notatki czy umowy bez wysyłania ich do zewnętrznej usługi - dane zostają lokalnie.

Połączenie z zewnętrznym API

Open WebUI nie jest przywiązany do Ollamy. Wskazujesz adres API kompatybilnego z OpenAI i podpinasz dowolnego dostawcę: LM Studio, OpenRouter, vLLM, Mistral, GroqCloud, a przez to także modele OpenAI czy Anthropic. W jednym interfejsie trzymasz wtedy modele lokalne i chmurowe obok siebie - wybierasz per rozmowa, który silnik liczy odpowiedź.

Użytkownicy i role

Skoro to platforma samohostowana, możesz wpuścić do niej innych. Pierwszy użytkownik jest adminem, kolejnym nadajesz role i uprawnienia. Dla zespołu oznacza to jeden wspólny interfejs do lokalnego AI bez zakładania kont w usługach zewnętrznych.

MCP i rozszerzenia w Pythonie

Open WebUI rozszerzasz w Pythonie - przez functions i plugins. Obsługuje też MCP (Model Context Protocol - standard, przez który modele i agenci sięgają do zewnętrznych narzędzi). To furtka do automatyzacji i podpinania własnej logiki, ale na start nie jest potrzebna - zostaw ją na później, gdy podstawy już działają.

Częste błędy i troubleshooting

Konkret: większość problemów z Open WebUI to nie awarie, tylko literówki w adresie albo zajęty port. Cztery sytuacje, na które natkniesz się najczęściej - przyczyna i rozwiązanie.

  • Nie łączy się z Ollamą / pusta lista modeli. Przyczyna: zły OLLAMA_BASE_URL albo kontener nie widzi hosta. Rozwiązanie: przy Dockerze ustaw adres na http://host.docker.internal:11434 i dorzuć --add-host=host.docker.internal:host-gateway do polecenia docker run. Sprawdź też, czy Ollama w ogóle działa (ollama list na hoście).
  • Port 3000 zajęty. Przyczyna: inna usługa już go używa. Rozwiązanie: zmień mapowanie w -p, np. -p 3001:8080, i wejdź na localhost:3001. Wewnętrzny port 8080 zostawiasz bez zmian.
  • Wolne odpowiedzi. Przyczyna: model liczy na CPU, bez akceleracji. Rozwiązanie: użyj GPU - rozkładam to w poradniku o przyspieszeniu modeli przez GPU.
  • Problem po aktualizacji kontenera. Przyczyna: podmiana obrazu bez zachowania danych. Rozwiązanie: trzymaj dane na nazwanym wolumenie (-v open-webui:/app/backend/data), wtedy konta i historia przeżyją podmianę obrazu na nowszy :main.

Gdy komunikat błędu jest niejasny, zacznij od logów kontenera (docker logs open-webui). Zwykle wprost piszą, czego interfejs nie może znaleźć.

Open WebUI na serwerze (VPS)

To zależy - od czego? Od Twojego sprzętu. Lokalny komputer jest świetny do nauki i prywatnych eksperymentów, ale ma trzy ograniczenia: słaby laptop bez GPU liczy wolno, interfejs jest dostępny tylko z tej jednej maszyny, a zespół nie ma jak się podłączyć. Wtedy naturalnym krokiem jest postawienie Open WebUI razem z Ollamą na serwerze.

Co realnie sprawdzić w hostingu pod lokalne AI:

  • RAM - tu mieści się model. Im większy model, tym więcej pamięci; to zwykle pierwsze wąskie gardło.
  • GPU lub mocne vCPU - GPU radykalnie skraca czas odpowiedzi. Bez niego modele działają, ale wolniej.
  • Dysk - modele LLM ważą po kilka, kilkanaście gigabajtów każdy. Licz miejsce z zapasem.
  • Możliwość uruchomienia Dockera - bez tego stracisz najwygodniejszą drogę instalacji opisaną wyżej.

W praktyce: na VPS stawiasz dokładnie tę samą konfigurację co lokalnie - Docker plus Ollama - tylko interfejs wystawiasz pod adresem serwera (pamiętaj o zabezpieczeniu dostępu, bo to już nie localhost). Jeśli szukasz maszyny pod takie zadania, sprawdź ranking VPS pod lokalne LLM i automatyzacje, czy adres bazowy jest poprawny i czy port 11434 jest osiągalny z wnętrza kontenera. Przy Dockerze pomaga --add-host=host.docker.internal:host-gateway.