Eigenes ChatGPT in 10 Minuten: Open WebUI + Ollama (2026)

Open WebUI + Ollama: Das 10-Minuten-Setup-Handbuch (2026)

Hast du dir jemals gewünscht, dass ChatGPT auf deinem Laptop läuft statt auf OpenAIs Server? Open WebUI + Ollama ist genau der Stack, den du willst. Open WebUI liefert die ausgereifte Chat-Oberfläche; Ollama führt die Modelle lokal aus. Keine API-Schlüssel, keine Kosten pro Token, keine Daten, die deinen Rechner verlassen. Diese Anleitung bringt dich in etwa zehn Minuten vom leeren Terminal zum ersten Chat — und behandelt dann die Dinge, die die meisten Tutorials überspringen: Spracheingabe/-ausgabe, Pipelines, MCP, Apple-Silicon-Benchmarks und einen sauberen HTTPS-Pfad mit Caddy.

Kurzfassung:

• Open WebUI ist ein selbst gehostetes, ChatGPT-ähnliches Frontend; Ollama ist der lokale Modell-Runner, der es antreibt.
• Der Single-Container-Docker-Pfad bringt dich auf einer warmen Maschine in ~10 Minuten zum ersten Chat.
• Setze OLLAMA_BASE_URL auf http://host.docker.internal:11434, um den "kann keine Verbindung herstellen"-Fehler neunmal von zehn zu beheben.
• Open WebUIs Killer-Features sind Pipelines/Functions, natives RAG, Sprach-I/O und MCP — keines davon bietet LM Studio.

Was Ist Open WebUI + Ollama Eigentlich?

Open WebUI ist eine quelloffene, selbst gehostete Web-Oberfläche, die Ollama (und anderen lokalen LLM-Runtimes) eine ChatGPT-ähnliche Chat-UI gibt. Zusammen ermöglichen sie dir, private KI-Modelle auf deiner eigenen Maschine auszuführen — keine API-Schlüssel, keine Kosten pro Token, vollständige Datenkontrolle. Open WebUI ist die Chat-Schicht; Ollama ist die Modell-Schicht. Sie kommunizieren über HTTP auf Port 11434 — das ist die gesamte Architektur.

Lass uns die Komponenten aufschlüsseln, denn die Namen klingen austauschbar, sind es aber nicht:

• Open WebUI — die Browser-App, die du tatsächlich verwendest. Mehrbenutzer-fähig, RAG integriert, Plugin-System, läuft auf Port 8080 innerhalb von Docker (du mapped es auf 3000 auf deinem Host).
• Ollama — der Modell-Server. Er lädt GGUF-Dateien (stell dir .mp3 für KI-Modelle vor), lädt sie auf deine CPU/GPU und stellt eine übersichtliche HTTP-API auf Port 11434 bereit.
• Modelle — tatsächliche Gewichtsdateien. llama3.2:3b, qwen2.5:14b, deepseek-r1:7b usw. Werden über ollama pull geladen, in Ollamals Modellbibliothek aufgelistet.

Warum diese Kombination gewinnt: Datenschutz (Daten bleiben lokal), Kosten (null pro Token), offline-fähig, Mehrbenutzer out-of-the-box und ein echtes Plugin-Ökosystem. Wenn du neu in diesem Bereich bist, behandelt unser Leitfaden zum lokalen Ausführen von LLMs die Hardware-Seite.

Die offizielle Open WebUI-Dokumentation ist die kanonische Referenz — lege sie als Lesezeichen an. Sie ist knapp, aber präzise.

Wie Installiere Ich Open WebUI mit Ollama? (Schnell-Setup)

Installiere Docker, installiere Ollama, führe dann docker run -d -p 3000:8080 --add-host=host.docker.internal:host-gateway -v open-webui:/app/backend/data --name open-webui ghcr.io/open-webui/open-webui:main aus. Besuche http://localhost:3000, erstelle das Admin-Konto, lade ein Modell über Admin → Einstellungen → Verbindungen → Ollama und starte den Chat. Gesamtzeit: etwa 10 Minuten auf einer warmen Maschine.

Hier ist der vollständige Pfad, Schritt für Schritt:

1. Docker Desktop installieren — lade es von docker.com für Mac/Windows herunter oder apt install docker.io unter Linux.

2. Ollama installieren

# macOS / Linux
curl -fsSL https://ollama.com/install.sh | sh

