Onyx self-hosted: Installation, Lizenz und Vergleich mit Open WebUI

Onyx im eigenen Netz statt in der Cloud? WZ-IT installiert und betreibt Onyx auf Ihrer Infrastruktur, bindet Datenquellen und lokale Modelle an und übernimmt Updates und Monitoring. Weitere Bausteine im KI-Hub. Termin vereinbaren

Onyx ist eine Open-Source-Plattform, die Unternehmenswissen aus vielen Anwendungen in einen gemeinsamen Suchindex holt und darüber KI-Antworten mit Quellenangaben erzeugt. Das Projekt hieß früher Danswer. Es gehört zu den wenigen Open-Source-Werkzeugen, die Konnektoren, Synchronisation und die Übernahme von Berechtigungen aus Quellsystemen mitbringen, und damit zu den Kandidaten für eine selbst betriebene Alternative zu Microsoft 365 Copilot oder Atlassian Rovo.

Deutschsprachige Informationen zu Onyx gibt es kaum. Dieser Beitrag fasst zusammen, was die Community Edition kann und was nur die Enterprise Edition bietet, welche Konnektoren es gibt, welche Ressourcen Onyx braucht, wie die Installation per Docker Compose abläuft, wie lokale Modelle angebunden werden und wie sich Onyx von der Knowledge-Funktion in Open WebUI unterscheidet. Alle Angaben beziehen sich auf Onyx 4.8.0, Stand September 2026.

Inhaltsverzeichnis

1. Was Onyx ist
2. Community Edition und Enterprise Edition
3. Konnektoren und Berechtigungen
4. Systemanforderungen von Onyx
5. Onyx per Docker Compose installieren
6. Lokale Modelle und Embeddings anbinden
7. Onyx im Vergleich mit Open WebUI Knowledge
8. Stolpersteine im Betrieb
9. Unser Vorgehen bei WZ-IT
10. Weiterführende Guides

Was Onyx ist

Onyx beschreibt sich als Wissens- und Kontextschicht für Teams und KI-Agenten (Onyx README). Die Plattform zieht Inhalte, Metadaten und Berechtigungen aus angebundenen Anwendungen, speichert sie in einem hybriden Index aus Vektor- und Keyword-Suche und stellt sie über Chat, Suche und Agenten bereit. Eine Einführung in das Prinzip gibt der Artikel Was ist RAG?.

Neben Suche und Chat bringt Onyx Deep Research, eigene Agenten mit abgegrenztem Wissen, Aktionen über MCP und OpenAPI, Websuche (unter anderem über SearXNG) und eine Sandbox für Code mit. Für eine Wissensdatenbank im Unternehmen sind Konnektoren, Index und Rechtemodell der Kern. Die übrigen Funktionen lassen sich später ergänzen.

Community Edition und Enterprise Edition

Onyx gibt es in zwei Editionen (Onyx README, Licensing). Die Grenze ist im Repository klar gezogen: Code in den ee-Verzeichnissen (backend/ee, web/src/app/ee, web/src/ee) steht unter der Onyx Enterprise License, alles andere unter der MIT-Lizenz (LICENSE). Für selbst betriebene Instanzen wird nach dem Abschluss eines Plans eine Lizenz ausgestellt, die lokal gespeichert und geprüft wird; für Air-Gap-Umgebungen ist ein manueller Lizenz-Upload vorgesehen (Plans & Billing).

Quellen der Tabelle: Plans & Billing, SSO Providers und Enterprise Edition. Aktuelle Preise stehen auf onyx.app/pricing.

Die Onyx-Dokumentation nennt als typische Kandidaten für die Enterprise Edition Organisationen mit mehr als 100 Nutzern, Umgebungen mit SSO-Pflicht und Instanzen, die Berechtigungen aus externen Systemen erben müssen. Der letzte Punkt entscheidet in der Praxis am häufigsten: Sobald Inhalte mit unterschiedlichen Leserechten in einen gemeinsamen Index laufen, reicht die Community Edition nur, wenn die Wissensbereiche vorab so geschnitten werden, dass jede Nutzergruppe alles sehen darf. Warum das so ist, beschreibt der Artikel zu Berechtigungen in RAG-Systemen.

