Open WebUI Wissensdatenbank automatisch aktuell halten: Sync-Ordner, Upload oder oikb

Wissensquellen mit Open WebUI verbinden? WZ-IT betreibt Open WebUI als KI-Plattform mit Wissensbereichen und richtet auf Wunsch die automatische Anbindung Ihrer Quellen ein, zum Beispiel Confluence, GitHub oder Dateiablagen. Mehr zu Funktionen und Varianten unter Open WebUI als KI-Plattform. Termin vereinbaren

Eine Wissensdatenbank in Open WebUI ist nur so gut wie ihr Stand. Wer Dokumente einmal hochlädt, hat in dem Moment eine veraltete Kopie, in dem sich die Quelle ändert: Das Handbuch im Wiki wird überarbeitet, die Produktdokumentation im Repository bekommt einen neuen Commit, in der Ablage landen neue Verträge. Das Modell antwortet dann mit Wissen von gestern, und niemand merkt es.

Dafür gibt es seit Open WebUI 0.9.6 oikb, das offizielle Zusatzwerkzeug zur Synchronisierung. Es hält eine Wissensdatenbank mit einer lebenden Quelle auf dem gleichen Stand, nach Zeitplan, bei jedem Push oder auf Abruf. Dieser Beitrag ordnet ein: Welche Wege es gibt, Wissen in Open WebUI zu bekommen, wann sich welcher lohnt, welche Anbindungen oikb mitbringt, wie der Betrieb aussieht und wo die Grenzen liegen. Alle Angaben haben den Stand Oktober 2026 und stützen sich auf die Dokumentation von Open WebUI.

Hinweis: Dieser Beitrag ist keine Rechtsberatung. Aussagen zu Datenschutz und Berechtigungen sind technische Einordnungen.

Inhaltsverzeichnis

1. oikb in Kürze
2. Wege in die Wissensdatenbank im Vergleich
3. Entscheidungsleitfaden
4. So funktioniert der inkrementelle Sync
5. Die Anbindungen im Überblick
6. Einsatzszenarien
7. Betrieb: Daemon, Webhooks und Sicherheit
8. Grenzen und Stolpersteine
9. Datenschutz und Berechtigungen bei Anbindungen
10. Unser Vorgehen bei WZ-IT
11. Weiterführende Guides

oikb in Kürze

oikb ist ein eigenständiges Programm, nicht Teil des Open-WebUI-Servers. Es besteht aus einer Kommandozeile und einem optionalen Daemon und spricht Open WebUI über die normale REST-API an (Doku zu oikb).

Der Kern ist der Unterschied zu einem einmaligen Upload: oikb verbindet eine Wissensdatenbank einmal mit einer Quelle und hält sie danach aktuell. Eine unveränderte Quelle löst nichts aus, weil nichts neu hochgeladen, neu extrahiert oder neu eingebettet wird.

Wege in die Wissensdatenbank im Vergleich

Es gibt mehrere Wege, Inhalte in eine Open-WebUI-Wissensdatenbank zu bringen. Sie unterscheiden sich in Aufwand, Aktualität und Skalierung.

Seit Version 0.9.6 ist auch die Synchronisierung in der Oberfläche nicht mehr destruktiv: Der Client hasht die Dateien, der Server vergleicht und fasst nur neue, geänderte und gelöschte Dateien an. Vorher wurde alles gelöscht und neu hochgeladen (Doku zu Wissensdatenbanken).

Entscheidungsleitfaden

Die Wahl hängt an vier Fragen:

1. Wie groß ist der Bestand? Bei kleinen Beständen reicht der Upload oder der Sync-Ordner. Bei Tausenden Dateien oder mehreren Gigabyte empfiehlt Open WebUI selbst oikb, weil es nativ mit parallelen Uploads und Wiederholungen arbeitet.
2. Wie aktuell muss das Wissen sein? Ändert sich die Quelle selten, genügt ein manueller Lauf. Soll das Modell immer den Stand von heute kennen, braucht es den Daemon mit Zeitplan oder Webhook.
3. Wo liegt die Quelle? Lokale Ordner, Repositories, Wikis, Ticketsysteme oder Cloud-Speicher decken die Anbindungen von oikb ab. Für proprietäre Fachsysteme ohne Anbindung bleibt ein eigenes Skript gegen die API.
4. Wer betreibt es? oikb ist ein zusätzlicher Dienst mit Zugangsdaten, Zeitplan und Überwachung. Das lohnt, wenn jemand dafür zuständig ist. Sonst ist ein betreuter Betrieb die bessere Wahl.