# Windows: Installer von ollama.com herunterladen

3. Ein Startmodell laden. Ich würde mit llama3.2:3b beginnen — auf fast allem schnell, klug genug, um nützlich zu sein. Wenn du eine Übersicht der stärksten Optionen möchtest, sieh dir unsere Liste der besten Open-Source-LLMs an.

ollama pull llama3.2:3b

4. Den Open WebUI-Container ausführen (der kanonische Befehl):

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

5. http://localhost:3000 öffnen, anmelden (der erste Benutzer wird automatisch Admin) und du chattst.

Profi-Tipp: Auf Apple-Silicon-Macs führe Ollama nativ aus (nicht in Docker). Das ist by Design — es ermöglicht Ollama, die Metal-GPU zu nutzen. Open WebUI läuft in Docker; die beiden kommunizieren über host.docker.internal:11434.

Zum "10-Minuten"-Versprechen: Das ist eine Warm-Machine-Zahl — Docker bereits installiert, anständiges Internet für das ~2-GB-Image-Pull und ~2-GB-Modell-Pull. Erste Docker-Installation ohne Cache? Addiere zehn Minuten dafür. Langsame Verbindung? Addiere weitere fünf. Ehrliche Baseline, keine Marketing-Zahl.

Docker Compose: Das Produktionsreife Setup

Wenn du ein reproduzierbares Multi-Container-Setup für Open WebUI plus einen eigenständigen Ollama-Dienst möchtest, ist Docker Compose der sauberere Weg. Eine YAML-Datei deklariert beide Dienste, ein gemeinsames Netzwerk, benannte Volumes für Persistenz und ermöglicht die Neubereitstellung mit einem einzigen docker compose up -d. Ideal für Server, Homelabs oder Teams.

Der Trick, der die Leute stolpern lässt: Wenn beide Dienste innerhalb von Compose laufen, setze OLLAMA_BASE_URL=http://ollama:11434 (den Compose-Dienst-Namen), nicht host.docker.internal. Dockers internes DNS löst den Dienst-Namen automatisch auf.

services:
  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    ports:
      - "11434:11434"
    volumes:
      - ollama:/root/.ollama
    restart: always

  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    ports:
      - "3000:8080"
    environment:
      - OLLAMA_BASE_URL=http://ollama:11434
    volumes:
      - open-webui:/app/backend/data
    depends_on:
      - ollama
    restart: always

volumes:
  ollama:
  open-webui:

Starte es:

docker compose up -d
docker compose logs -f

Zwei Hinweise wert. Erstens schlagen benannte Volumes (ollama: und open-webui: unten) Bind-Mounts hier — Docker verwaltet Berechtigungen und dein Chat-Verlauf/deine Konfiguration überleben Container-Neubauten. Zweitens, wenn du ein Open WebUI möchtest, das mit lokalem Ollama und remote OpenAI/Anthropic über eine einzige URL spricht, stelle einen LiteLLM-Proxy davor. Und wenn du noch deine Runtime-Schicht auswählst, behandelt unser Überblick der besten lokalen LLM-Tools Ollama, vLLM, LM Studio und mehr.

GPU-Beschleunigung: NVIDIA, AMD und Apple Silicon

Ollama erkennt NVIDIA-GPUs automatisch über das NVIDIA Container Toolkit, AMD-GPUs über ROCm unter Linux und Apple-Silicon-GPUs nativ über Metal. Du übergibst --gpus all nicht an Open WebUI — nur Ollama braucht die GPU. Das schnellste Setup auf jeder Plattform sieht unterschiedlich aus, und einige "warum ist das langsam"-Momente lassen sich darauf zurückführen, dass Ollama am falschen Ort ist.

NVIDIA (Linux + Windows WSL2)

Installiere das NVIDIA Container Toolkit, dann führe Ollama in Docker mit --gpus all aus:

docker run -d --gpus=all \
  -v ollama:/root/.ollama \
  -p 11434:11434 \
  --name ollama \
  ollama/ollama

Überprüfe mit nvidia-smi, während ein Modell geladen ist — du solltest ollama in der GPU-Prozessliste sehen. Die Umgebungsvariable OLLAMA_NUM_GPU lässt dich Schichten begrenzen, wenn du VRAM mit anderen Workloads teilst.

Apple Silicon (M1/M2/M3/M4)

