Octop selbst hosten: KI-Assistent für mehrere Benutzer

Was Octop ist und warum Sie es selbst hosten sollten

Octop ist ein selbst gehosteter KI-Assistent für einen Haushalt oder ein kleines Team. Der Grund, Octop statt einer einfachen Chat-Oberfläche selbst zu hosten, besteht darin, dass Octop die Benutzer voneinander trennt. Open WebUI stellt eine Browser-Oberfläche vor einem Modell bereit. Octop ergänzt Benutzerkonten mit einer Administratorrolle, einen privaten Arbeitsbereich und einen eigenen Zugangsdaten-Satz für jeden Benutzer sowie eine Bibliothek spezialisierter Agenten, zwischen denen jeder Benutzer je nach Aufgabe wechseln kann. Dieser Unterschied ermöglicht es, fünf Personen über einen VPS zu versorgen statt nur eine.

Das Projekt befindet sich unter github.com/TencentCloud/Octop. Es handelt sich um einen Prozess, der ein Web-Dashboard, eine Befehlszeilenschnittstelle, Chat-Kanäle (Feishu, DingTalk, QQ, Discord, WeCom) und geplante Aufgaben bereitstellt. Als gemeinsame Datenbasis dient eine einzelne SQLite-Datenbank unter ~/.octop/. Alle folgenden Angaben beziehen sich auf den Tag v0.9.19, der am 5. August 2026 veröffentlicht wurde. Wenn Sie noch zwischen Plattformen entscheiden, behandelt der Vergleich von Open-WebUI-Alternativen, die Sie auf einem VPS ausführen können das gesamte Spektrum.

Bevor Sie einen Abend dafür einplanen, sollten Sie einen Punkt beachten. Octop ist eine Software vor Version 1.0, die aus der GitHub-Organisation eines Anbieters veröffentlicht wird und im August 2026 etwa 900 Sterne hatte. Das Projekt entwickelt sich schnell weiter, wie die Versionsnummern zeigen. Eine stabile Upgrade-Strategie ist daher nicht garantiert. Fixieren Sie einen Tag, lesen Sie das Changelog und halten Sie Backups vor.

Was Sie vor dem Start benötigen

• Einen VPS mit Ubuntu 24.04, Docker Engine und dem Compose-Plugin. Sie kennen Compose noch nicht? Beginnen Sie mit den Grundlagen von Docker Compose für einen VPS.
• git, weil Sie ein Release-Tag auschecken, statt ein Image abzurufen.
• Einen Domainnamen, der auf den VPS zeigt, weil Sie davor TLS (Transport Layer Security) bereitstellen möchten.
• Ein Modell-Backend, das die OpenAI API unterstützt: ein lokales Ollama, ein selbst gehostetes Gateway oder einen kostenpflichtigen Schlüssel.

Octop selbst benötigt nur wenige Ressourcen. Es besteht aus einem Python-Prozess und einer SQLite-Datei. Die benötigten Ressourcen fallen beim Modell-Backend an. Wenn Sie das Modell auf demselben Server ausführen möchten, dimensionieren Sie den Server entsprechend dem Modell.

Warum wir den curl-Installer nicht empfehlen

Die README beginnt mit einer einzeiligen Installation:

curl -fsSL https://finnie-1258344699.cos.ap-guangzhou.myqcloud.com/octop/install.sh | bash

Wir empfehlen diese Methode nicht auf einem Server, der Ihnen wichtig ist. Der konkrete Grund: Das Script befindet sich nicht im Repository. Es wird aus einem Tencent Cloud Object Storage-Bucket bereitgestellt. Es ist weder durch ein Git-Tag noch durch einen Commit abgedeckt. Daher können Sie das heutige Script nicht mit dem Script der letzten Woche vergleichen. Außerdem gibt es keine Historie, die eine Änderung erklärt. Der Bucket kann morgen andere Bytes ausliefern, ohne dass dies im Projekt dokumentiert wird. Wenn das Ergebnis direkt an bash weitergeleitet wird, führt der Rechner das Script außerdem aus, bevor Sie auch nur eine Zeile gelesen haben.

Der Installer schreibt außerdem direkt auf den Host und nicht in einen Container. Er verwendet uv, um Python 3.12 abzurufen und eine Umgebung zu erstellen, von der Ihr Paketmanager nichts weiß. Wenn Sie diese Umgebung später entfernen möchten, müssen Sie dies manuell erledigen.