Konnektoren und Berechtigungen

Die Dokumentation listet 54 offizielle Konnektoren (Connectors Overview). Fast alle synchronisieren laufend: Standardmäßig holt Onyx alle 30 Minuten Änderungen ab und entfernt alle 30 Tage Inhalte, die in der Quelle nicht mehr existieren. Ohne Startdatum liest der erste Durchlauf die gesamte Historie einer Quelle, was bei großen Beständen laut Dokumentation Tage dauern kann.

Der Datei-Konnektor verarbeitet hochgeladene Dateien in den Formaten TXT, PDF, DOCX, PPTX, XLSX, CSV, Markdown, JSON, XML, YAML, EML, EPUB und weiteren, auch als ZIP-Archiv. Über eine Metadatenzeile am Dateianfang lassen sich Link, Verantwortliche, Änderungsdatum und eigene Tags mitgeben.

Drei Zugriffsarten je Konnektor. Ein Konnektor ist privat (nur Ersteller sowie zugewiesene Nutzer und Gruppen), öffentlich (alle Onyx-Nutzer) oder auf „Auto Sync Permissions" gestellt. Nur im letzten Fall übernimmt Onyx die Zugriffslisten der Quelle. Diese Rechteübernahme ist eine Funktion der Enterprise Edition und steht nur für diese Konnektoren bereit:

Was fehlt. Einen Konnektor für Nextcloud, WebDAV oder SMB-Freigaben gibt es in der offiziellen Liste nicht (Stand September 2026). Für Unternehmen, deren Dokumente in Nextcloud liegen, bleiben der Web-Crawler, der Datei-Upload oder ein eigener Konnektor über die Onyx-API. Rechte aus Nextcloud übernimmt keiner dieser Wege. Welche Optionen es für Nextcloud, SharePoint und Dokumentenmanagementsysteme allgemein gibt, zeigt der Artikel zu RAG-Datenquellen, die Kombination mit Open WebUI der Artikel RAG mit Nextcloud und Open WebUI.

Systemanforderungen von Onyx

Onyx kennt zwei Betriebsarten (Deployment Overview). Onyx Standard enthält Vektor- und Keyword-Index, Hintergrund-Worker für die Konnektoren, zwei Model-Server für Embeddings und Reranking sowie Redis und MinIO. Onyx Lite ist eine Chat-Oberfläche mit Agenten, Datei-Uploads und Projekten, aber ohne Index. Für eine Wissensdatenbank mit Konnektoren kommt nur Standard in Frage.

Quelle: Resourcing, Stand September 2026. Für eine Verteilung auf Kubernetes nennt die Dokumentation diese Anforderungen je Dienst:

Zusammen ergibt das rund 12 CPU und 24 GB RAM. Werden Embeddings über eine externe API statt lokal berechnet, brauchen die beiden Model-Server deutlich weniger Speicher.

Wie der Bedarf mit der Datenmenge wächst. Haupttreiber ist die Menge indexierter Dokumente, die in OpenSearch landet. Der Speicherbedarf auf der Platte liegt bei einer Einzelinstanz ohne Replikate bei etwa dem 1,45-Fachen der Quelldaten. Für den Arbeitsspeicher von OpenSearch gibt die Dokumentation Richtwerte je GB Quelldaten an:

Das Rechenbeispiel der Dokumentation: 10 GB Textinhalt ergeben für OpenSearch 4 GB Grundbedarf plus 10 × 1,5 GB, also 19 GB RAM, und 4,5 CPU-Kerne. Auf einer einzelnen Maschine kommen die übrigen Dienste hinzu, insgesamt mindestens 9 CPU und 35 GB RAM. Der JVM-Heap von OpenSearch sollte die Hälfte des verfügbaren Speichers bekommen und 32 GB nicht überschreiten.

Diese Werte betreffen nur Onyx selbst. Ein lokales Sprachmodell läuft als eigener Dienst mit eigenem GPU-Bedarf. Wie viel VRAM welches Modell braucht, steht im Artikel GPU- und VRAM-Sizing für LLMs.

