Auto-héberger Octop avec Docker Compose sur un VPS

Ce qu’est Octop et pourquoi l’auto-héberger

Octop est un assistant IA auto-hébergé pour un foyer ou une petite équipe. L’intérêt de l’auto-héberger plutôt que d’utiliser une simple interface de chat est qu’il sépare les utilisateurs. Open WebUI fournit une interface web devant un modèle. Octop ajoute des comptes avec un rôle d’administrateur, un espace de travail privé et un jeu d’identifiants pour chaque utilisateur, ainsi qu’une bibliothèque d’agents spécialisés entre lesquels chaque utilisateur peut basculer selon la tâche. C’est cette différence qui permet à un seul VPS de servir cinq personnes au lieu d’une seule.

Le projet se trouve sur github.com/TencentCloud/Octop. Il s’agit d’un processus unique qui fournit un tableau de bord web, une interface en ligne de commande, des canaux de chat (Feishu, DingTalk, QQ, Discord, WeCom) et des tâches planifiées. L’ensemble s’appuie sur une seule base de données SQLite dans ~/.octop/. Tout ce qui suit concerne le tag v0.9.19, publié le 5 August 2026. Si vous hésitez encore entre plusieurs plateformes, la comparaison des alternatives à Open WebUI que vous pouvez exécuter sur un VPS couvre un éventail plus large.

Un point doit être clair avant d’y consacrer une soirée. Octop est un logiciel antérieur à la version 1.0, publié depuis l’organisation GitHub d’un éditeur, avec environ 900 étoiles en August 2026. Le projet évolue rapidement, comme l’indiquent les numéros de version, et rien ne garantit ici un parcours de mise à niveau stable. Épinglez un tag, lisez le changelog et conservez des sauvegardes.

Ce dont vous avez besoin avant de commencer

• Un VPS sous Ubuntu 24.04 avec Docker Engine et le plugin Compose. Vous débutez avec Compose ? Commencez par les bases de Docker Compose pour un VPS.
• git, car vous allez récupérer un tag de release plutôt qu’une image.
• Un nom de domaine qui pointe vers le VPS, car vous voulez placer TLS (Transport Layer Security) devant ce service.
• Un backend de modèle compatible avec l’API OpenAI : une instance Ollama locale, une gateway auto-hébergée ou une clé payante.

Octop est léger. Il s’agit d’un processus Python et d’un fichier SQLite. Le poids vient du backend de modèle. Si vous prévoyez d’exécuter le modèle sur le même serveur, dimensionnez-le en conséquence.

Pourquoi nous ne recommandons pas l’installateur curl

Le README commence par une installation en une seule ligne :

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

Nous ne la recommandons pas sur un serveur auquel vous tenez, pour une raison concrète : ce script ne se trouve pas dans le dépôt. Il est servi depuis un bucket Tencent Cloud Object Storage. Rien ne le rattache à un tag ou à un commit Git. Vous ne pouvez donc pas comparer le script d’aujourd’hui avec celui de la semaine dernière, et aucun historique n’explique les modifications. Le bucket peut servir un contenu différent demain sans que le projet en conserve la trace. Envoyer directement le résultat vers bash signifie également que la machine exécute le script avant que vous en ayez lu une seule ligne.

L’installateur écrit également sur l’hôte, et non dans un conteneur. Il utilise uv pour récupérer Python 3.12 et créer un environnement dont votre gestionnaire de paquets ne connaît pas l’existence. Sa suppression ultérieure doit donc être effectuée manuellement.

Deux options sont préférables. Récupérez le script, lisez-le, puis exécutez-le. Cela vous prend trente secondes : curl -fsSL <url> -o install.sh, puis less install.sh, puis bash install.sh. Vous pouvez aussi utiliser Docker, ce que nous ferons dans la suite de ce guide. Le paquet PyPI (pip install octop) est au moins un artefact versionné que vous pouvez verrouiller sur une release.

Déployer Octop avec Docker Compose, en verrouillant la version sur v0.9.19