Es gibt zwei bessere Optionen. Rufen Sie das Script ab, lesen Sie es und führen Sie es anschließend aus. Das kostet dreißig Sekunden: curl -fsSL <url> -o install.sh, danach less install.sh und anschließend bash install.sh. Oder verwenden Sie Docker. Das ist der Ansatz im restlichen Teil dieses Leitfadens. Das PyPI-Paket (pip install octop) ist zumindest ein versioniertes Artefakt, dessen Version Sie auf ein Release festlegen können.

Octop mit Docker Compose und fest auf v0.9.19 bereitstellen

Bis August 2026 gibt es kein veröffentlichtes Image zum Herunterladen. Die mitgelieferte Compose-Datei erstellt das Image aus dem Repository. Eine Version festzulegen bedeutet daher, einen Git-Tag auszuchecken.

git clone https://github.com/TencentCloud/Octop.git
cd Octop
git checkout v0.9.19

Dies ist der von der Datei definierte Dienst, auf die relevanten Teile gekürzt:

services:
  octop:
    build:
      context: ..
      dockerfile: docker/Dockerfile
    image: octop:latest
    container_name: octop
    restart: unless-stopped
    ports:
      - "${OCTOP_PORT:-8088}:${OCTOP_PORT:-8088}"
    volumes:
      - ${OCTOP_DATA:-~/.octop}:/data/.octop
    environment:
      - HOME=/data
      - OCTOP_BIND_HOST=0.0.0.0
      - OCTOP_PORT=${OCTOP_PORT:-8088}
      - OCTOP_DEFAULT_PASSWORD=${OCTOP_DEFAULT_PASSWORD:-octop}
      - OCTOP_ADMIN_USERNAME=${OCTOP_ADMIN_USERNAME:-admin}
      - OPENAI_API_KEY=${OPENAI_API_KEY:-}

Beachten Sie den Block build:. image: octop:latest ist der Name Ihres eigenen Builds und kein Verweis auf eine Registry. latest steht hier daher für das, was Sie zuletzt kompiliert haben. Legen Sie den Datenpfad explizit fest, statt ihn einem Standardwert zu überlassen. Vergeben Sie außerdem vor dem ersten Start ein echtes Passwort für das Administratorkonto. Tragen Sie dies in docker/.env ein:

OCTOP_PORT=8088
OCTOP_ADMIN_USERNAME=admin
OCTOP_DEFAULT_PASSWORD=<a long random password>
OCTOP_DATA=/srv/octop-data

Ein wichtiger Fehler in diesem Zusammenhang ist relevanter als der Rest der Datei. Compose liest docker/.env nur ein, um die Platzhalter ${...} in der YAML-Datei zu ersetzen. Ein Schlüssel, den Sie dieser Datei hinzufügen, erreicht den Container nicht, sofern er nicht auch unter environment: in der Compose-Datei aufgeführt ist. Wenn Sie OCTOP_ACCESS_TOKEN_TTL nur zu .env hinzufügen, bewirkt das überhaupt nichts. Das geschieht stillschweigend. Alternativ können Sie dieselben Schlüssel in ~/.octop/env im eingebundenen Datenverzeichnis eintragen. Octop lädt diese Datei beim Start. Der Leitfaden zu Env-Dateien und Secrets in Docker Compose erklärt, warum diese beiden Mechanismen nicht identisch sind.

Erstellen und starten Sie den Dienst:

docker compose -f docker/docker-compose.yml up -d --build
docker compose -f docker/docker-compose.yml ps
curl http://127.0.0.1:8088/api/health

Eine funktionsfähige Instanz beantwortet die Health-Prüfung mit {"status":"ok","version":"..."}. Bei jedem anderen Ergebnis lesen Sie docker compose -f docker/docker-compose.yml logs -f octop, bevor Sie den Browser verwenden.

Geben Sie dem gerade erstellten Image nun einen aussagekräftigen Namen. Der nächste --build überschreibt octop:latest. Andernfalls können Sie die beiden Images nicht unterscheiden:

docker image tag octop:latest octop:0.9.19

Beim ersten Start wird octop init ausgeführt. Die anfänglichen Zugangsdaten werden in das Datenvolume geschrieben:

docker exec -it octop cat /data/.octop/credential.txt