Onyx per Docker Compose installieren

Die Dokumentation beschreibt zwei Wege zur Docker-Compose-Installation: den geführten Installer der Onyx-CLI und die manuelle Einrichtung aus dem Repository.

Weg 1: Onyx-CLI. Der empfohlene Weg ist onyx-cli deploy install (Quickstart). Das Skript install_onyx.sh installiert nur die CLI und ruft denselben Befehl auf.

uv tool install onyx-cli
onyx-cli deploy install

Der Installer prüft RAM, Festplatte und freie Ports, installiert unter Linux nach Rückfrage Docker Engine und das Compose-Plugin, fragt nach Betriebsart (Lite oder Standard) und Version, legt eine .env mit zufällig erzeugten Secrets an und startet die Container, bis alle Dienste als gesund gemeldet werden (Onyx CLI). Die Konfiguration liegt unter ~/.config/onyx, die Daten in benannten Docker-Volumes.

Mit --offline lässt sich Onyx aus bereits vorhandenen Images ohne Netzzugang ausrollen. Das ist die Grundlage für abgeschottete Umgebungen.

Weg 2: manuell aus dem Repository (Docker):

git clone --depth 1 https://github.com/onyx-dot-app/onyx.git
cd onyx/deployment/docker_compose
docker compose up -d

Nach der Initialisierung ist Onyx unter Port 3000 erreichbar. Die Compose-Datei von Version 4.8.0 startet diese Dienste:

Vor dem Produktivbetrieb. Die Compose-Datei enthält selbst eine Checkliste (docker-compose.yml). Beim manuellen Weg sind vor allem vier Punkte offen:

• Version festlegen. Die Vorlage env.template setzt IMAGE_TAG=latest. Für einen reproduzierbaren Betrieb gehört dort eine feste Version wie v4.8.0 hin.
• Passwörter ersetzen. OpenSearch startet ohne gesetzte Variable mit dem Standardpasswort aus der Compose-Datei, MinIO mit Standardzugangsdaten. OPENSEARCH_ADMIN_PASSWORD, die MinIO-Zugangsdaten und USER_AUTH_SECRET sind vor dem Start zu setzen.
• Ports schließen. Außer nginx sollte kein Dienst nach außen lauschen.
• TLS einrichten. Entweder über den vorbereiteten Certbot-Dienst oder über einen vorgelagerten Reverse Proxy.

Die CLI erzeugt die Secrets automatisch und ist deshalb für neue Installationen der sauberere Weg. Für größere Umgebungen gibt es ein Helm-Chart, das Dienste einzeln skalieren lässt.

Lokale Modelle und Embeddings anbinden

Onyx trennt zwei Modellarten: das Sprachmodell für Antworten und das Embedding-Modell für den Index.

Sprachmodell. Anbieter werden in der Verwaltungsoberfläche unter „Configuration → Language Models" eingetragen. Für den Betrieb ohne US-Cloud sind drei Wege relevant:

Für jeden Anbieter lässt sich festlegen, welche Modelle sichtbar sind und ob er allen Nutzern oder nur bestimmten Gruppen zur Verfügung steht. Wie ein zentrales Gateway vor mehreren Modellen aussieht, erklärt der Artikel Was ist LiteLLM?. Wer europäische Modell-APIs statt eigener Hardware nutzen möchte, findet einen Vergleich im Beitrag zu europäischen LLM-APIs.

Embedding-Modell. Das Embedding-Modell wird unter „Search Settings" gewählt (Index Settings). Voreingestellt ist im Quellcode nomic-ai/nomic-embed-text-v1 mit 768 Dimensionen (configs.py), ein vorwiegend englisch trainiertes Modell. Unter den vorgeschlagenen selbst betriebenen Modellen finden sich mehrsprachige Varianten wie intfloat/multilingual-e5-base und intfloat/multilingual-e5-small (embedding_configs.py); eigene Modelle lassen sich ebenfalls anbinden. Für deutschsprachige Bestände ist die Wahl des Embedding-Modells eine der wichtigsten Stellschrauben, siehe den Vergleich der Embedding-Modelle für Deutsch.

