Odysseus als privacy-first KI-Workspace
Autonome Recherche, virtuelle Expertenteams und ein unerwarteter SOC-Einsatz - Odysseus im Praxistest.
Mit Odysseus ist Ende Mai 2026 ein selbstgehosteter KI-Workspace erschienen, der den Anspruch erhebt, weit mehr zu sein als ein weiterer Chatbot-Wrapper: Das Projekt vereint Chat, autonome Agenten, mehrstufige Tiefenrecherche, Dokumentenverwaltung, E-Mail-Integration und Kalender in einer einzigen, vollständig lokal betriebenen Plattform. Wer bisher entweder zum schlanken Frontend-Ansatz von Open WebUI oder zur autonomen Agenten-Power von Hermes Agent gegriffen hat, findet in Odysseus eine dritte Option, die bewusst zwischen diesen Welten angesiedelt ist.
Einordnung: Wo sich Odysseus im Ökosystem positioniert
Um Odysseus einzuordnen, hilft ein kurzer Blick auf die Nachbarn. Open WebUI ist ein exzellentes Chat-Frontend für lokale Modelle - es bietet Model-Management, RAG, Function Calling und eine vertraute ChatGPT-ähnliche Oberfläche. Es ist aber primär ein Interface: Der Nutzer fragt, das Modell antwortet, die Sitzung endet. Hermes Agent von Nous Research hingegen ist ein autonomes Agenten-Framework mit einem geschlossenen Lernkreislauf - es speichert erfolgreiche Lösungsstrategien als wiederverwendbare Skills, baut ein persistentes Nutzerprofil auf und wird über Sitzungen hinweg besser. Der Einstieg ist technisch und primär auf Code-Interfaces ausgelegt.
Odysseus setzt sich genau dazwischen. Es ist ein vollständiger KI-Arbeitsplatz mit einer durchgängigen Web-UI, der weit über einen Chat hinausgeht (Agenten, Recherche, Dokumente, E-Mail, Kalender), dabei aber zugänglicher bleibt als ein reines Agenten-Framework. Keine Kommandozeilen-Pflicht, keine YAML-Konfigurationen für Skills - stattdessen eine konsolidierte Oberfläche, die Privatsphäre-first und lokal-first als Designprinzipien verinnerlicht hat.
Entwickelt wurde Odysseus von Felix Kjellberg - im Internet als PewDiePie mit über 110 Millionen YouTube-Abonnenten bekannt - unter dem GitHub-Handle pewdiepie-archdaemon. Das Projekt sammelte innerhalb weniger Wochen über 73.000 GitHub-Stars und steht unter der AGPL-3.0-Lizenz. Hinter dem Projekt steckt keine Venture-Capital-Finanzierung, kein Telemetrie-Backdoor und kein Abo-Modell - sondern das dokumentierte Ergebnis eines Jahres intensiver Eigenentwicklung auf einem beeindruckenden GPU-Rig. Ob das den langfristigen Support sichert, bleibt abzuwarten, aber der Start ist überzeugend.
Docker-Setup mit bestehender Infrastruktur
Der offizielle Quick-Start von Odysseus bringt von Haus aus vier Container mit: Odysseus selbst, ChromaDB als Vektordatenbank, SearXNG und ntfy. Wer - wie im hiesigen Stack - SearXNG und ntfy bereits betreibt, übernimmt nur die zwei tatsächlich neuen Dienste und referenziert die bestehenden Instanzen über die Umgebungsvariablen.
Die folgende docker-compose.yml-Konfiguration integriert Odysseus in eine Infrastruktur, in der SearXNG und ntfy bereits als separate Container laufen:
# M. Meister - Odysseus + ChromaDB (SearXNG & ntfy extern eingebunden)
services:
odysseus:
image: ghcr.io/pewdiepie-archdaemon/odysseus:latest
container_name: odysseus
restart: unless-stopped
depends_on:
- chromadb
expose:
- 7000
environment:
# Bind auf alle Interfaces (Reverse-Proxy übernimmt TLS-Terminierung)
- APP_BIND=0.0.0.0
- APP_PORT=7000
# Ollama läuft auf dem Host "ai" im selben Docker-Netzwerk
- OLLAMA_BASE_URL=http://ai:11434
# Bestehende SearXNG-Instanz einbinden
- SEARXNG_INSTANCE=http://searxng:8080
# ChromaDB-Verbindung (interner Backend-Service)
- CHROMADB_HOST=chromadb
- CHROMADB_PORT=8000
# CORS: Nur eigene Frontend-Domain erlaubt
- ALLOWED_ORIGINS=https://oi.meine-domain.de
# Sicherheit: Secure Cookies für HTTPS-Betrieb hinter Reverse-Proxy
- SECURE_COOKIES=true
- AUTH_ENABLED=true
volumes:
- ./odysseus/data:/app/data # Datenbank, Sessions, Uploads
- ./odysseus/logs:/app/logs # Anwendungs-Logs
- ./odysseus/ssh:/app/.ssh # SSH-Keys für Cookbook-Remotezugang
- ./odysseus/huggingface:/app/.cache/huggingface # Modell-Cache
- ./odysseus/local:/app/.local # Installierte CLI-Tools (llama.cpp etc.)
networks:
- web # Erreichbar für Reverse-Proxy
- backend # Internes Netz: Zugang zu ChromaDB, SearXNG, Ollama, ntfy
labels:
- "com.centurylinklabs.watchtower.enable=true"
chromadb:
image: chromadb/chroma:latest
container_name: chromadb
restart: unless-stopped
volumes:
- ./odysseus/chromadb:/chroma/chroma # Persistenter Vektorspeicher
networks:
- backend # Nur intern erreichbar - nie öffentlich exponieren!
labels:
- "com.centurylinklabs.watchtower.enable=true"
networks:
web:
external: true
backend:
external: true
Das initiale Admin-Passwort wird beim ersten Start in den Container-Logs ausgegeben:
docker compose logs odysseus | grep -i "password\|admin"
Danach sollte das Passwort sofort in den Settings geändert werden. Ollama wird in den Settings → Model Providers als zusätzlicher Endpoint eingetragen - entweder direkt über die Container-IP oder, falls Ollama auf dem Docker-Host läuft, über http://host.docker.internal:11434/v1.
Ein wichtiger Hinweis zum ChromaDB-Port: Die Standarddokumentation gibt Port 8100 als Host-Port an, während innerhalb des Docker-Netzwerks Port 8000 genutzt wird. Die obige Konfiguration setzt CHROMADB_PORT=8000 korrekt für die Container-zu-Container-Kommunikation.
Agents und Personas: Das virtuelle Expertenteam
Odysseus unterscheidet zwischen einfachen Chat-Sitzungen und Agenten. Ein Agent hat Zugriff auf Werkzeuge: Web-Suche (via SearXNG), Dateizugriff, Shell-Ausführung, MCP-Server und den eigenen Vektorspeicher in ChromaDB. Jede Persona wird über den Characters-Tab angelegt: Ein Name, ein Avatar und ein System-Prompt definieren, wer der Agent "ist" und worüber er Bescheid weiß.
Die interessante Funktion ist die Gruppen-Funktion: Mehrere Personas werden zu einem Team zusammengefasst, und eine Frage wird an alle gleichzeitig gestellt. Jede Persona antwortet - und kann die Antworten der anderen sehen und darauf aufbauen.
Ob das tatsächlich funktioniert? Ja. Ein Praxisszenario für IT-Security und Netzwerkbetrieb könnte so aussehen:
Team "Firewall Review":
Persona 1: "Konfigurations-Experte"
System-Prompt: "Du bist ein erfahrener Firewall-Ingenieur mit tiefem Wissen über
Check Point R82, FortiOS 7.4 und OPNsense. Du bewertest Konfigurationsvorschläge
auf technische Korrektheit, Best Practices und mögliche Nebenwirkungen. Du kennst
die Fallstricke bei NAT, asymmetrischem Routing und Stateful Inspection.
Konfigurationen in deinem Scope werden wie folgt vorgenommen:
**Interfaces / Routing / Antispoofing**
Mit folgenden Befehlen werden in der anvertrauten Umgebung Interfaces angelegt und mit passenden Monitoring-Eigenschaften versehen:
..."
Persona 2: "Pentester"
System-Prompt: "Du analysierst Netzwerkkonfigurationen aus Angreifersicht.
Du identifizierst Schwachstellen, Bypass-Möglichkeiten und Fehlkonfigurationen,
die ein Angreifer ausnutzen könnte. Du denkst in Angriffsvektoren, nicht in
Compliance-Checklisten.
Du kannst Dir aus dem Internet weitere Ideen für eine erfolgreiche Übernahme der Infrastruktur beschaffen..."
Persona 3: "Dokumentationsprofi"
System-Prompt: "Du bist ein technischer Redakteur mit Fokus auf IT-Security-
Dokumentation. Sobald Konfigurations-Experte und Pentester einig sind, fasst du
die Ergebnisse strukturiert zusammen: Was wurde beschlossen, warum, und welche
Risiken bleiben bestehen."
Wird nun eine Frage an das Team gestellt - etwa: "Wir möchten SMTP-Traffic für einen neuen Mailserver durch die Firewall erlauben, aber nur ausgehend. Wie setzt man das sicher um?" - antwortet der Konfigurations-Experte mit konkreten Regelvorschlägen, der Pentester weist auf potenzielle Risiken (Relay-Missbrauch, SPF/DKIM-Umgehung, ungewollte Outbound-Pfade) hin, und der Dokumentationsprofi erstellt am Ende eine saubere Zusammenfassung der abgestimmten Lösung.
Ein wichtiger Hinweis zur aktuellen Implementierung: Die Personas innerhalb einer Gruppe teilen aktuell denselben Konversationskontext und greifen nicht auf individuell isolierte, persistente Langzeitgedächtnisse zu. Wer möchte, dass "der Pentester" zwischen Sitzungen dazulernt und sich an frühere Diskussionen erinnert, muss das Character-Preset jedes Mal manuell selektieren. Eine tiefere Persistenz pro Agent - vergleichbar mit dem Memory-System in Hermes Agent - ist im Roadmap für Odysseus als geplantes Feature gelistet, aber noch nicht implementiert. Für Einzel-Sitzungs-Diskussionen funktioniert die Gruppen-Funktion jedoch ausgezeichnet.
Deep Research: Mehrstufige Recherche ohne Browser-Ping-Pong
Die Deep Research-Funktion ist einer der überzeugendsten Unterschiede gegenüber einem einfachen Chat-Interface. Statt eine Suchanfrage abzuschicken und die Snippets zu lesen, führt Odysseus hier einen mehrstufigen, autonomen Rechercheprozess durch:
Der Agent formuliert eigenständig Suchqueries, schickt sie an die angebundene SearXNG-Instanz, ruft die tatsächlichen Inhalte der Ergebnisseiten ab (nicht nur die Snippets), wertet sie aus, identifiziert offene Fragen und formuliert Folge-Queries - so lange, bis das Thema ausreichend beleuchtet ist. Am Ende entsteht ein strukturierter Bericht mit Quellenangaben.
Konkrete Anwendungen im IT-Security-Kontext, wo sich dieses Feature besonders lohnt:
Wird nach einem neu entdeckten CVE gefragt, findet der Agent selbständig die NVD-Eintragung, die Vendor-Advisory, öffentliche PoC-Analysen und aktuelle Community-Bewertungen der tatsächlichen Ausnutzbarkeit - und fasst das in einem lesbaren Bericht zusammen, statt die Recherchepflicht auf den Anwender abzuwälzen.
Für die Vorbereitung eines Penetrationstests lässt sich der Scope (z.B. "Nginx 1.24 hinter einem FortiGate-Gateway, Ubuntu 24.04 Server, Dienste: SSH, SMTP, HTTPS") eingeben, und der Agent recherchiert aktuelle CVEs, bekannte Fehlkonfigurationen und relevante Exploit-Techniken zu dieser spezifischen Kombination.
Persönliche Wissensdatenbank mit ChromaDB
ChromaDB dient Odysseus als Vektordatenbank für eine semantische Wissensdatenbank. Dokumente, die in den persönlichen Dokumentenspeicher hochgeladen werden - PDFs, Markdown-Dateien, Text-Exporte - werden in Embeddings umgewandelt und in ChromaDB gespeichert. Beim Chatten kann der Agent die Wissensdatenbank abfragen und relevante Inhalte in seinen Kontext einbinden.
Für den täglichen IT-Security-Betrieb ergeben sich daraus interessante Möglichkeiten. Firewall-Regelwerke der betreuten Clients lassen sich als Markdown exportieren und einlesen - der Agent weiß dann, welche Netze freigegeben sind und kann bei neuen Anforderungen direkt auf die bestehende Konfiguration referenzieren, anstatt von vorne zu beginnen. Ebenso eignen sich Runbooks, Change-Log-Dokumente, Sicherheitsrichtlinien oder OPNsense-Export-Dumps als Wissensbasis.
Die praktische Erfahrung mit ähnlichen RAG-Systemen zeigt: Denormalisiertes, gut strukturiertes Markdown mit expliziten Kontextangaben schlägt rohe JSON-Dumps und minimalistisch kommentierte Configs. Ein Firewall-Regelwerk, das jeden Block mit einem Kommentar wie # Client: Muster GmbH | Policy: HTTPS-Ausgehend | Stand: 2026-06 einleitet, lässt sich vom Agenten weit präziser auswerten als eine rohe Regelliste ohne Kontext.
Unerwarteter Einsatz: Odysseus als SOC-Assistent
Da ich unterschiedliche Varianten getestet habe, wie mich lokale KI beim sofotigen Auftreten von Incidents unterstützen kann: Odysseus als automatisierter Security-Triage-Assistent - integriert ebenfalls gut in den bestehenden Monitoring-Stack.
Die E-Mail-Integration von Odysseus unterstützt IMAP/SMTP und erlaubt es, Postfächer direkt in der Oberfläche zu verwalten: eingehende Mails werden zusammengefasst, mit Tags versehen, und ein Agent kann bereits Antwort-Entwürfe erstellen. Was auf den ersten Blick nach "KI für den Posteingang" klingt, ergibt für einen IT-Security-Betrieb eine ganz andere Dimension.
Der Aufbau funktioniert folgendermaßen: Ein dediziertes Postfach - etwa alerts@meine-domain.de - empfängt die Benachrichtigungen der bestehenden Monitoring-Systeme (Wazuh-Alarme, Suricata-Alerts, Uptime-Kuma-Ausfälle). Odysseus wird über IMAP an dieses Postfach angebunden. Ein geplanter Agent-Task - Odysseus unterstützt zeitgesteuerte Aufgaben - liest periodisch neue Mails, klassifiziert sie nach Schweregrad, und legt für jede Kategorie eine strukturierte Zusammenfassung im Documents-Modul ab.
Das Ergebnis: Statt 47 roher E-Mail-Benachrichtigungen pro Nacht findet sich morgens im Documents-Modul ein strukturiertes Triage-Dokument. "3 kritische Alerts: Wazuh hat auf Client A und B eine erhöhte Authentifizierungsfehlschlagsrate erkannt, Suricata hat auf dem Edge-Router einen ET-Scan-Alarm ausgelöst. 12 informationale Alerts: Uptime Kuma hat kurzzeitige Latenzen auf 4 Diensten gemeldet. Alle Details siehe Anhang."
Der Agent kann dabei auch die SearXNG-Integration nutzen, um Suricata-Signatur-IDs direkt gegen aktuelle Threat-Intelligence-Quellen zu recherchieren und einzuordnen. Das ist kein Ersatz für ein vollständiges SIEM - aber eine schlanke, vollständig datenschutzkonforme Ergänzung für den Solo-Betreiber oder den kleinen IT-Dienstleister.
Ein Nebenvorteil: Für die CalDAV-Kalenderintegration lassen sich aus den Triage-Ergebnissen automatisch Follow-up-Termine anlegen - "Nachkontrolle Client A, Login-Anomalie" für übermorgen, 14:00 Uhr.
Sicherheitshinweise für den Betrieb
Odysseus ist kein harmloses Chat-Tool. Wer Agenten mit Shell-Zugriff aktiviert, gibt dem Agenten die Berechtigungen des Prozess-Users - ohne weiteres Sandboxing. Ich habe daher meine Dokumente für den Wissensspeicher read-only in den Container von Odysseus durchgereicht. Das THREAT_MODEL.md im Repository adressiert das explizit und transparent, was in der Agentic-AI-Landschaft leider keine Selbstverständlichkeit ist (ein freundlicher Seitenhieb Richtung OpenClaw).
Für den produktiven Einsatz gelten folgende Grundsätze:
AUTH_ENABLED=true ist gesetzt und muss gesetzt bleiben - insbesondere, wenn der Dienst über einen Reverse-Proxy aus dem Internet erreichbar ist. SECURE_COOKIES=true ist für HTTPS-Betrieb hinter einem Reverse-Proxy korrekt. ChromaDB, Ollama und ntfy gehören ausschließlich ins interne Backend-Netzwerk und werden niemals direkt öffentlich exponiert. Der Odysseus-Prozess selbst sollte nicht als root laufen. Wer Shell-Zugriff für Agenten aktiviert, sollte sicherstellen, dass der Container-User nur die minimal notwendigen Dateisystem-Berechtigungen besitzt. API-Tokens und hochgeladene Dateien mit sensiblen Inhalten landen in ./odysseus/data/ - dieser Pfad gehört nicht ins Git-Repository und nicht in öffentlich zugängliche Backup-Ziele.
Fazit
Odysseus trifft eine klare Designentscheidung: Es ist kein schlankes Chat-Interface, das einzelne Modelle durchreicht, und kein autonomes Agenten-Framework für Power-User, die sich in Kommandozeilentools wohl fühlen - sondern ein vollständiger, privacy-first KI-Arbeitsplatz, der beides kombiniert und um echte Produktivitätsfunktionen (E-Mail, Kalender, Dokumente) erweitert. Die Gruppen-Funktion für Agenten-Teams und die mehrstufige Deep-Research-Pipeline heben das Projekt klar über einfache Model-Frontends hinaus. Die Reife des Projekts bleibt zu beobachten, aber der Start ist bemerkenswert - auch wenn er aus einer unerwarteten Richtung kam.