Aucune image publiée n’est disponible en août 2026. Le fichier Compose fourni construit l’image depuis le dépôt. Verrouiller une version signifie donc extraire un tag Git. C’est une étape de plus que pour la plupart des projets auto-hébergés. Par exemple, un espace de travail AFFiNE auto-hébergé utilise un tag d’image publié et ne construit rien sur votre VPS. La procédure de clonage, d’extraction et de build ci-dessous est la même que celle présentée dans le guide de déploiement d’openGym. Si vous l’avez déjà suivie, vous en connaissez donc la structure.

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

Voici le service défini par le fichier, avec uniquement les éléments importants :

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:-}

Notez le bloc build:. image: octop:latest est le nom attribué à votre propre build, et non une référence vers un registry. latest désigne donc ce que vous avez compilé le plus récemment. Définissez explicitement le chemin des données au lieu de conserver la valeur par défaut. Définissez également un vrai mot de passe pour le compte administrateur avant le premier démarrage. Ajoutez ceci dans docker/.env :

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

Un point important mérite plus d’attention que le reste du fichier. Compose lit docker/.env uniquement pour interpoler les variables ${...} dans le fichier YAML. Une clé ajoutée à ce fichier n’est pas transmise au conteneur, sauf si elle figure également sous environment: dans le fichier Compose. Ajouter OCTOP_ACCESS_TOKEN_TTL à .env uniquement ne produit absolument aucun effet, et aucune erreur n’est affichée. Vous pouvez aussi écrire les mêmes clés dans ~/.octop/env, dans le répertoire de données monté. Octop charge alors ce fichier au démarrage. Le guide sur les fichiers env et les secrets dans Docker Compose explique pourquoi ces deux mécanismes ne sont pas équivalents.

Construisez l’image et démarrez le service :

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

Une instance saine répond au health check avec {"status":"ok","version":"..."}. Dans tout autre cas, consultez docker compose -f docker/docker-compose.yml logs -f octop avant d’ouvrir le navigateur.

Attribuez maintenant à l’image que vous venez de construire un nom explicite. Le prochain --build écrasera octop:latest, et vous ne pourrez plus distinguer les deux images :

docker image tag octop:latest octop:0.9.19

Au premier démarrage, octop init s’exécute et écrit les identifiants initiaux dans le volume de données :

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

Les valeurs par défaut sont admin / octop. Elles ne sont appliquées que lors de la première initialisation. C’est pourquoi une question revient souvent : modifier OCTOP_DEFAULT_PASSWORD après le premier démarrage du conteneur ne change rien, car le compte existe déjà. Modifiez plutôt le mot de passe dans le dashboard.

Ne publiez pas le port 8088

La ligne ports: ci-dessus se lie à toutes les interfaces du VPS. Dès que le conteneur démarre, le dashboard est accessible sur Internet en clair, avec un mot de passe par défaut. La valeur par défaut de OCTOP_BIND_HOST dans Octop est 127.0.0.1 ; le fichier Compose la remplace par 0.0.0.0, car le processus doit accepter le trafic provenant de l’extérieur de son propre espace de noms réseau. Cette substitution est correcte. C’est la publication du port qui vous expose.

Modifiez la ligne ports: dans docker/docker-compose.yml afin que le mapping écoute uniquement sur la loopback :

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

N’essayez pas de corriger cela avec un simple fichier d’override. Compose concatène les listes ports provenant de plusieurs fichiers au lieu de les remplacer. Vous publiez donc les deux mappings, et le second ne peut pas se lier. Si vous souhaitez conserver le fichier upstream intact, utilisez le tag !override sur la séquence. C’est la méthode documentée pour remplacer les éléments au lieu de les ajouter. L’explication de la fusion de plusieurs fichiers Compose couvre les autres règles de fusion.