Führe Ollama nativ aus — nicht in Docker. Es gibt noch kein Metal-GPU-Passthrough in Docker (Stand Anfang 2026), also fällt ein dockerisiertes Ollama auf dem Mac auf CPU zurück, und du wirst dich fragen, warum sich dein M3 Max wie ein ThinkPad von 2015 anfühlt. Open WebUI läuft weiterhin in Docker; es erreicht Ollama über host.docker.internal:11434.

Auf meinem M2 Pro (16 GB) mit llama3.2:3b sehe ich ungefähr 45–55 Tokens/Sek. llama3.1:8b fällt auf ~22–28 Tokens/Sek. qwen2.5:14b ist mit ~9–12 Tokens/Sek grenzwertig nutzbar — gut für Chat, schmerzhaft für Batch-Arbeit. Die Zahlen variieren mit Quantisierung und Kontextlänge, aber das ist die Größenordnung.

AMD (ROCm unter Linux)

Ollama 0.5+ enthält ROCm-Unterstützung für RDNA2/RDNA3-Karten (RX 6000/7000 Serie, MI200/MI300 Datencenter-Chips). Verwende das dedizierte Image:

docker run -d --device=/dev/kfd --device=/dev/dri \
  -v ollama:/root/.ollama \
  -p 11434:11434 \
  --name ollama \
  ollama/ollama:rocm

Die AMD-Leistung hat 2025 die Lücke deutlich geschlossen — noch nicht auf NVIDIA-Niveau, aber kein Wissenschaftsprojekt mehr.

Wie Füge Ich RAG (Eigene PDFs) zu Open WebUI Hinzu?

Open WebUI kommt mit nativem RAG. Klicke auf dein Profil → Workspace → Wissen, erstelle eine Wissensbasis und lade PDFs, Word-Dokumente, Markdown oder Textdateien hoch. Im Hintergrund teilt Open WebUI Dokumente auf, bettet sie mit dem konfigurierten Einbettungsmodell (Standard nomic-embed-text) ein, speichert sie in ChromaDB und ruft sie zur Abfragezeit ab. Kein externer Dienst erforderlich.

Das Setup benötigt einen zusätzlichen Schritt: Zunächst das Einbettungsmodell laden.

ollama pull nomic-embed-text

Dann unter Admin → Einstellungen → Dokumente das Einbettungsmodell auf nomic-embed-text setzen. Passe Chunk-Größe (Standard 1500) und Überlappung (Standard 100) nach Bedarf an. Der klassische Fehler: Zu große Chunks sprengen dein Kontextfenster bei kleinen Modellen. Wenn du llama3.2:3b mit einem 4K-Kontext verwendest, lässt Chunks von 1500 Tokens kaum Platz für die eigentliche Frage — senke auf 800 mit 80 Überlappung.

Um eine Wissensbasis im Chat zu verwenden, tippe # und wähle die Sammlung aus. Oder füge sie dauerhaft an ein Custom-Modell in Workspace → Modelle an. Websuche funktioniert ähnlich — aktiviere einen Anbieter (SearXNG, Brave oder Tavily) unter Admin → Einstellungen → Websuche, und das Modell kann Live-Ergebnisse abrufen.

Für einen tieferen RAG-Vergleich, sieh unseren RAG-Tools-Überblick. Und wenn ChromaDB bei Scale nicht ausreicht, behandelt unser Überblick der Vektordatenbank-Optionen Qdrant, pgvector und die Kompromisse.

Sprach-I/O: Mit Deiner Lokalen KI Sprechen

Open WebUI unterstützt sowohl Sprache-zu-Text (STT) als auch Text-zu-Sprache (TTS). Für STT läuft faster-whisper lokal ohne API-Schlüssel. Für TTS kannst du OpenAIs TTS-API verdrahten oder eine lokale Engine wie coqui-tts betreiben. Einmal aktiviert, erscheint ein Mikrofon-Symbol im Chat-Feld und deine lokale KI antwortet.

Gehe zu Admin → Einstellungen → Audio. Zwei Engines, zwei Dropdowns.

STT-Pfad — wähle Whisper (Lokal), wähle eine Modellgröße: tiny, base, small, medium oder large. Das Modell wird beim ersten Gebrauch automatisch heruntergeladen. base ist der Sweet Spot für die meisten Laptops; medium, wenn du GPU-Headroom hast.