Ein Wechsel des Embedding-Modells löst eine vollständige Neuindexierung aus. Während der Umstellung bleibt das alte Modell für Suchen aktiv. Deshalb gehört die Modellwahl an den Anfang eines Projekts, nicht ans Ende.

Weitere Sucheinstellungen. Auf derselben Seite lassen sich Reranking, mehrsprachige Anfrageerweiterung, Multipass-Indexierung mit Chunks unterschiedlicher Größe, Contextual RAG und die Genauigkeit der Embeddings (bfloat16 oder float) einstellen. Contextual RAG ergänzt jeden Chunk um Informationen zum Gesamtdokument und ist laut Dokumentation sehr aufwendig in der Berechnung. Die Hintergründe erklären die Artikel zu Hybrid Search und Reranking, Contextual Retrieval und Chunking.

Für lokale Embeddings empfiehlt die Onyx-Dokumentation dringend eine GPU für den Indexing-Model-Server. WZ-IT stellt dafür Managed GPU-Server mit NVIDIA RTX PRO 4000 Blackwell (24 GB) oder RTX PRO 6000 Blackwell (96 GB) bereit; für den Betrieb im eigenen Netzwerk gibt es den AI Cube.

Onyx im Vergleich mit Open WebUI Knowledge

Onyx und Open WebUI werden oft gemeinsam genannt, setzen aber an unterschiedlichen Stellen an. Open WebUI ist in erster Linie eine Chat-Oberfläche für lokale und entfernte Modelle, deren Knowledge-Funktion Dokumente in Wissensbereiche aufnimmt (Open WebUI Knowledge). Onyx ist in erster Linie eine Such- und Wissensschicht über vielen Unternehmensquellen.

Die Lizenz von Open WebUI verbietet seit Version 0.6.6, das Branding „Open WebUI" zu entfernen, außer bei höchstens 50 Nutzern in 30 Tagen, mit schriftlicher Erlaubnis oder mit einer Enterprise-Lizenz (Open WebUI License).

Wann Onyx passt: Viele Quellen wie Confluence, Jira, SharePoint und Teams sollen gemeinsam durchsuchbar sein, Inhalte ändern sich laufend, und die Leserechte der Quellsysteme müssen im Index gelten. Letzteres setzt die Enterprise Edition voraus.

Wann Open WebUI passt: Der Chat mit lokalen Modellen steht im Vordergrund, die Wissensbestände sind überschaubar und lassen sich pro Gruppe als eigene Wissensbereiche schneiden, und die Ressourcen sollen gering bleiben. Einen Vergleich von Open WebUI mit AnythingLLM gibt es im Beitrag Open WebUI vs. AnythingLLM.

Beide Werkzeuge schließen sich nicht aus. Onyx lässt sich über seinen MCP-Server als Wissensquelle an andere Clients anbinden, und Open WebUI kann über ein vorgeschaltetes Gateway dieselben Modelle nutzen.

Stolpersteine im Betrieb

• Upgrade von alten Versionen. Seit Version 3 migriert Onyx indexierte Dokumente automatisch von Vespa nach OpenSearch. Wer von einer Version vor 3 direkt auf 4 springt, verliert den Index und muss alle Konnektoren neu indexieren (OpenSearch Migration). Der Weg führt also immer über Version 3.
• Ungepinnte Images. Ohne feste Version zieht die Installation das Tag latest. Die Onyx-Dokumentation rät, auf der jeweils neuesten stabilen Version zu bleiben und Versionen gezielt zu setzen. Bei wöchentlichen Releases gehört ein Update-Fenster in den Betriebsplan.
• Voller Datenträger. OpenSearch setzt Indizes bei 95 Prozent Plattenbelegung auf schreibgeschützt. Neue Dokumente werden dann nicht mehr indexiert. Plattenbelegung gehört ins Monitoring.
• Erste Indexierung. Ohne Startdatum liest ein Konnektor die komplette Historie der Quelle. Bei großen Confluence- oder SharePoint-Beständen ist ein Startdatum oder ein Pilot mit einem Ausschnitt sinnvoll.
• Öffentliche Konnektoren. Wird ein Konnektor mit Zugriff auf vertrauliche Bereiche als öffentlich eingerichtet, sieht jeder Onyx-Nutzer diese Inhalte. In der Community Edition muss der Zuschnitt der Quellen das Rechtemodell ersetzen.
• Neuindexierung beim Modellwechsel. Jeder Wechsel des Embedding-Modells baut den Index neu auf und belastet den Indexing-Model-Server entsprechend.