La liaison à la loopback résout également un problème que vous rencontreriez avec le firewall. Docker écrit les règles de publication des ports dans la table nat, avant les chaînes gérées par ufw. Par conséquent, ufw deny 8088 n’empêche pas l’accès à un port de conteneur publié. Un port lié à 127.0.0.1 n’est jamais accessible depuis l’extérieur, quelle que soit la configuration de ufw. C’est pourquoi cette correction est la bonne, et non une solution de second choix.

Placez TLS devant le service avec un reverse proxy

Caddy est la solution la plus rapide, car il demande lui-même le certificat via ACME (automatic certificate management environment) et proxyfie les WebSockets sans configuration supplémentaire :

octop.example.com {
    reverse_proxy 127.0.0.1:8088
}

nginx demande davantage de configuration, car Octop transmet le chat via un WebSocket :

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;
    }
}

Chaque ligne a une fonction. Le chat utilise WS /agents/{id}/chat/ws. Sans proxy_http_version 1.1 et les deux en-têtes d’upgrade, nginx répond à la tentative d’upgrade avec 400 Bad Request : le dashboard se charge normalement, mais chaque message envoyé reste bloqué indéfiniment sans afficher d’erreur. proxy_buffering off est nécessaire, car l’endpoint de reprise human-in-the-loop renvoie text/event-stream. Les SSE (server-sent events) conservés dans le buffer du proxy arrivent alors en un seul bloc à la fin au lieu d’être transmis progressivement. proxy_read_timeout couvre les exécutions longues des outils, car la valeur par défaut de 60 secondes interrompt un agent au milieu de sa tâche et inscrit upstream timed out (110: Connection timed out) dans les logs.

Fonctionnement de l’authentification JWT derrière le proxy

Octop s’authentifie avec un bearer token, et non avec un cookie. POST /api/auth/login renvoie {access_token, role, user, ...}, puis les requêtes suivantes transmettent Authorization: Bearer <access_token>. Pour un reverse proxy, c’est une bonne nouvelle : il n’y a pas de domaine de cookie, pas d’option Secure et pas de règle SameSite à configurer incorrectement. Une session qui fonctionne sur http://127.0.0.1:8088 se comporte donc de la même manière sur https://octop.example.com.

Deux conséquences sont importantes à connaître avant d’y connecter de vrais utilisateurs.

Le WebSocket transmet le token dans l’URL. L’endpoint est WS /agents/{id}/chat/ws?token=<jwt>, car le JavaScript du navigateur ne peut pas définir d’en-tête Authorization lors du handshake WebSocket. TLS protège ce token pendant son transport. En revanche, il ne le protège pas de vos propres journaux : nginx écrit par défaut la ligne de requête complète, chaîne de requête comprise, dans access_log. Un token valide d’un utilisateur réel se retrouve donc dans un fichier en clair sur le serveur. Journalisez le chemin sans les arguments. $uri correspond au chemin normalisé, avec la chaîne de requête déjà supprimée. Ajoutez donc ceci au bloc http, puis référencez-le depuis le serveur :

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;

Il n’existe pas de déconnexion par session. OCTOP_ACCESS_TOKEN_TTL utilise par défaut la valeur 86400. Un token reste donc valide pendant 24 heures après la connexion. La seule méthode documentée pour en invalider un est octop admin rotate-jwt-secret. Cette commande renouvelle la clé de signature stockée dans ~/.octop/secrets/jwt_secret et invalide immédiatement tous les tokens encore valides, pour tous les utilisateurs. Lorsqu’une personne quitte l’équipe, procédez donc dans cet ordre : supprimez l’utilisateur, renouvelez le secret, puis demandez aux autres utilisateurs de se reconnecter. Si cette procédure vous paraît trop contraignante, réduisez la durée de validité et pensez à ajouter la variable à la liste environment: ainsi qu’à .env :

OCTOP_ACCESS_TOKEN_TTL=28800