TTS-Pfad — am einfachsten ist OpenAI TTS: füge einen API-Schlüssel ein, wähle tts-1 und eine Stimme (alloy, nova usw.). Vollständig lokaler Pfad: coqui-tts-Engine mit einem separaten Docker-Image. Die meisten landen bei lokalem Whisper + OpenAI TTS als pragmatischem Mittelweg — dein Audio verlässt das Gerät für die Eingabe nicht, und der API-Aufruf ist nur eine kurze Textzeichenkette für die Ausgabe.

Du kannst die Wahl mit Umgebungsvariablen in den Container einbauen:

docker run -d \
  -e WHISPER_MODEL=base \
  -e AUDIO_STT_ENGINE=whisper \
  -p 3000:8080 \
  --add-host=host.docker.internal:host-gateway \
  -v open-webui:/app/backend/data \
  --name open-webui \
  ghcr.io/open-webui/open-webui:main

Die vollständige Audio-Referenz findet sich in der Open WebUI GitHub-Dokumentation.

Pipelines & Functions: Open WebUIs Killer-Feature

Pipelines und Functions sind die Art, wie du Open WebUI erweiterst, ohne es zu forken. Pipelines sind externe Python-Dienste, die als Filter, Modell-Router oder vollständige benutzerdefinierte Handler fungieren. Functions sind Inline-Python (Filter, Action oder Pipe), die innerhalb von Open WebUI selbst leben. Zusammen sind sie der Grund, warum Open WebUI LM Studio für ernsthafte Benutzer schlägt.

Drei Function-Typen, jeweils ein Satz:

• Filter — vor-/nachverarbeitet Nachrichten (PII-Schwärzung, Profanitätsfilter, Prompt-Umschreibung).
• Action — ein Button in der Chat-UI, der Python auslöst (Zusammenfassen, in Notion speichern, SQL-Abfrage ausführen).
• Pipe — ein vollständiger benutzerdefinierter Modell-Handler (an Remote-API weiterleiten, mehrere Modelle verketten, einen Agenten bauen).

Hier ist ein minimaler Filter, der E-Mail-Adressen aus Benutzer-Prompts entfernt, bevor sie das Modell erreichen:

from pydantic import BaseModel
import re

class Filter:
    class Valves(BaseModel):
        priority: int = 0

    def __init__(self):
        self.valves = self.Valves()

    def inlet(self, body: dict, __user__: dict = None) -> dict:
        for message in body.get("messages", []):
            if message.get("role") == "user":
                message["content"] = re.sub(
                    r"[\w\.-]+@[\w\.-]+",
                    "[REDACTED_EMAIL]",
                    message["content"],
                )
        return body

Füge das in Admin → Einstellungen → Functions → Neu ein, speichere und aktiviere es für ein beliebiges Modell. Fertig.

Für externe Pipelines starte den dedizierten Container neben Open WebUI:

  pipelines:
    image: ghcr.io/open-webui/pipelines:main
    container_name: pipelines
    ports:
      - "9099:9099"
    volumes:
      - pipelines:/app/pipelines
    restart: always

Dann unter Admin → Einstellungen → Verbindungen füge http://pipelines:9099 als OpenAI-kompatible API hinzu. Lade .py-Dateien unter Admin → Einstellungen → Pipelines hoch. Das offizielle Pipelines-Repo hat Dutzende von Beispielen — Übersetzungsrouter, Langfuse-Logging, Funktionsaufruf und mehr.

MCP: Open WebUI mit Externen Tools Verbinden

Open WebUI 0.6+ unterstützt das Model Context Protocol (MCP), was bedeutet, dass dein lokales Modell externe Tools aufrufen kann — Dateisuche, GitHub, Slack, deine eigenen benutzerdefinierten Server — über dasselbe Protokoll, das Claude Desktop verwendet. Es ist der sauberste Weg, einem lokalen Modell echten Werkzeuggebrauch zu geben, ohne eine Pipeline zu schreiben.

Füge einen MCP-Server unter Admin → Einstellungen → Tools hinzu: füge die Server-URL ein, gib ihr einen Namen und aktiviere sie pro Modell. Das Modell entscheidet während des Chats, wann es aufgerufen werden soll. Wir behandeln das Protokoll von Anfang bis Ende in unserem Model Context Protocol (MCP)-Leitfaden — gleiche Muster, nur von der Open WebUI-Seite statt von Claude Desktops Seite.

