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 de navigateur 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 ce 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 repose sur une seule base de données SQLite sous ~/.octop/. Tout ce qui suit concerne le tag v0.9.19, publié le 5 août 2026. Si vous hésitez encore entre plusieurs plateformes, la comparaison des alternatives à Open WebUI exécutables sur un VPS couvre un éventail plus large.

Un point doit être clair avant d’y consacrer une soirée. Au moment de la rédaction de ce guide, Octop était un logiciel antérieur à la version 1.0, publié depuis l’organisation GitHub d’un éditeur, et comptait environ 900 stars en août 2026. Depuis, le projet a publié le tag v1.0.0 le 14 septembre 2026. Au 20 octobre 2026, le dernier tag est v1.0.2, une version stable publiée le 18 octobre 2026 après une série de tags beta 1.0.2. Le dépôt compte alors environ 10 400 stars. Les étapes ci-dessous ont été rédigées pour v0.9.19 et n’ont pas été retestées sur 1.x. Le projet évolue rapidement, comme le montrent les numéros de version, et rien ne garantit ici un chemin de mise à niveau stable. Épinglez un tag, consultez 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 épinglant la version v0.9.19

Le fichier Compose fourni avec v0.9.19 construit l’image à partir du dépôt. Dans ce guide, épingler une version signifie donc extraire un tag git. Des images publiées existent aussi. L’arborescence v0.9.19 contient déjà un workflow docker-publish.yml, ajouté dans v0.9.8 le 15 juillet 2026. Ce workflow construit une image et la pousse vers Docker Hub pour chaque tag v*. Depuis le 20 octobre 2026, le projet publie également ses images dans le registre de conteneurs de GitHub (docker pull ghcr.io/tencentcloud/octop:1.0.2). Construire l’image à partir du tag extrait reste la méthode la plus stricte, car vous compilez exactement le code que vous avez lu au lieu de faire confiance à un tag de registre. C’est une étape de plus que ce que demandent 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 du tag et de construction 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 une fois, vous en connaissez donc le principe.

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

Remarquez le bloc build:. image: octop:latest est le nom attribué à votre propre build, et non une référence de registre. Ici, latest désigne donc la version compilée la plus récemment. Définissez explicitement le chemin des données au lieu de laisser Compose utiliser une valeur par défaut. Définissez également un vrai mot de passe pour le compte administrateur avant le premier démarrage. Placez 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 d’être signalé. Compose lit docker/.env uniquement pour interpoler les variables ${...} dans le fichier YAML. Une clé ajoutée dans ce fichier n’est pas transmise au conteneur si elle n’est pas également déclarée sous environment: dans le fichier Compose. Ajouter OCTOP_ACCESS_TOKEN_TTL à .env uniquement ne produit donc absolument aucun effet, sans afficher d’erreur. Vous pouvez aussi écrire ces mêmes clés dans ~/.octop/env, à l’intérieur du répertoire de données monté. Octop les charge au démarrage. Le guide sur les fichiers env et les secrets dans Docker Compose explique pourquoi ces deux mécanismes sont différents.

Construisez 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 fonctionnelle répond au health check avec un objet JSON similaire à {"ok":true,"started_at":...,"db":...,"users_loaded":0,"agents_running":0}. Dans tout autre cas, consultez docker compose -f docker/docker-compose.yml logs -f octop avant d’ouvrir le navigateur.

Donnez maintenant un nom explicite à l’image que vous venez de construire. 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 est exécuté et les identifiants initiaux sont écrits 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. Cela explique une question très fréquente : 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 d’Octop pour OCTOP_BIND_HOST 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 modification est correcte. C’est la publication du port qui vous expose.

Modifiez la ligne ports: dans docker/docker-compose.yml afin que le mapping n’écoute que 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 au port. Si vous voulez conserver le fichier upstream intact, utilisez le tag !override sur la séquence. C’est la méthode documentée pour remplacer une séquence au lieu d’y ajouter des éléments. L’explication de la fusion de plusieurs fichiers Compose présente les autres règles de fusion.

La liaison à la loopback résout également un problème que vous rencontreriez sinon avec le firewall. Docker écrit ses 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é. Avec Docker Engine 28.0.0 ou une version ultérieure, un port lié à 127.0.0.1 n’est pas accessible depuis l’extérieur, quelle que soit la configuration de ufw. C’est pourquoi cette solution est la bonne, et non une solution de second choix. Les anciennes versions d’Engine permettent aux hôtes du même segment L2, par exemple d’autres machines connectées au switch de votre fournisseur, d’accéder aux ports publiés sur localhost. Exécutez donc docker version et effectuez la mise à niveau si le serveur indique une version inférieure à 28.

Mettre TLS en frontal 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 relaie les WebSockets sans configuration supplémentaire :

octop.example.com {
    reverse_proxy 127.0.0.1:8088
}