La protection contre la brute force est intégrée : OCTOP_LOGIN_MAX_ATTEMPTS est défini par défaut sur 5 échecs et OCTOP_LOGIN_LOCKOUT_SECONDS sur 900. Un utilisateur bloqué doit donc simplement attendre quinze minutes, plutôt que de conclure que l’installation est défectueuse. Octop utilise son propre stockage d’utilisateurs et ne documente pas la prise en charge d’OIDC dans la version v0.9.19. Si vous avez besoin d’un véritable single sign-on, placez un proxy d’authentification devant Octop. C’est le rôle d’un serveur Authentik auto-hébergé.

Configurer Octop avec un backend de modèle

Les fournisseurs se configurent pour chaque agent dans le tableau de bord, et octop provider list vous montre la configuration actuelle. Octop fournit des configurations prédéfinies pour les API compatibles avec OpenAI, DashScope (Qwen) et Ollama. Les identifiants sont stockés dans la table providers de votre propre base de données SQLite. Ce choix détermine ce que vous payez et les données qui quittent le serveur.

Un modèle local avec Ollama. Rien ne quitte le serveur et vous payez en mémoire RAM plutôt qu’en tokens. Le point de configuration qui pose souvent problème est le suivant : un conteneur ne peut pas joindre l’Ollama de l’hôte via 127.0.0.1:11434, car cette adresse correspond à sa propre interface loopback. Ajoutez une entrée de passerelle vers l’hôte au service :

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

Définissez ensuite l’URL de base du fournisseur sur http://host.docker.internal:11434/v1, qui correspond au chemin compatible OpenAI d’Ollama. Saisissez une chaîne non vide quelconque dans le champ de clé API, car Ollama l’ignore, tandis que les clients OpenAI refusent d’envoyer une clé vide. Ollama doit également écouter au-delà de l’interface loopback pour que cela fonctionne. Cela implique OLLAMA_HOST=0.0.0.0:11434 dans son unité systemd. C’est la partie risquée : Ollama n’intègre aucune authentification. Un port 11434 ouvert sur une IP publique devient donc un serveur de modèles gratuit pour le premier qui le détecte. Autorisez uniquement la plage privée de Docker, sudo ufw allow from 172.16.0.0/12 to any port 11434 proto tcp, et refusez le reste. Exécuter Ollama sur un VPS présente le dimensionnement du modèle, tandis que la comparaison entre Ollama et vLLM explique quand Ollama n’est plus le serveur adapté.

Autre avertissement concernant les modèles locaux : le problème ressemble à un bug d’Octop, mais ce n’en est pas un. Les agents fonctionnent en appelant des outils. Le prompt système, les définitions des outils et l’historique forment un prompt volumineux. Ollama sert les modèles avec une fenêtre de contexte par défaut assez limitée. Le début du prompt, qui contient les définitions des outils, sort alors de cette fenêtre. Le modèle cesse ensuite d’appeler les outils ou en invente qui n’existent pas. Augmentez num_ctx à 16k ou 32k et choisissez un modèle réellement performant pour les appels de fonctions. Une réponse qui s’arrête au milieu d’une phrase correspond au problème inverse et à un autre paramètre, num_predict. Si les réponses sont tronquées, consultez l’emplacement de définition de num_predict et la valeur indiquée par done_reason avant d’accuser l’agent. Si vous préférez partir d’un modèle précis plutôt que d’une liste restreinte, Nemotron 3.5 Lightning mérite un essai. Cet article indique le tag exact à télécharger, la quantité de RAM nécessaire et les performances en mode CPU uniquement.

Une gateway auto-hébergée. Placez une gateway LiteLLM auto-hébergée entre Octop et le reste de votre infrastructure. Vous obtenez ainsi une URL de base unique, une clé distincte par utilisateur, des limites de dépenses et un journal unique. Vous pouvez également remplacer le modèle derrière cette gateway sans modifier la configuration d’Octop.

Une API payante. Vous obtenez la meilleure qualité, avec un compromis à accepter : le contenu des conversations quitte votre serveur et est transmis au fournisseur, ce qui remet en question une grande partie de l’intérêt de l’auto-hébergement. La clé se place dans docker/.env sous la forme OPENAI_API_KEY, et le fichier Compose la transmet déjà.

