Open WebUI installieren: Docker Compose, Ollama und der erste Chat

Open WebUI und Ollama: zwei Dienste, ein Lernaufbau

Open WebUI zeigt Chats an und verbindet sich mit einem Modellanbieter. Im folgenden Aufbau ist dieser Anbieter ein eigener Ollama-Container. Open WebUI wird dadurch nicht selbst zum Sprachmodell. Auch nach dem Start beider Dienste musst du ein passendes Modell auswählen beziehungsweise laden. Für den Ollama-Dienst allein zeigt die Docker-Anleitung Speicher, Portbindung und die getrennte Prüfung von Container und API.

localhost innerhalb eines Containers meint diesen Container, nicht automatisch deinen Rechner und nicht den Nachbardienst. Bei Unklarheiten kannst du den Ollama-Port und die erreichbare Adresse unterscheiden.

Die Architekturzeichnung zeigt einen Lernaufbau mit normalem Compose-Netzwerk. Wir veröffentlichen hier keinen Ollama-Port am Host und schalten keinen Host-Netzwerkmodus ein.

Vorbereiten: Docker, Speicher und Sitzungsschlüssel

Du brauchst eine funktionierende aktuelle Docker-Engine mit Compose v2, ausreichend Speicher für Images und Modell sowie die nötigen lokalen Rechte. Unter Windows mit Docker Desktop/WSL folgst du zuerst dessen offizieller Einrichtung; die nachstehenden Shellbeispiele verwenden eine Linux- oder macOS-Shell.

docker version
docker compose version

Für die beschriebene lokale Portbindung verwenden wir eine aktuelle Engine, mindestens Docker28. Docker dokumentiert bei älteren Versionen eine Ausnahme, durch die Rechner im gleichen Netzwerksegment auch an localhost veröffentlichte Ports erreichen konnten. Angepasste Routingregeln sind außerdem ein eigener Prüffall.

Lege einen eigenen Projektordner an. Open WebUI benötigt einen festen privaten Sitzungsschlüssel. Der Schlüssel ist nicht dein späteres Loginpasswort. Er bleibt über Containerneustarts und Wiederherstellungen gleich und gehört nicht in Git oder einen öffentlichen Download.

export WEBUI_SECRET_KEY="$(openssl rand -hex 32)"

Das ist ein Erzeugungsbefehl, kein von uns erzeugter oder gespeicherter Schlüssel. Sichere den tatsächlichen Wert privat, etwa in deiner geschützten lokalen Konfiguration. Wenn du für jeden Neustart einen neuen erzeugst, erfüllst du die Anforderung eines festen Werts nicht. Gib aufgelöste Compose-Konfigurationen mit diesem Wert nicht weiter.

Compose-Datei für einen lokalen Einstieg

Speichere die folgende eigene Lernvorlage als compose.yaml in deinem Projektordner. Sie verwendet zwei benannte Volumes: eines für Ollama-Modelle, eines für WebUI-Daten. Die Ollama-Adresse nutzt den Servicenamen im gemeinsamen Netzwerk.

# Eigene Tokenwerk-Lernvorlage: CPU-Einstieg auf dem eigenen Rechner.
# Voraussetzung: aktuelle Docker Engine (mindestens 28 fuer den genannten
# Loopback-Schutz), Compose v2 und ein privat gesetzter WEBUI_SECRET_KEY.
# main und latest sind rollende Tags. Fuer reproduzierbaren Betrieb
# vorher echte freigegebene Versionen oder gepruefte Digests einsetzen.
name: tokenwerk-webui-lernen
services:
  ollama:
    image: ollama/ollama:latest
    volumes:
      - ollama-modelle:/root/.ollama
    restart: unless-stopped
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    ports:
      - "127.0.0.1:3000:8080"
    environment:
      OLLAMA_BASE_URL: http://ollama:11434
      WEBUI_SECRET_KEY: ${WEBUI_SECRET_KEY:?Privaten festen Sitzungsschluessel setzen}
      ENABLE_OPENAI_API: "false"
    volumes:
      - webui-daten:/app/backend/data
    depends_on:
      - ollama
    restart: unless-stopped
volumes:
  ollama-modelle:
  webui-daten:

Die gezeigten Tags main und latest sind beweglich. Besonders Open WebUI erklärt ausdrücklich: latest ist hier nicht gleichbedeutend mit einer stabil gepinnten Veröffentlichung. Für wiederholbaren Betrieb setzt du überprüfte konkrete Versionen oder Digests ein und hältst sie mit deiner Sicherung fest.

Die Vorlage setzt den lokal gewählten API-Zugang. ENABLE_OPENAI_API=false entfernt den hierfür unnötigen Standard-API-Weg; es ist kein vollständiger Offline-Schalter. Der Ollama-Dienst erhält in diesem CPU-Einstieg keine GPU-Geräte. GPU-Nutzung braucht eine zusätzliche passende Einrichtung.

Compose-Lernvorlage als Text herunterladen. Benenne die Datei bei dir bewusst in compose.yaml um und kontrolliere sie. Der Download enthält keinen echten Sitzungsschlüssel.

