Odysseus AI installieren und ausführen: Weg auswählen und ersten Login prüfen

Docker, native Einrichtung oder Plattformleitfaden wählen

Das offizielle Projekt beschreibt Docker Compose für viele Nutzer als gut wiederholbaren Einstieg. Anwendung und Zusatzdienste bleiben in einem bekannten Stack, wodurch ein sauberer Neustart leichter wird. Der Nachteil: localhost in einem Container ist nicht automatisch localhost des Browsers oder des Hostsystems.

Eine native Einrichtung passt, wenn Sie Prozesse direkt steuern, Python einfacher debuggen oder die lokale Beschleunigung des Betriebssystems nutzen möchten. Dafür verwalten Sie Python-Umgebung, Abhängigkeiten, Ports und Logs selbst. Unter Windows sollten Sie den eigenen Windows-Leitfaden nutzen, weil WSL2, Docker Desktop, PowerShell und Ollama mehrere Netzwerke erzeugen können.

Vor der Installation die Umgebung prüfen

Viele Fehler beim ersten Start sind Umgebungsfehler. Entscheiden Sie vor dem Klonen, wo die Anwendung liegt, wo persistente Daten gespeichert werden und ob der Modellserver auf demselben Rechner läuft. Starten Sie zuerst eine kleine Basiskonfiguration, statt Modell, Proxy, LAN und Suche gleichzeitig hinzuzufügen.

Planen Sie Speicherplatz für Quellcode, Container, Logs, Modelle und Dokumente ein. RAM und VRAM eines lokalen Modells sind nicht dasselbe wie die Anforderungen des Arbeitsbereichs. Der erste Browser-Test sollte auf demselben Rechner über localhost erfolgen; LAN, Tailscale, Reverse Proxy oder öffentliche Erreichbarkeit kommen später.

• Git, Docker Compose oder die Laufzeit der gewählten Methode prüfen.
• Einen persistenten Ordner für Repository, .env, Volumes, Logs und Backups wählen.
• Den ersten Test auf localhost lassen und nicht automatisch an 0.0.0.0 binden.
• Festhalten, ob Ollama und SearXNG auf dem Host, in Docker oder auf einem anderen Rechner laufen.
• Befehle mit dem aktuellen offiziellen README und Setup-Leitfaden vergleichen.

Arbeitsbereich installieren und starten

Für den ersten Versuch ist Docker oft der kürzeste Weg zu einer reproduzierbaren Basis. Klonen Sie das offizielle Repository, lesen Sie das aktuelle README, kopieren Sie die Beispiel-Umgebungsdatei, falls sie vorhanden ist, und starten Sie Compose. Erfinden Sie keine Versionsnummer und übernehmen Sie keine alten Befehle ohne Vergleich mit dem aktuellen Stand.

Bei einer nativen Installation erstellen Sie die unterstützte Python-Umgebung, installieren die dokumentierten Abhängigkeiten, führen die Einrichtung aus und starten den Prozess. Unter Windows verwenden Sie den Projekt-Launcher, statt Linux- und PowerShell-Befehle zu vermischen.

1. Zuerst nur die Basis starten

   Proxy, LAN-Zugriff, Modell und Suche nicht gleichzeitig einrichten. Das Ziel ist zunächst ein gesunder Prozess.

2. Logs vor Portänderungen lesen

   Wenn der Browser nicht verbindet, prüfen Sie zuerst Prozess, Health-Status und Logs.

3. Branch dokumentieren

   Das Projekt kann Entwicklungs- und kuratierte Branches unterscheiden. Vor alten Befehlen den aktuellen README prüfen.

git clone https://github.com/odysseus-dev/odysseus.git
cd odysseus
cp .env.example .env
docker compose up -d --build

git clone https://github.com/odysseus-dev/odysseus.git
cd odysseus
powershell -ExecutionPolicy Bypass -File .\launch-windows.ps1

git clone https://github.com/odysseus-dev/odysseus.git
cd odysseus
./start-macos.sh

Ollama und Suchdienste einzeln verbinden