Als Faustregel: einzelne Dokumente hochladen, einen Ordner im Browser synchronisieren, ab größeren oder lebenden Quellen oikb, und für Dauerbetrieb den Daemon.

So funktioniert der inkrementelle Sync

oikb scannt die Quelle und berechnet für jede Datei eine SHA-256-Prüfsumme. Es schickt ein Manifest mit Pfad, Dateiname, Prüfsumme und Größe, aber ohne Dateiinhalt, an den Endpunkt /sync/diff von Open WebUI. Der Server antwortet, was hinzugekommen ist, sich geändert hat und gelöscht wurde, dazu welche Verzeichnisse anzulegen oder zu entfernen sind. Dieser Aufruf verändert nichts.

Danach löscht oikb die veralteten Dateien und leeren Verzeichnisse, legt fehlende Verzeichnisse an und lädt nur neue und geänderte Dateien hoch, jeweils mit ihrem Hash, damit der Server nicht erneut hasht. Fehler vom Typ HTTP 5xx werden bis zu dreimal mit wachsender Wartezeit wiederholt. Standardmäßig laufen Uploads nacheinander, mit --concurrency N laufen N Dateien parallel (Doku zu oikb).

Eine kurze Ausgabe zeigt, was ein Lauf tut:

$ oikb sync github:acme/handbook --kb-id 8f3a2b1c-...
  1,204 files found
  Diff: +3, ~1, -2, 1198 unchanged
Sync complete: 3 added, 1 modified, 2 deleted, 1198 unchanged

Mit --dry-run zeigt oikb vorab, was sich ändern würde, ohne etwas hochzuladen. Das ist der sichere Einstieg, bevor eine produktive Wissensdatenbank angebunden wird.

Die Anbindungen im Überblick

Eine Quelle ist entweder ein lokaler Pfad oder eine Zeichenkette der Form schema:ziel. oikb löst das Schema auf einen Connector auf, holt die Dateien und gleicht sie ab. Zugangsdaten stehen nie in der Quellenangabe oder in der Konfigurationsdatei, sondern kommen aus Umgebungsvariablen. Eine Auswahl aus der Dokumentation:

Einige Anbindungen brauchen ein Zusatzpaket des Anbieters, etwa pip install oikb[s3] für Amazon S3. GitHub wird über die Trees-API gelesen, ein lokaler Klon ist nicht nötig. Chat-Verläufe werden nach Tagen aufgeteilt, damit der Sync wirklich inkrementell bleibt: Vergangene Tage ändern sich nicht und werden nie erneut hochgeladen.

Der Umfang lässt sich eingrenzen: mit Include- und Exclude-Mustern, einer Größenobergrenze und einer .oikbignore-Datei im Stammordner. Eine Quelle lässt sich außerdem auf mehrere Wissensdatenbanken aufteilen, etwa Dokumentation und Quellcode eines Repositorys.

Einsatzszenarien

Die Dokumentation nennt typische Szenarien, die sich für Unternehmen übertragen lassen:

• Produktdokumentation, die immer aktuell ist. Das Dokumentations-Repository wird bei jedem Merge in der CI oder per Webhook synchronisiert. Support und Kunden fragen einen Bestand ab, der höchstens einen Commit alt ist.
• Handbuch aus dem Wiki. Ein Confluence-Space oder ein Notion-Arbeitsbereich wird morgens per Cron gespiegelt. Ein Assistent für interne Fragen antwortet aus dem aktuellen Handbuch, Änderungen im Wiki sind am nächsten Tag drin.
• Supportwissen aus Tickets. Gelöste Fälle aus Zendesk oder Jira landen in einer Wissensdatenbank, damit ein Triage-Modell sieht, wie ähnliche Probleme gelöst wurden.
• Code-bewusster Assistent. Ein Repository wird per Filter auf zwei Wissensdatenbanken verteilt: Prosa unter docs/** und Quellcode unter src/**.
• Dokumentenablagen. Verträge, Richtlinien oder Berichte in S3, SharePoint oder einer Dateiablage werden regelmäßig abgeglichen, damit neue Dokumente ohne Handarbeit auffindbar sind.

Welches Szenario passt, hängt von den Quellen ab. Wer vorher klärt, welche Inhalte das Modell sehen darf, vermeidet den häufigsten Fehler: ganze Ablagen anzubinden, in denen vertrauliche oder veraltete Dokumente liegen.

Betrieb: Daemon, Webhooks und Sicherheit

Der Daemon führt mehrere Quellen aus einer Konfigurationsdatei .oikb.yaml aus. Pro Eintrag stehen Quelle, Wissensdatenbank-ID und optional Intervall, Webhook und Benachrichtigung (Doku zum Daemon).

• Zeitplan. Intervalle wie 30m, 1h oder 1d oder Cron-Ausdrücke wie 0 6 * * 1-5 (werktags 6 Uhr).
• Webhooks. Für GitHub (HMAC-Signatur), GitLab (Token), Slack (Signatur) und Confluence (nach Space-Schlüssel). Läuft gerade ein Sync, wird ein ausgelöster Webhook übersprungen.
• HTTP-API. GET /health, GET /health/ready und GET /metrics sind öffentlich, POST /sync/{name-oder-kb-id} verlangt den API-Schlüssel OIKB_API_KEY.
• Beobachtung. Prometheus-Metriken wie oikb_sync_total und oikb_sync_duration_seconds, JSON-Logs mit LOG_FORMAT=json, Verlauf in SQLite und Benachrichtigung per HTTP-POST bei Fehlern.
• Container. Image ghcr.io/open-webui/oikb, in Compose oder Kubernetes mit ConfigMap für die Konfiguration und Secret für die Schlüssel. Der Daemon ist für ein Replikat gedacht, weil Zeitplan und Sperren pro Wissensdatenbank in einem Prozess liegen.
• Modellgesteuert. Der Daemon bietet unter /openapi.json drei Werkzeuge: Sync starten, Status abfragen, Verlauf abrufen. Ein Modell kann so im Gespräch eine Aktualisierung anstoßen, sofern ein API-Schlüssel gesetzt ist.

Zur Sicherheit empfiehlt die Dokumentation, keine Geheimnisse in die Konfigurationsdatei zu schreiben, in Produktion dateibasierte Secrets zu bevorzugen und den Daemon ohne gesetzte Webhook-Geheimnisse nur in vertrauenswürdigen Netzen zu erreichen.

Grenzen und Stolpersteine

• Version. Ohne Open WebUI 0.9.6 oder neuer gibt es nichts, was oikb aufrufen könnte.
• API-Schlüssel. Sie sind standardmäßig aus. Ein Admin muss sie freischalten, und Nutzer ohne die Berechtigung sehen keine Schlüsselverwaltung. Auch bei gültigem Schlüssel gibt es 403, wenn Endpunkt-Beschränkungen /api/v1/knowledge und /api/v1/files nicht erlauben oder dem Nutzer das Schreibrecht an der Wissensdatenbank fehlt.
• Indexierung läuft serverseitig. oikb lädt schnell hoch, die Einbettung geschieht danach asynchron. Dateien erscheinen erst nach Abschluss in der Dateiliste.
• Dateigrenzen. Hat ein Admin eine maximale Uploadgröße oder erlaubte Dateiendungen gesetzt, scheitern passende Dateien bei jedem Lauf mit HTTP 413 oder 400, bis sie per Filter ausgeschlossen werden.
• Ein Daemon, ein Replikat. Mehr Quellen gehören als weitere Einträge in einen Daemon, nicht in mehrere Kopien.
• oikb reset. Der Befehl löscht alle Dateien der Wissensdatenbank, nicht nur die von oikb hochgeladenen. Er fragt nach, aus gutem Grund.
• Aufbewahrung. Beim Aufräumen löscht der Server den Datensatz und die gespeicherten Bytes einer veralteten Datei, außer ENABLE_KNOWLEDGE_FILE_RETENTION=true ist gesetzt, die Datei hängt an einer weiteren Wissensdatenbank oder der Nutzer des Schlüssels ist weder Eigentümer der Datei noch Admin.

Datenschutz und Berechtigungen bei Anbindungen

Jede Anbindung ist ein Datenfluss. Bei lokalen Ordnern und Repositories im eigenen Netz bleibt er intern. Bei Confluence Cloud, Slack, Gmail oder Zendesk fließen Inhalte aus diesen Diensten in Ihre Open-WebUI-Instanz, werden eingebettet und fließen in die Antworten des Modells ein. Vorab zu klären:

1. Inhalte. Welche personenbezogenen oder vertraulichen Daten liegen in der Quelle, und müssen sie in die Wissensdatenbank?
2. Zugriff. oikb arbeitet mit den Rechten des API-Schlüssel-Nutzers und umgeht keine Zugriffskontrolle in Open WebUI. Gehen Sie davon aus, dass alles, was das Konto der Anbindung in der Quelle lesen darf, in der Wissensdatenbank landet. Legen Sie die Freigaben der Wissensdatenbank deshalb unabhängig von den Rechten in der Quelle fest.
3. Zugangsdaten. Jeder Connector liest seine Schlüssel aus Umgebungsvariablen. Vergeben Sie dafür Konten mit minimalen Leserechten auf die gewünschte Quelle.
4. Modellweg. Wohin die Inhalte nach der Einbettung fließen, entscheidet die Modellanbindung. Wer das Modell in Deutschland betreibt, hält den Datenfluss im eigenen Rahmen.

Das ist eine technische Einordnung. Die rechtliche Bewertung, etwa zu Auftragsverarbeitung oder besonderen Berufsgeheimnissen, gehört in Ihre Datenschutzprüfung.

Unser Vorgehen bei WZ-IT

WZ-IT betreibt Open WebUI als KI-Plattform und als Managed Hosting nach Compute-Größe, jeweils mit sichtbarem Original-Branding. Für diese Instanzen richten wir auf Wunsch die Anbindung Ihrer Wissensquellen mit oikb ein. Die Voraussetzung, Open WebUI 0.9.6 oder neuer, ist bei uns erfüllt, weil wir Open WebUI in der jeweils aktuellen Version betreiben.

Vor dem Einrichten klären wir mit Ihnen:

1. Quellen und Inhalte. Welche Systeme sollen angebunden werden und welche Inhalte dürfen in die Wissensdatenbank?
2. Berechtigungen. Wer darf welche Wissensdatenbank nutzen, und mit welchen Konten greift die Synchronisierung auf die Quellen zu?
3. Zeitplan. Täglicher Lauf, Webhook bei Änderungen oder manueller Abruf?
4. Betrieb. Überwachung der Läufe, Benachrichtigung bei Fehlern, Aktualisierung von oikb und Open WebUI.

Der Umfang wird im Angebot festgelegt. Wer Open WebUI im eigenen Netz betreibt, findet den Weg dorthin über den AI Cube.

Weiterführende Guides

• Open WebUI als KI-Plattform, Funktionen, Betriebsvarianten und Pakete.
• RAG-Wissensdatenbank in Behörden, was bei öffentlichen Auftraggebern zu beachten ist.
• RAG und KI-Verordnung, wann eine Wissensdatenbank zum Hochrisiko-System wird.
• Open WebUI Lizenz und Branding, was die Branding-Klausel für Unternehmen bedeutet.
• Open WebUI vs. AnythingLLM, der Vergleich beider Oberflächen.
• Open WebUI unter Linux installieren, Installer-Skript mit Docker und Caddy.
• Onyx self-hosted, Enterprise-Suche als Alternative.
• Schatten-KI im Unternehmen, wie eine freigegebene interne Alternative aussieht.
• KI-Lösungen von WZ-IT, der Hub mit allen Angeboten zu lokaler KI und LLM-Betrieb.

Open WebUI mit Ihren Wissensquellen verbinden? Wir richten die automatische Anbindung Ihrer Quellen für Open-WebUI-Instanzen von WZ-IT ein und betreiben sie. Quellen, Berechtigungen und Zeitplan klären wir vorab. Termin vereinbaren

Quellen

• Open WebUI, Knowledge Base Sync (oikb)
• Open WebUI, oikb Daemon, Webhooks und Deployment
• Open WebUI, Wissensdatenbanken und Sync-API
• oikb, GitHub-Repository
• Open WebUI, Release v0.9.6