Starten, Administrator anlegen und erstes Modell wählen

Öffne das Terminal im Ordner der Vorlage. Prüfe zuerst deren Syntax und Variablen, ohne die aufgelösten privaten Werte auszugeben. Danach startest du die Dienste. Der erste Start kann wegen Downloads und Initialisierung dauern.

docker compose config --quiet
docker compose up -d
docker compose ps
docker compose logs --tail=80 open-webui ollama

depends_on beschreibt in dieser Vorlage eine Startreihenfolge, keine bestätigte Betriebsbereitschaft des Modellservers. Lies deshalb Status und Logs. Öffne anschließend http://127.0.0.1:3000 auf demselben Rechner.

1. Lege über Create Admin Account deinen ersten lokalen Administrator an. Dieser erste Account verwaltet die Instanz.
2. Öffne bei Bedarf über dein Profil Settings → Admin → Connections und kontrolliere den Ollama-Zugang http://ollama:11434.
3. Wähle im neuen Chat ein tatsächlich vorhandenes geeignetes Modell. Ist noch keines geladen, nutze den dokumentierten Modell-Pull über die Modellauswahl und beachte dessen Download- und Speicherbedarf.
4. Stelle eine kurze Frage ohne persönliche Daten und prüfe die Antwort.

Eigene Mini-Aufgabe: „Formuliere diesen Satz kürzer, ohne den Termin zu ändern: Unser fiktiver Test beginnt am Dienstag um 09:30 Uhr.“ Das Prüfkriterium ist der unveränderte Tag und die unveränderte Zeit. Eine sichtbare Chatblase beweist noch keine korrekte Antwort.

Bleibt der Modellwähler leer, prüfe zuerst Verbindung und tatsächlich verfügbare Modelle. Lege nicht wiederholt neue Administratorkonten an, um einen Netzwerkfehler zu lösen.

Daten, externe Verbindungen und Werkzeuge prüfen

Chats, Nutzer und Einstellungen liegen im WebUI-Volume; die Ollama-Modelle liegen im zweiten Volume. „Lokal bereitgestellt“ bedeutet trotzdem nicht automatisch „ohne ausgehende Verbindungen“. Der Quickstart nennt unter anderem Versionsprüfungen und Aktualisierungsanfragen für Embeddingmodelle. Zusätzliche Provider und Werkzeuge können weitere Datenwege öffnen.

Beginne mit einer fiktiven Textfrage. Aktiviere Dokumentensuche, Websuche, Sprache und Community-Werkzeuge erst, wenn du deren Anbieter, Daten und Rechte geprüft hast. Die Standard- und Slim-Images unterscheiden sich bei lokalen Funktionen; ein kleineres Image übernimmt nicht automatisch dieselben Aufgaben ohne zusätzliche Dienste.

Für den nächsten Lernschritt kannst du Dokumente in Open WebUI mit Quellen prüfen. Ein Upload allein belegt noch keine passende Fundstelle oder korrekte Antwort.

Wenn du fremde Texte verarbeiten lässt, solltest du außerdem Anweisungen in fremden Dokumenten erkennen. Ein gelesener Text bekommt dadurch keine Berechtigung, Dateien zu ändern oder Werkzeuge auszuführen. Halte solche Funktionen im ersten Versuch ausgeschaltet.

Der erste Administrator ist ein echtes Konto deiner eigenen Instanz. Bewahre seinen Zugang geschützt auf. Der Sitzungsschlüssel und das Passwort haben unterschiedliche Aufgaben; keine dieser Angaben gehört in ein öffentliches Fehlerprotokoll.

Fehler, Sicherung und kontrolliertes Update

Ein Update beginnt mit einer prüfbaren Sicherung: Datenvolumes, Compose-Datei, verwendete Imageversionen und den festen Schlüssel getrennt geschützt sichern. Stoppe schreibende Dienste für einen konsistenten Datenstand und prüfe die Wiederherstellung in einer separaten Umgebung. Ein erhaltenes Volume allein ist noch keine unabhängige Sicherung.

Erst nach dieser Vorbereitung wählst du eine konkrete neue Version. Die folgenden Befehle beziehen die in deiner Datei angegebenen Images erneut und erstellen die Dienste passend zur Konfiguration. Bei rollenden Tags kann sich der Inhalt dabei ändern.

docker compose pull
docker compose up -d
docker compose ps

docker compose down entfernt Container und Netzwerk, benannte Volumes bleiben normalerweise erhalten. Füge zum normalen Stoppen oder Update kein -v hinzu: Damit würdest du auch die benannten Datenvolumes entfernen. Teste Vorabversionen nie mit demselben Datenvolume wie deine eigentliche Installation, weil Datenbankmigrationen den Rückweg erschweren können.

Öffentliche Freigabe mit Domain, HTTPS, Benutzerverwaltung, Sicherungen und Netzschutz ist ein eigener Betriebsauftrag. Die lokale Vorlage soll dir zuerst zeigen, welcher Teil des Systems funktioniert und wo ein Fehler entsteht.