Wenn der Arbeitsbereich geöffnet ist, verbinden Sie den Modell-Backend. Bei nativen Prozessen auf demselben Host kann localhost richtig sein. Läuft Odysseus in Docker und Ollama auf dem Host, zeigt localhost jedoch meist auf den Container. Verwenden Sie den im Docker-Leitfaden beschriebenen Host-Gateway-Endpoint und testen Sie ihn aus der Umgebung der Anwendung.

Die Suche ist eine eigene Servicegrenze. Ein eingebundenes SearXNG kann über den Compose-Servicenamen erreichbar sein; eine externe Instanz braucht eine URL, die Odysseus erreichen kann. Eine geöffnete Seite beweist daher nicht, dass Modell und Suche funktionieren. Testen Sie beides separat mit kleinen Anfragen.

Den ersten Login vor echter Arbeit prüfen

Der erste Login ist ein wichtiger Betriebspunkt. Öffnen Sie den lokalen Port der aktuellen Methode, prüfen Sie die richtige Instanz und ersetzen Sie sofort das temporäre Admin-Passwort. Bei einer leeren Seite oder einem Reverse Proxy gehen Sie zunächst auf die direkte lokale Adresse zurück.

Prüfen Sie danach in Settings, ob die gewünschten Dienste sichtbar sind. Verwenden Sie eine kleine Aufgabe ohne sensible Dateien, lesen Sie Antwort und Plan und stoppen Sie, wenn vorgeschlagene Änderungen nicht nachvollziehbar sind.

1. Lokale Seite öffnen

   Den Port aus aktueller Anleitung und Logs nutzen, nicht blind einen alten Blog-Port übernehmen.

2. Zugangsdaten ändern

   Das erzeugte Passwort vor LAN-, VPN- oder Proxy-Tests ersetzen.

3. Modell testen

   Kurzen Prompt senden und Provider sowie Modell prüfen.

4. Workflow testen

   Beispielprojekt öffnen, Plan prüfen und anfangs manuelle Freigabe behalten.

Einen wiederholbaren Startablauf erstellen

Ein zuverlässiger Start trennt Rechnerprüfung, Anwendungsstart, Dienstverbindung und Benutzerfreigabe. Wenn diese Schritte vermischt werden, wirkt jeder Fehler wie ein Modellfehler. Notieren Sie Methode, lokale URL, getesteten Branch oder Commit, Modell- und Such-Endpoint, Datenordner und Stop-Befehl in einem kurzen Runbook.

So wird der nächste Neustart zu einer bekannten Prozedur. Das ist besonders hilfreich, wenn Docker, Ollama, SearXNG und ein Proxy verschiedene Netzwerke verwenden.

Häufige Startfehler eingrenzen

Die meisten ersten Fehler gehören zu wenigen Grenzen: Prozess nicht gesund, falscher Port, localhost aus einem anderen Container, unerreichbarer optionaler Dienst oder ein falsch verstandenes Volume beziehungsweise Passwort. Beginnen Sie bei der kleinsten fehlerhaften Schicht und ändern Sie nicht mehrere Variablen gleichzeitig.

Bei Videos oder Community-Anleitungen vergleichen Sie Branch, Port, Umgebungsvariablen und Servicenamen mit dem offiziellen Repository. Eine hilfreiche Anleitung kann trotzdem veraltet sein.

Kontrolliert aktualisieren

Kein allgemeiner Update-Befehl ersetzt das Lesen der aktuellen Projektanleitung. Vor Pull oder Rebuild wichtige Daten sichern, getesteten Branch oder Commit notieren und Änderungen an Variablen oder Servicenamen prüfen. Bei Volumes, Dokumenten und Zugangsdaten ist ein Rebuild ein Vorgang mit Zustand.

Bei Docker den Stack vor dem Neuerstellen stoppen und prüfen. Bei nativer Installation die verstandenen Änderungen und die Python-Umgebung erhalten und Abhängigkeiten bewusst aktualisieren. Vor dem Verlassen von localhost Authentifizierung, HTTPS, Netzregeln und Rückfallplan vorbereiten.