Quel que soit votre choix, le fichier Compose contient également OCTOP_LANGFUSE_ENABLED, LANGFUSE_PUBLIC_KEY, LANGFUSE_SECRET_KEY et LANGFUSE_BASE_URL. Vous pouvez ainsi envoyer les traces vers votre propre instance Langfuse et voir ce que font réellement les agents au lieu de le déduire de la fenêtre de conversation.

Utilisateurs, rôles et bibliothèque d’agents partagée

Le compte administrateur créé lors du premier démarrage crée et gère les autres comptes. Chaque utilisateur dispose de ses propres agents, de son espace de travail et de ses identifiants. Cette isolation repose sur le token conservé par le navigateur. En parallèle, un pool partagé de skills et de sous-agents est accessible à tous. C’est ce qui rend cette solution intéressante pour une famille : une personne peut créer une fois un agent de recherche efficace, sans que les autres aient à le recréer.

Soyez prudent avec les outils. Octop propose une validation des outils et des garde-fous pour les commandes shell, et ces deux mécanismes fonctionnent réellement. Toutefois, un agent qui exécute des commandes shell les exécute dans le conteneur Octop, où votre volume de données est monté. Les garde-fous limitent les actions qu’un prompt imprudent peut déclencher. Ils ne constituent pas une limite de sandbox. Laissez donc la validation des outils activée pour les personnes auxquelles vous ne confieriez pas un shell. Si vous comparez cette solution à d’autres options, le comparatif des agents IA auto-hébergés explique comment chacune gère ce point.

Mettre à niveau un projet dont les versions sortent à ce rythme

[
  {
    "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
  }
]

Voici les dates des tags du dépôt, au 7 août 2026. 4 versions taguées sont sorties en neuf jours. L’intervalle le plus court était de 1 jour. La version v0.9.19 est sortie 3 jours après le tag précédent. Cette cadence est un bon signe pour le projet, mais ce n’est pas une raison suffisante pour exécuter latest. Lisez les changements avant de les appliquer :

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"

Commencez toujours par effectuer une sauvegarde, car les migrations de base de données s’exécutent au démarrage. Une migration qui échoue sur un projet antérieur à la version 1.0, c’est à vous de la corriger :

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

Récupérez ensuite le nouveau tag et reconstruisez avec docker compose -f docker/docker-compose.yml up -d --build. En cas de problème, récupérer l’ancien tag et reconstruire restaure le code. Seul le tarball restaure la base de données.

Ce tarball contient octop.db, config.json, le secret de signature JWT et credential.txt. Il est donc aussi sensible que le serveur lui-même. Conservez-le avec le mode 600 et gardez une copie hors du serveur. Pour une installation plus importante, le projet fournit également docker/docker-compose.postgres.yml, qui exécute PostgreSQL avec pgvector au lieu de SQLite.

Modes de défaillance et messages affichés

Le health check ne reçoit jamais de réponse. curl http://127.0.0.1:8088/api/health se bloque ou refuse la connexion. Consultez docker compose -f docker/docker-compose.yml logs -f octop. Un conteneur qui s’arrête pendant la première initialisation ne peut généralement pas écrire dans le répertoire de données. Vérifiez donc le propriétaire du chemin défini dans OCTOP_DATA.

Le dashboard se charge, mais le chat reste bloqué. La page n’affiche aucune erreur et aucune réponse n’arrive. Ouvrez la console du navigateur et recherchez une connexion échouée vers wss://octop.example.com/agents/.../chat/ws. Le proxy ne transmet pas la mise à niveau de connexion. Ajoutez les en-têtes proxy_http_version 1.1, Upgrade et Connection.

La réponse entière s’affiche d’un seul coup, après plusieurs secondes. Le streaming fonctionne, mais la mise en tampon est activée. Définissez proxy_buffering off.

bind: address already in use. Un autre processus utilise déjà 8088. sudo ss -tlnp | grep 8088 permet d’identifier le processus concerné. Vous obtenez également ce message si vous avez ajouté une deuxième entrée ports dans un fichier de surcharge au lieu de modifier l’entrée originale.