Warum das wichtig ist: Stand Mitte 2026 erwähnt fast kein Open WebUI-Tutorial MCP. Wenn du bereits auf MCP-Server für dein Claude- oder Cursor-Setup standardisiert hast, kannst du Open WebUI auf genau dieselben Server zeigen. Ein Protokoll, jeder Client.

Warum Kann Open WebUI Meine Ollama-Modelle Nicht Sehen? (Fehlerbehebung)

Wenn Open WebUI lädt, aber das Modell-Dropdown leer ist, kann der Container Ollama nicht erreichen. Neunmal von zehn ist die Lösung --add-host=host.docker.internal:host-gateway plus OLLAMA_BASE_URL=http://host.docker.internal:11434. Unter Linux ohne das host-gateway-Flag kann Dockers Bridge-Netzwerk Port 11434 des Hosts nicht sehen. Als wir das zum ersten Mal auf dem Linux-Rechner eines Kunden bereitgestellt haben, haben wir genau das getroffen und eine Stunde verloren.

Drei Grundursachen, in Häufigkeitsreihenfolge:

1. Fehlender --add-host-Flag (am häufigsten unter Linux). macOS Docker Desktop setzt host.docker.internal automatisch; Linux benötigt das explizite Flag.

2. Ollama nur an 127.0.0.1 gebunden. Aus der Perspektive des Containers ist das nicht erreichbar. Lösung:

   bash

   OLLAMA_HOST=0.0.0.0:11434 ollama serve

   Oder setze Environment="OLLAMA_HOST=0.0.0.0:11434" in der systemd-Unit unter Linux.

3. Firewall / Antivirus blockiert 11434. Weniger häufig, aber überprüfe ufw, Windows Defender oder Unternehmensendpunktschutz.

Diagnose — führe dies aus dem Open WebUI-Container aus:

docker exec open-webui curl http://host.docker.internal:11434/api/tags

Wenn das JSON mit deiner Modellliste zurückgibt, ist das Netzwerk in Ordnung und das Problem liegt in den Open WebUI-Einstellungen (überprüfe Admin → Verbindungen → Ollama-URL). Wenn es hängt oder ablehnt, hast du ein Host-seitiges Problem — beginne mit Ursache Nr. 2.

Open WebUI vs. LM Studio vs. Jan vs. AnythingLLM

Open WebUI gewinnt bei Mehrbenutzer, RAG-Tiefe und Pipelines/Functions. LM Studio gewinnt bei Out-of-the-Box-GPU-Leistung und einer ausgearbeiteten Einzelbenutzer-UI. Jan gewinnt bei minimaler Reibung beim ersten Start. AnythingLLM gewinnt bei der Dokumenten-Ingestion-Ergonomie. Wenn du einen selbst gehosteten ChatGPT-Ersatz für ein Team möchtest, ist Open WebUI die Antwort.

Fazit: Wenn du ein Solo-Entwickler bist, der einfach ein Modell auf seiner Gaming-GPU laufen lassen und chatten möchte, ist LM Studio schneller einzurichten. Wenn du ein privates ChatGPT für ein Team aufbaust, ernsthaftes RAG betreibst oder benutzerdefinierte Python-Logik verdratest, ist Open WebUI die einzig echte Wahl. Unser umfassenderer Beitrag zu den besten lokalen LLM-Tools vergleicht die Runtime-Schicht (vLLM, llama.cpp, Ollama) unter diesen UIs.

Wie Exponiere Ich Open WebUI Sicher über HTTPS?

Zwei saubere Pfade: ein 5-zeiliges Caddyfile vor Open WebUI für ein echtes Let's-Encrypt-Zertifikat (produktionsähnlich) oder ein Cloudflare-Tunnel für Team-Nutzung ohne offene Ports. Beide halten Open WebUI auf localhost:3000, während sie eine saubere öffentliche URL mit HTTPS exponieren. Wähle danach, ob du DNS für eine Domain kontrollierst.

Der Caddy-Pfad — richte deine Domain auf die Box, dann:

ai.example.com {
    reverse_proxy localhost:3000
}

Das ist die gesamte Konfiguration. Caddy ruft beim ersten Request automatisch ein Let's-Encrypt-Zertifikat ab. Führe caddy run --config Caddyfile aus (oder verwende die systemd-Unit). Vollständige Referenz: Caddy-Dokumentation.