nginx demande davantage de précautions, 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 /api/agents/{id}/chat/ws. Sans proxy_http_version 1.1 et les deux en-têtes de mise à niveau, nginx répond à la tentative de mise à niveau 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 en un seul bloc à la fin au lieu d’être transmis progressivement. proxy_read_timeout couvre les exécutions longues des outils. 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 journaux.

Fonctionnement de l’authentification JWT derrière le proxy

Octop s’authentifie avec un bearer token, pas avec un cookie. POST /api/auth/login renvoie {access_token, role, user, ...} et les appels suivants 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’attribut Secure et pas de règle SameSite à configurer incorrectement. Une session qui fonctionnait sur http://127.0.0.1:8088 se comporte donc de la même manière sur https://octop.example.com.

Deux conséquences doivent être connues avant d’y connecter de vrais utilisateurs.

Le WebSocket transporte le token dans l’URL. Le endpoint est WS /api/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, TLS 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 pour 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. Placez donc ceci dans le bloc http et 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 vaut 86400 par défaut. 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 ce fonctionnement est trop contraignant, réduisez la durée de validité. Pensez aussi à ajouter la variable à la liste environment: ainsi qu’à .env :

OCTOP_ACCESS_TOKEN_TTL=28800

La protection contre la force brute est intégrée : OCTOP_LOGIN_MAX_ATTEMPTS vaut 5 échecs par défaut et OCTOP_LOGIN_LOCKOUT_SECONDS vaut 900. Un utilisateur bloqué doit donc simplement attendre quinze minutes ; il ne s’agit pas d’une installation défaillante. Octop possède son propre stockage des 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 devant lui un proxy d’authentification. C’est précisément le rôle de 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 qui publie aussi rapidement

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

Il s’agit des dates des tags du dépôt, relevées au 7 August 2026. 4 releases taguées ont été publiées en neuf jours, avec un intervalle de seulement 1 jour, puis v0.9.19 est arrivé 3 jours après le tag précédent. Cette cadence est un bon signe pour le projet, mais une mauvaise raison d’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"

Vérifiez ce que contient réellement $NEW_TAG avant de faire le checkout, car les tags du projet incluent des versions beta comme v1.0.2b9 en plus des releases stables. Au 20 October 2026, le tag le plus récent est la version stable v1.0.2, publiée le 18 October 2026. Le passage depuis v0.9.19 inclut la release v1.0.0 du 14 September 2026. Le journal est donc long et mérite une lecture attentive.

Faites toujours une sauvegarde au préalable, car les migrations de base de données s’exécutent au démarrage. Une migration qui échoue sur un projet publié à ce rythme, 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

Faites ensuite le checkout du nouveau tag et reconstruisez avec docker compose -f docker/docker-compose.yml up -d --build. En cas de problème, revenir à l’ancien tag et reconstruire permet de restaurer le code, mais seul le tarball permet de restaurer 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 à la place de SQLite.

Modes d’échec et messages affichés

Le health check ne répond jamais. 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 indiqué dans OCTOP_DATA.

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

Toute la réponse apparaît d’un coup, avec plusieurs secondes de retard. Le streaming fonctionne, mais la mise en mémoire tampon est activée. Définissez proxy_buffering off.

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

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 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 utiliser des outils.

FAQ

Octop remplace-t-il Open WebUI ?

Seulement si vous avez besoin de ce qu’il ajoute. Open WebUI est une interface de chat devant un modèle. Elle convient bien à 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 d’agents spécialisés entre lesquels les utilisateurs peuvent basculer. 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 devrais-je 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 fait de le rediriger vers bash l’exécute avant que vous ne l’ayez lu. Il s’installe aussi 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 Octop avec Docker Compose depuis un tag extrait du dépôt.

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

Oui. Octop prend en charge les API compatibles avec OpenAI et fournit un preset Ollama. Il suffit de le faire pointer vers http://host.docker.internal:11434/v1 après avoir ajouté extra_hosts: ["host.docker.internal:host-gateway"] au conteneur et défini OLLAMA_HOST=0.0.0.0:11434 sur l’hôte. Filtrez le port 11434 pour n’autoriser que la plage d’adresses de Docker, car Ollama n’a pas d’authentification intégrée. Prévoyez d’augmenter num_ctx d’Ollama à 16k ou plus, car les prompts des agents contenant les définitions des outils dépassent la fenêtre de contexte par défaut. 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 traverseraient donc Internet en clair. Remplacez le port publié par 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 ?

En août 2026, Octop était encore en version pré-1.0 et publiait plusieurs releases taguées par semaine. Il a publié le tag v1.0.0 le 14 septembre 2026, puis une série de tags bêta 1.0.2 avant la version stable v1.0.2 du 18 octobre 2026. Le rythme reste élevé. Considérez donc Octop comme prometteur, mais pas encore mature. Cela peut convenir à une famille ou à une petite équipe interne si vous verrouillez 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.