Unser Vorgehen bei WZ-IT

Wir betreiben Onyx auf Ihrer Infrastruktur oder auf einem Managed GPU-Server von WZ-IT in Deutschland. Support, Beratung und Implementierung erfolgen durch WZ-IT.

1. Quellen und Rechte klären. Welche Systeme angebunden werden, welche Bereiche ausgeschlossen bleiben und ob Rechte aus den Quellsystemen übernommen werden müssen. Daraus folgt die Wahl zwischen Community und Enterprise Edition.
2. Pilot mit echten Fragen. Ein abgegrenzter Bestand mit vereinbarten Referenzfragen und Quellenprüfung, wie im RAG Proof of Value beschrieben.
3. Installation und Härtung. Onyx per Docker Compose oder Kubernetes mit festen Versionen, eigenen Secrets, TLS, SSO und geschlossenen Ports.
4. Modelle anbinden. Lokales Sprachmodell über Ollama oder vLLM, Embedding-Modell passend für deutschsprachige Inhalte, auf Wunsch ein Gateway über LiteLLM.
5. Laufender Betrieb. Updates, Monitoring von Konnektoren, Index und Plattenbelegung sowie Backups, beschrieben auf der Seite Onyx betreiben.

Soll statt einer Such- und Agentenplattform ein Chat mit Wissensbereichen entstehen, setzen wir auf Open WebUI. Für den fertigen Assistenten mit mehreren Wissensbereichen und Rollen gibt es den internen KI-Assistenten.

Weiterführende Guides

• Atlassian Rovo Alternative self-hosted, Wiki und KI-Schicht mit Rechten im eigenen Betrieb.
• Embedding-Modelle für Deutsch im Vergleich, welches Modell deutsche Dokumente gut findet.
• XWiki KI einrichten, die LLM Application von XWiki mit lokalem Modell.
• Hybrid Search und Reranking, warum Vektorsuche allein nicht reicht.
• Open WebUI vs. AnythingLLM, die beiden bekanntesten Chat-Oberflächen im Vergleich.
• KI-Lösungen von WZ-IT, der Hub für lokale Modelle, GPU-Server und RAG.

Onyx einführen, ohne Daten in fremde Clouds zu geben? Wir richten Onyx mit Ihren Datenquellen und einem lokalen Modell ein und übernehmen auf Wunsch den laufenden Betrieb. Termin vereinbaren

Quellen

• Onyx auf GitHub (README)
• Onyx, LICENSE
• Onyx, GitHub Releases
• Onyx Docs, Deployment Overview
• Onyx Docs, Quickstart
• Onyx Docs, Resourcing
• Onyx Docs, Onyx CLI
• Onyx Docs, Docker
• Onyx Docs, Kubernetes
• Onyx Docs, Enterprise Edition
• Onyx Docs, Plans & Billing
• Onyx Docs, SSO Providers
• Onyx Docs, Connectors Overview
• Onyx Docs, File Connector
• Onyx Docs, Create Connectors
• Onyx Docs, Ollama
• Onyx Docs, LiteLLM Proxy
• Onyx Docs, Custom Inference Provider
• Onyx Docs, Index Settings
• Onyx Docs, OpenSearch Document Index Migration
• Onyx Docs, Release Process & Updates
• Onyx, docker-compose.yml
• Onyx, shared_configs/configs.py
• Onyx, embedding_configs.py
• Open WebUI Docs, Knowledge
• Open WebUI Docs, Knowledge Base Sync (oikb)
• Open WebUI Docs, Groups
• Open WebUI Docs, License