Der Cloudflare-Tunnel-Pfad — cloudflared tunnel create open-webui, route einen Hostnamen in deiner Cloudflare-Zone, dann cloudflared tunnel run. Keine offenen Ports, Cloudflare handhabt TLS. Ideal für "Ich möchte mein Team darauf haben, ohne Löcher in meine Firewall zu schlagen."

Eine harte Regel: Exponiere Port 3000 niemals roh ins öffentliche Internet. Open WebUIs Anmeldung ist standardmäßig offen — jeder, der deine URL trifft, kann ein Konto erstellen. WEBUI_AUTH=False ist für LAN in Ordnung, niemals für öffentliche Nutzung. Stelle immer einen Reverse-Proxy plus authentifizierte Anmelde-Whitelisting davor (Admin → Einstellungen → Allgemein → "Anmeldung aktivieren" nach der Erstellung deiner Konten deaktivieren).

Wie Techsy Lokale LLM-Bereitstellungen Angeht

Wir haben Open WebUI + Ollama-Setups für Kunden in Recht, Gesundheitswesen und internen Tooling-Teams geliefert, die keine Daten an OpenAI senden können (oder wollen). Die Muster wiederholen sich genug, dass wir aufgehört haben, sie von Grund auf zu schreiben — aber jede Bereitstellung hat dieselben drei Prioritäten.

Was wir tatsächlich tun:

• Modell entsprechend Hardware und Budget dimensionieren. Der 3B–8B-Bereich trifft den Sweet Spot öfter als nicht. Größer ist nicht immer besser, wenn Latenz und monatliche Kosten wichtig sind.
• Die Bereitstellung absichern. Caddy davor, Anmeldung deaktiviert, /app/backend/data auf einem gesicherten Named Volume, wöchentliche Snapshots und ein tatsächlicher Disaster-Recovery-Plan.
• Pipelines für organisationsspezifische Bedürfnisse verdrahten. PII-Schwärzungsfilter, benutzerdefinierte RAG-Pipelines, die auf interne SharePoint- oder Confluence-Instanzen zeigen, Funktionsaufruf-Tools für sicheren Shell-Zugriff — die Dinge, die eine Chat-UI innerhalb eines Unternehmens tatsächlich nützlich machen.

Wenn du lieber das Setup überspringen und einen laufenden privaten KI-Stack übergeben bekommen möchtest, buche eine kostenlose Beratung. Wir freuen uns, den Umfang zu besprechen.

Zusammenfassung

Drei kurze Zusammenfassungen:

• Single-Container-Pfad — schnellster Weg zum ersten Chat, zehn ehrliche Minuten auf einer warmen Maschine.
• Docker Compose — was du tatsächlich für alles willst, das einen Neustart überleben muss.
• Pipelines + RAG + MCP — der Graben, der Open WebUI die Wahl gegenüber LM Studio oder Jan wert macht.

Du chattest in zehn Minuten mit deiner eigenen KI. Von dort an ist alles inkrementell — füge RAG hinzu, wenn du Dokumente hast, füge Caddy hinzu, wenn du es auf deinem Telefon willst, füge Pipelines hinzu, wenn du willst, dass es echte Arbeit leistet. Wenn du tiefer in die lokale Modellauswahl einsteigen möchtest, behandelt unser Leitfaden zum lokalen Ausführen von LLMs die Hardware-Seite ausführlich.

FAQ

Wie installiere ich Open WebUI mit Ollama?