Die Standardwerte sind admin / octop. Sie werden nur bei der ersten Initialisierung verwendet. Das erklärt eine häufig gestellte Frage: Wenn Sie OCTOP_DEFAULT_PASSWORD ändern, nachdem der Container bereits einmal gestartet wurde, hat das keine Wirkung, weil das Konto bereits vorhanden ist. Ändern Sie das Passwort stattdessen im Dashboard.

8088 nicht veröffentlichen

Die obige Zeile ports: bindet an alle Schnittstellen des VPS. Sobald der Container startet, ist das Dashboard unverschlüsselt und mit einem Standardpasswort aus dem öffentlichen Internet erreichbar. Der Standardwert 127.0.0.1 von Octop in OCTOP_BIND_HOST lautet 127.0.0.1; die Compose-Datei überschreibt ihn mit 0.0.0.0, weil der Prozess Datenverkehr außerhalb seines eigenen Netzwerk-Namespace annehmen muss. Diese Überschreibung ist korrekt. Der veröffentlichte Port ist der Teil, der den Zugriff von außen ermöglicht.

Bearbeiten Sie die Zeile ports: in docker/docker-compose.yml, sodass das Mapping nur auf dem Loopback-Interface lauscht:

    ports:
      - "127.0.0.1:${OCTOP_PORT:-8088}:${OCTOP_PORT:-8088}"

Versuchen Sie nicht, dies mit einer einfachen Override-Datei zu beheben. Compose führt die ports-Listen aus mehreren Dateien zusammen, statt sie zu ersetzen. Dadurch veröffentlichen Sie beide Mappings, und das zweite kann nicht gebunden werden. Wenn Sie die Upstream-Datei unverändert lassen möchten, verwenden Sie das Tag !override für die Sequenz. Dies ist die dokumentierte Methode, um eine Sequenz zu ersetzen, statt Einträge anzuhängen. Die Erklärung zum Zusammenführen mehrerer Compose-Dateien behandelt die übrigen Regeln für das Zusammenführen.

Das Binden an das Loopback-Interface behebt außerdem ein Problem, das sonst mit der Firewall auftreten würde. Docker schreibt seine Regeln für veröffentlichte Ports vor den von ufw verwalteten Chains in die nat-Tabelle. Daher verhindert ufw deny 8088 nicht, dass ein Container-Port veröffentlicht wird. Ein an 127.0.0.1 gebundener Port ist unabhängig von der Konfiguration von ufw niemals von außen erreichbar. Deshalb ist dies die richtige Lösung und keine zweitbeste Alternative.

TLS mit einem Reverse Proxy vorschalten

Caddy ist der kürzeste Weg, weil es das Zertifikat selbst über ACME (automatic certificate management environment) anfordert und WebSockets ohne zusätzliche Konfiguration weiterleitet:

octop.example.com {
    reverse_proxy 127.0.0.1:8088
}

nginx erfordert mehr Sorgfalt, weil Octop den Chat über einen WebSocket überträgt:

server {
    listen 443 ssl;
    server_name octop.example.com;

    ssl_certificate     /etc/letsencrypt/live/octop.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/octop.example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:8088;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_buffering off;
        proxy_read_timeout 3600s;
    }
}

Jede Zeile erfüllt eine bestimmte Aufgabe. Der Chat läuft über WS /agents/{id}/chat/ws. Ohne proxy_http_version 1.1 und die beiden Upgrade-Header beantwortet nginx den Upgrade-Versuch mit 400 Bad Request. Das Dashboard wird dann zwar normal geladen, aber jede gesendete Nachricht bleibt ohne Fehlermeldung auf der Seite hängen. proxy_buffering off ist erforderlich, weil der Resume-Endpunkt für Human-in-the-Loop text/event-stream zurückgibt. SSE (server-sent events), die in einem Proxy-Puffer zwischengespeichert werden, treffen andernfalls erst am Ende gesammelt ein, statt fortlaufend übertragen zu werden. proxy_read_timeout deckt lange Tool-Läufe ab. Der Standardwert von 60 Sekunden beendet einen Agenten sonst mitten in der Aufgabe, und die Logs enthalten upstream timed out (110: Connection timed out).

Wie sich die JWT-Authentifizierung hinter dem Proxy verhält