Le mot de passe correct est refusé. Cinq tentatives incorrectes déclenchent un verrouillage de 900 secondes. Attendez la fin du verrouillage au lieu de réinstaller.

Le nouveau mot de passe défini dans .env n’a eu aucun effet. Ces identifiants ne s’appliquent que lors de la première initialisation. Modifiez le mot de passe dans le dashboard.

L’agent répond, mais n’exécute jamais d’outil. Il s’agit presque toujours d’un problème lié au modèle local : la fenêtre de contexte est trop petite pour les définitions des outils, ou le modèle gère mal les appels de fonctions. Augmentez num_ctx et essayez un modèle conçu pour l’utilisation d’outils.

FAQ

Octop remplace-t-il Open WebUI ?

Seulement si vous avez besoin de ce qu’il apporte. Open WebUI est une interface de chat devant un modèle, et il remplit bien ce rôle pour une personne ou un foyer de confiance. Octop ajoute des comptes avec un rôle d’administrateur, des espaces de travail et des identifiants propres à chaque utilisateur, ainsi qu’une bibliothèque sélectionnable d’agents spécialisés. Plusieurs personnes peuvent ainsi partager un serveur sans partager un même historique. Si un seul compte vous suffit, Open WebUI est le choix le plus simple et le plus mature.

Pourquoi ne devriez-vous pas utiliser le script d’installation curl d’Octop ?

Le script est servi depuis un bucket Tencent Cloud Object Storage, et non depuis le dépôt. Il n’est donc couvert par aucun tag ni commit git. Vous ne pouvez pas comparer ce qu’il fait aujourd’hui avec ce qu’il faisait la semaine dernière. De plus, le transmettre par pipe à bash l’exécute avant que vous ne l’ayez lu. Il s’installe aussi directement sur l’hôte, avec son propre environnement Python 3.12, en dehors de votre gestionnaire de paquets. Téléchargez-le et lisez-le d’abord, ou déployez-le avec Docker Compose depuis un tag vérifié.

Octop peut-il utiliser un modèle local au lieu d’une API payante ?

Oui. Octop utilise des API compatibles avec OpenAI et fournit un preset Ollama. Il suffit donc de le pointer vers http://host.docker.internal:11434/v1, puis d’ajouter extra_hosts: ["host.docker.internal:host-gateway"] au conteneur et de définir OLLAMA_HOST=0.0.0.0:11434 sur l’hôte. Limitez le port 11434 à la plage d’adresses de Docker, car Ollama ne fournit aucune authentification native. Prévoyez d’augmenter la valeur de num_ctx d’Ollama à 16k ou davantage. Les prompts des agents contenant des définitions d’outils dépassent sinon la fenêtre de contexte par défaut, et le modèle cesse alors d’appeler les outils.

Ai-je besoin d’un reverse proxy, ou puis-je ouvrir le port 8088 ?

Vous avez besoin du proxy. Le fichier Compose fourni avec Octop publie 8088 sur toutes les interfaces, sans TLS. Les mots de passe et les bearer tokens circuleraient donc en clair sur Internet. Modifiez le port publié en 127.0.0.1:8088:8088 et placez Caddy ou nginx devant, avec un certificat. Avec nginx, transmettez les en-têtes de mise à niveau WebSocket et définissez proxy_buffering off. Sinon, la page se chargera, mais le chat ne répondra jamais, sans afficher d’erreur.

Octop est-il prêt pour la production ?

Le projet est encore en version pré-1.0 et publiait plusieurs releases taguées par semaine en août 2026. Considérez-le donc comme prometteur, mais pas encore stabilisé. Il peut convenir à une famille ou à une petite équipe interne si vous figez un tag exact, lisez le journal des commits avant chaque mise à niveau et sauvegardez le volume de données avant chaque reconstruction. Ne l’exécutez pas sur latest et n’y stockez pas encore de données client.