Drei Schritte: Installiere Docker Desktop, installiere Ollama (curl -fsSL https://ollama.com/install.sh | sh unter macOS/Linux), dann führe den kanonischen Open WebUI-Container aus mit docker run -d -p 3000:8080 --add-host=host.docker.internal:host-gateway -v open-webui:/app/backend/data --name open-webui ghcr.io/open-webui/open-webui:main. Öffne http://localhost:3000 und erstelle dein Admin-Konto.

Ist Open WebUI kostenlos?

Ja — Open WebUI ist MIT-lizenziert und vollständig quelloffen. Self-Hosting ist kostenlos; du zahlst nur für die Hardware, die es ausführt (dein Laptop, ein Homelab-Server oder eine Cloud-VM). Optionale bezahlte Komponenten umfassen OpenAIs TTS-API für Sprache oder kommerzielle Modelle, auf die über den OpenAI-kompatiblen Connector von Open WebUI zugegriffen wird. Alles Kernmäßige ist kostenlos.

Kann Open WebUI ohne Ollama laufen?

Ja — Open WebUI spricht mit jeder OpenAI-kompatiblen API. Du kannst es direkt auf OpenAI, Anthropic über einen LiteLLM-Proxy, vLLM-Server, den HTTP-Server von llama.cpp oder gehostete Anbieter wie Groq und Together zeigen. Aber "Open WebUI + Ollama" ist die kanonische lokale KI-Kombination, weil Ollama die Modellverwaltung kinderleicht macht.

Warum kann Open WebUI keine Verbindung zu Ollama herstellen?

Häufigste Ursache: fehlender --add-host=host.docker.internal:host-gateway-Flag und OLLAMA_BASE_URL nicht in den Open WebUI-Einstellungen gesetzt. Zweithäufigste: Ollama nur an 127.0.0.1 gebunden, vom Container aus nicht erreichbar — behebe mit OLLAMA_HOST=0.0.0.0:11434 ollama serve. Führe docker exec open-webui curl http://host.docker.internal:11434/api/tags zur schnellen Diagnose aus.

Wie füge ich Modelle zu Open WebUI hinzu?

Einfachster Weg: Führe vom Host aus ollama pull llama3.2:3b aus (oder ein beliebiges Modell von ollama.com/library). Das Modell erscheint automatisch im Dropdown von Open WebUI — kein Neustart erforderlich. Alternativ gehe in Open WebUI zu Admin → Einstellungen → Verbindungen → Ollama und verwende den In-UI-Pull-Button. In jedem Fall leben die Modelle auf der Ollama-Seite.

Was ist der Unterschied zwischen Open WebUI und LM Studio?

LM Studio ist eine Einzelbenutzer-Desktop-App, die sich auf Modellverwaltung plus Chat konzentriert — starke GPU-Standards, schicke UI, kein Mehrbenutzer. Open WebUI ist ein selbst gehosteter Server, der mehrere Benutzer, natives RAG, Sprach-I/O, Pipelines/Functions und MCP unterstützt. Unterschiedliche Zielgruppen: LM Studio für Solo-Desktop-Power-User, Open WebUI für Teams oder jeden, der ein erweiterbares privates ChatGPT möchte.

Kann ich Open WebUI auf einem Telefon verwenden?

Ja — Open WebUI ist vollständig responsiv, sodass jeder mobile Browser funktioniert. Kombiniere es mit HTTPS (Caddy mit einem Let's-Encrypt-Zertifikat oder einem Cloudflare-Tunnel) und es wird zu einer vollständig funktionalen mobilen Chat-App. Füge es deinem Home-Screen unter iOS oder Android für ein nahezu natives PWA-Erlebnis hinzu. Exponiere es ohne Auth nicht öffentlich.

Wie aktualisiere ich Open WebUI?

Hole das neueste Image und starte neu: docker pull ghcr.io/open-webui/open-webui:main && docker stop open-webui && docker rm open-webui, dann führe deinen ursprünglichen docker run-Befehl erneut aus. Benannte Volumes bewahren alle Daten — Chat-Verlauf, Benutzer, RAG-Sammlungen und Einstellungen. Mit Docker Compose: docker compose pull && docker compose up -d. Updates erscheinen etwa wöchentlich.

Unterstützt Open WebUI Sprach-Chat?

Ja — sowohl Sprache-zu-Text (über lokales faster-whisper) als auch Text-zu-Sprache (über OpenAIs TTS-API oder lokales coqui-tts). Konfiguriere beide unter Admin → Einstellungen → Audio. Einmal aktiviert, erscheint ein Mikrofon-Symbol im Chat-Feld. Das pragmatische Setup ist lokaler Whisper plus OpenAI TTS — vollständig offline-Eingabe, schnelle saubere Ausgabe. Sieh den Abschnitt Sprach-I/O oben für die Umgebungsvariablen-Konfiguration.

Wie füge ich meine PDFs zu Open WebUI hinzu?

Klicke auf dein Profil → Workspace → Wissen → Neue Sammlung, dann lade PDFs, Word-Dokumente, Markdown oder Textdateien hoch. Open WebUI teilt die Dokumente auf, bettet sie mit nomic-embed-text ein (lade es zuerst über ollama pull nomic-embed-text herunter) und speichert sie in ChromaDB. Referenziere eine beliebige Sammlung im Chat mit #sammlungsname oder füge sie dauerhaft an ein Custom-Modell an.