Octop authentifiziert sich mit einem Bearer-Token, nicht mit einem Cookie. POST /api/auth/login gibt {access_token, role, user, ...} zurück, und spätere Aufrufe übertragen Authorization: Bearer <access_token>. Für einen Reverse Proxy ist das eine gute Nachricht: Es gibt keine Cookie-Domain, kein Secure-Flag und keine SameSite-Regel, die falsch konfiguriert werden kann. Eine Sitzung, die auf http://127.0.0.1:8088 funktioniert hat, verhält sich daher auf https://octop.example.com genauso.

Zwei Folgen sollten Sie kennen, bevor Sie echte Benutzer darauf zugreifen lassen.

Der WebSocket überträgt das Token in der URL. Der Endpunkt ist WS /agents/{id}/chat/ws?token=<jwt>, weil JavaScript im Browser beim WebSocket-Handshake keinen Authorization-Header setzen kann. TLS schützt dieses Token bei der Übertragung. Es schützt das Token jedoch nicht vor Ihren eigenen Logs: nginx schreibt die vollständige Anforderungszeile einschließlich Query-String standardmäßig nach access_log. Dadurch landet ein funktionierendes Token eines echten Benutzers in einer Klartextdatei auf dem Server. Protokollieren Sie den Pfad ohne Argumente. $uri ist der normalisierte Pfad, aus dem der Query-String bereits entfernt wurde. Fügen Sie daher Folgendes in den http-Block ein und referenzieren Sie ihn vom Server aus:

log_format octop_noargs '$remote_addr [$time_local] '
                        '"$request_method $uri $server_protocol" '
                        '$status $body_bytes_sent';
access_log /var/log/nginx/octop.log octop_noargs;

Es gibt keine Abmeldung pro Sitzung. OCTOP_ACCESS_TOKEN_TTL ist standardmäßig auf 86400 gesetzt. Daher bleibt ein Token nach der Anmeldung 24 Stunden lang gültig. Die einzige dokumentierte Möglichkeit, ein Token ungültig zu machen, ist octop admin rotate-jwt-secret. Dieser Befehl rotiert den in ~/.octop/secrets/jwt_secret gespeicherten Signaturschlüssel und macht sofort alle noch gültigen Token für alle Benutzer ungültig. Wenn ein Benutzer das Team verlässt, ist die Reihenfolge daher: Löschen Sie den Benutzer, rotieren Sie das Secret und fordern Sie anschließend die verbleibenden Benutzer auf, sich erneut anzumelden. Wenn das zu aufwendig ist, verkürzen Sie die Gültigkeitsdauer. Denken Sie daran, die Variable sowohl in die Liste environment: als auch in .env aufzunehmen:

OCTOP_ACCESS_TOKEN_TTL=28800

Brute-Force-Angriffe werden behandelt: OCTOP_LOGIN_MAX_ATTEMPTS ist standardmäßig auf 5 Fehlversuche und OCTOP_LOGIN_LOCKOUT_SECONDS auf 900 gesetzt. Ein gesperrter Benutzer wartet daher einfach 15 Minuten, statt eine fehlerhafte Installation zu vermuten. Octop hat einen eigenen Benutzerspeicher und unterstützt in v0.9.19 keine dokumentierte OIDC-Integration. Wenn Sie echtes Single Sign-on benötigen, setzen Sie einen authentifizierenden Proxy davor. Dafür eignet sich ein selbst gehosteter Authentik-Server.

Point Octop auf ein Modell-Backend

Provider werden pro Agent im Dashboard konfiguriert, und octop provider list zeigt Ihnen, was eingestellt ist. Octop liefert Voreinstellungen für OpenAI-kompatible APIs, DashScope (Qwen) und Ollama. Die Zugangsdaten werden in der Tabelle providers Ihrer eigenen SQLite-Datenbank gespeichert. Die Auswahl bestimmt, welche Kosten entstehen und welche Daten das System verlassen.

Ein lokales Modell mit Ollama. Nichts verlässt den Server, und Sie zahlen mit RAM statt mit Tokens. Ein wichtiger Verbindungsaspekt wird häufig übersehen: Ein Container kann Ollama auf dem Host unter 127.0.0.1:11434 nicht erreichen, weil diese Adresse auf die Loopback-Schnittstelle des Containers selbst zeigt. Fügen Sie dem Dienst einen Host-Gateway-Eintrag hinzu:

    extra_hosts:
      - "host.docker.internal:host-gateway"

Setzen Sie anschließend die Provider-Basis-URL auf http://host.docker.internal:11434/v1. Das ist der OpenAI-kompatible Pfad von Ollama. Tragen Sie im API-Key-Feld eine beliebige nicht leere Zeichenfolge ein, weil Ollama den Wert ignoriert, OpenAI-Clients aber keinen leeren Wert senden. Ollama muss außerdem über die Loopback-Schnittstelle hinaus Verbindungen annehmen. Dafür ist OLLAMA_HOST=0.0.0.0:11434 in seiner systemd-Unit erforderlich. Das ist der riskante Teil: Ollama bietet keine Authentifizierung. Ein offener Port 11434 auf einer öffentlichen IP-Adresse stellt daher für jeden, der ihn zuerst scannt, kostenlos einen Modellserver bereit. Erlauben Sie nur den privaten Docker-Adressbereich sudo ufw allow from 172.16.0.0/12 to any port 11434 proto tcp und verweigern Sie alle übrigen Zugriffe. Ollama auf einem VPS ausführen behandelt die Dimensionierung des Modells. Der Vergleich von Ollama und vLLM zeigt, wann Ollama nicht mehr der passende Server ist.

Noch ein Hinweis zu lokalen Modellen, weil das Verhalten wie ein Fehler in Octop aussieht, aber keiner ist. Agenten arbeiten, indem sie Tools aufrufen. System-Prompt, Tool-Definitionen und Verlauf ergeben zusammen einen großen Prompt. Ollama stellt Modelle mit einem eher kleinen standardmäßigen Kontextfenster bereit. Dadurch fällt der Anfang des Prompts aus dem Fenster, also der Bereich mit den Tool-Definitionen. Das Modell ruft dann keine Tools mehr auf oder erfindet nicht vorhandene Tools. Erhöhen Sie num_ctx auf 16k oder 32k und wählen Sie ein Modell, das tatsächlich gut mit Function Calling umgehen kann.

Ein selbst gehostetes Gateway. Schalten Sie ein selbst gehostetes LiteLLM-Gateway zwischen Octop und alle anderen Komponenten. Dadurch erhalten Sie eine gemeinsame Basis-URL, einen separaten Schlüssel pro Benutzer, Ausgabenlimits und ein zentrales Log. Sie können das dahinter verwendete Modell außerdem austauschen, ohne etwas in Octop zu ändern.

Eine kostenpflichtige API. Sie erhalten die beste Qualität, müssen dafür aber einen klaren Nachteil akzeptieren: Der Inhalt der Unterhaltungen verlässt Ihren Server und wird an den Provider übertragen. Genau das widerspricht einem wesentlichen Zweck des Self-Hostings. Tragen Sie den Schlüssel in docker/.env als OPENAI_API_KEY ein. Die Compose-Datei reicht ihn bereits entsprechend weiter.

Unabhängig von Ihrer Auswahl enthält die Compose-Datei außerdem OCTOP_LANGFUSE_ENABLED, LANGFUSE_PUBLIC_KEY, LANGFUSE_SECRET_KEY und LANGFUSE_BASE_URL. Damit können Sie Traces an Ihre eigene Langfuse-Instanz senden und sehen, was die Agenten tatsächlich tun, statt aus dem Chatfenster zu raten.

Benutzer, Rollen und die gemeinsame Agent-Bibliothek

Das Administratorkonto aus dem ersten Bootvorgang erstellt und verwaltet die übrigen Konten. Jeder Benutzer erhält eigene Agents, einen eigenen Arbeitsbereich und eigene Zugangsdaten. Diese Isolation wird durch das Token gewährleistet, das der Browser speichert. Daneben gibt es einen gemeinsamen Pool aus Skills und Sub-Agents, den jeder verwenden kann. Genau das macht den Betrieb für eine Familie interessant: Eine Person erstellt einmal einen guten Recherche-Agent. Niemand sonst muss ihn neu erstellen.

Seien Sie bei den Tools vorsichtig. Octop bietet eine Genehmigung für Tools und Schutzmechanismen für Shell-Befehle an. Beides funktioniert tatsächlich. Ein Agent, der Shell-Befehle ausführt, führt sie jedoch innerhalb des Octop-Containers aus, in den Ihr Datenvolume eingebunden ist. Die Schutzmechanismen begrenzen, was ein unachtsamer Prompt auslösen kann. Sie bilden keine Sandbox-Grenze. Lassen Sie die Tool-Genehmigung daher für alle Benutzer aktiviert, denen Sie keinen Shell-Zugriff geben würden. Wenn Sie diese Lösung mit anderen Optionen vergleichen, zeigt der Überblick über self-hosted AI-Agents, wie die einzelnen Lösungen damit umgehen.

Ein Projekt aktualisieren, das so schnell Releases veröffentlicht

[
  {
    "version": "v0.9.16",
    "days_since_previous_release": 2
  },
  {
    "version": "v0.9.17",
    "days_since_previous_release": 3
  },
  {
    "version": "v0.9.18",
    "days_since_previous_release": 1
  },
  {
    "version": "v0.9.19",
    "days_since_previous_release": 3
  }
]

Das sind die Tag-Daten aus dem Repository, gezählt bis zum 7. August 2026. In neun Tagen wurden 4 getaggte Releases veröffentlicht. Der kürzeste Abstand betrug 1 Tag. v0.9.19 wurde 3 Tage nach dem vorherigen Tag veröffentlicht. Diese Release-Frequenz ist ein gutes Zeichen für das Projekt, aber ein schlechter Grund, latest ungeprüft auszuführen. Lesen Sie die Änderungen, bevor Sie sie übernehmen:

cd Octop
git fetch --tags
git tag --sort=-creatordate | head
NEW_TAG=$(git tag --sort=-creatordate | head -1)
git log --oneline "v0.9.19..$NEW_TAG"

Erstellen Sie jedes Mal zuerst ein Backup. Datenbankmigrationen werden beim Start ausgeführt. Eine fehlgeschlagene Migration bei einem Projekt vor Version 1.0 müssen Sie selbst beheben:

docker compose -f docker/docker-compose.yml stop
sudo tar czf octop-backup-$(date +%F).tgz -C /srv octop-data
docker compose -f docker/docker-compose.yml start

Checken Sie anschließend den neuen Tag aus und erstellen Sie das Image mit docker compose -f docker/docker-compose.yml up -d --build neu. Falls dabei ein Fehler auftritt, können Sie den alten Tag auschecken und das Image neu erstellen. Dadurch wird der Code wiederhergestellt. Die Datenbank wird jedoch nur durch das Tarball wiederhergestellt.

Dieses Tarball enthält octop.db, config.json, das JWT-Signaturgeheimnis und credential.txt. Es ist daher genauso vertraulich wie der Server selbst. Setzen Sie die Berechtigungen auf 600 und bewahren Sie eine Kopie außerhalb des Servers auf. Für größere Installationen veröffentlicht das Projekt außerdem docker/docker-compose.postgres.yml. Dieses verwendet PostgreSQL mit pgvector statt SQLite.

Fehlerbilder und die dabei angezeigten Meldungen

Die Zustandsprüfung antwortet nie. curl http://127.0.0.1:8088/api/health hängt oder verweigert die Verbindung. Lesen Sie docker compose -f docker/docker-compose.yml logs -f octop. Ein Container, der während der ersten Initialisierung beendet wird, kann das Datenverzeichnis in der Regel nicht beschreiben. Prüfen Sie daher die Eigentümer- und Berechtigungseinstellungen des Verzeichnisses, das Sie für OCTOP_DATA festgelegt haben.

Das Dashboard wird geladen, aber der Chat hängt. Auf der Seite erscheint kein Fehler, und es kommt nie eine Antwort. Öffnen Sie die Browserkonsole und suchen Sie nach einer fehlgeschlagenen Verbindung zu wss://octop.example.com/agents/.../chat/ws. Der Proxy leitet das Upgrade nicht weiter. Ergänzen Sie proxy_http_version 1.1 sowie die Header Upgrade und Connection.

Die gesamte Antwort erscheint mehrere Sekunden verspätet auf einmal. Das Streaming funktioniert, aber die Pufferung ist aktiviert. Setzen Sie proxy_buffering off.

bind: address already in use. Port 8088 wird bereits von einem anderen Prozess verwendet. sudo ss -tlnp | grep 8088 ermittelt den Prozess. Diese Meldung erscheint auch, wenn Sie in einer Override-Datei einen zweiten Eintrag für ports hinzugefügt haben, statt den ursprünglichen Eintrag zu bearbeiten.

Das korrekte Passwort wird abgelehnt. Fünf fehlerhafte Versuche lösen eine Sperre von 900 Sekunden aus. Warten Sie die Sperrzeit ab, statt die Anwendung neu zu installieren.

Das neue Passwort in .env hatte keine Wirkung. Diese Zugangsdaten werden nur bei der ersten Initialisierung verwendet. Ändern Sie das Passwort im Dashboard.

Der Agent antwortet, führt aber nie ein Tool aus. Fast immer liegt das an einem lokalen Modell: Das Kontextfenster ist für die Tool-Definitionen zu klein, oder das Modell unterstützt Function Calling nur unzureichend. Erhöhen Sie num_ctx und verwenden Sie ein Modell, das für die Tool-Nutzung ausgelegt ist.

FAQ

Ist Octop ein Ersatz für Open WebUI?

Nur wenn Sie die zusätzlichen Funktionen benötigen. Open WebUI ist eine Chat-Oberfläche vor einem Modell und erfüllt diese Aufgabe für eine Person oder einen Haushalt mit gegenseitigem Vertrauen gut. Octop ergänzt Konten mit einer Administratorrolle, benutzerspezifische Arbeitsbereiche und Zugangsdaten sowie eine umschaltbare Bibliothek spezialisierter Agenten. Dadurch können mehrere Personen einen Server gemeinsam nutzen, ohne dieselbe Chat-Historie zu teilen. Wenn ein einzelnes Konto für Sie ausreicht, ist Open WebUI die einfachere und deutlich ausgereiftere Wahl.

Warum sollte ich nicht das Octop-Installationsskript für curl verwenden?

Das Skript wird aus einem Tencent Cloud Object Storage-Bucket bereitgestellt und nicht aus dem Repository. Daher ist es durch keinen git-Tag und keinen Commit abgedeckt. Sie können nicht vergleichen, was es heute mit dem tut, was es letzte Woche getan hat. Wenn Sie es in bash weiterleiten, wird es ausgeführt, bevor Sie es gelesen haben. Außerdem installiert es sich mit einer eigenen Python-3.12-Umgebung direkt auf dem Host und außerhalb Ihres Paketmanagers. Laden Sie es herunter und lesen Sie es zuerst, oder stellen Sie die Anwendung mit Docker Compose aus einem ausgecheckten Tag bereit.

Kann Octop ein lokales Modell statt einer kostenpflichtigen API verwenden?

Ja. Octop unterstützt OpenAI-kompatible APIs und wird mit einer Ollama-Voreinstellung ausgeliefert. Wenn Sie es auf http://host.docker.internal:11434/v1 verweisen, funktioniert es, sobald Sie extra_hosts: ["host.docker.internal:host-gateway"] in den Container übernehmen und OLLAMA_HOST=0.0.0.0:11434 auf dem Host setzen. Schränken Sie den Firewall-Zugriff auf Port 11434 auf den Adressbereich von Docker ein, weil Ollama keine eigene Authentifizierung besitzt. Setzen Sie Ollamas num_ctx auf 16k oder höher. Agenten-Prompts mit Tool-Definitionen überschreiten sonst das standardmäßige Kontextfenster, woraufhin das Modell keine Tools mehr aufruft.

Benötige ich einen Reverse Proxy, oder kann ich Port 8088 öffnen?

Sie benötigen den Proxy. Die mit Octop ausgelieferte Compose-Datei veröffentlicht Port 8088 auf jeder Schnittstelle ohne TLS. Dadurch würden Passwörter und Bearer-Tokens unverschlüsselt über das Internet übertragen. Ändern Sie den veröffentlichten Port in 127.0.0.1:8088:8088 und schalten Sie Caddy oder nginx mit einem Zertifikat davor. Bei nginx müssen Sie die Header für das WebSocket-Upgrade weiterleiten und proxy_buffering off setzen. Andernfalls wird die Seite geladen, während der Chat ohne sichtbare Fehlermeldung nicht antwortet.

Ist Octop für den Produktivbetrieb bereit?

Octop ist noch vor Version 1.0 und veröffentlicht seit August 2026 mehrere getaggte Releases pro Woche. Betrachten Sie es daher als vielversprechend, aber noch nicht als ausgereift. Für eine Familie oder ein kleines internes Team kann der Einsatz vertretbar sein, wenn Sie einen exakten Tag festlegen, vor jedem Upgrade das Commit-Protokoll lesen und vor jedem Neuaufbau ein Backup des Daten-Volumes erstellen. Betreiben Sie es nicht auf latest und speichern Sie dort noch keine Kundendaten.