Aller au contenu
PentAGI
Déploiement

Mise à niveau

Mettre à jour une installation vers une nouvelle version, et ce qu'il faut modifier lors du passage de la 2.1.0 à la 2.2.0.

Une mise à jour remplace les images PentAGI et, lorsque la version les a modifiés, les fichiers compose. Vos .env et les volumes de données restent, et les migrations de base de données s’exécutent au démarrage de PentAGI.

Avant de commencer

  • Lisez les notes de version de chaque version postérieure à celle que vous exécutez ; depuis la 2.1.0, elles incluent des notes de mise à niveau.

  • Sauvegardez la base de données. Ni l’installateur ni PentAGI ne le font, et les migrations ne peuvent pas être annulées sans perte de données. Avec les valeurs par défaut PENTAGI_POSTGRES_USER et PENTAGI_POSTGRES_DB :

    docker exec pgvector pg_dump -U postgres -Fc pentagidb > pentagi-backup.dump

    Conservez également des copies de .env et des fichiers compose : l’installateur remplace les fichiers compose sans sauvegarde.

  • Terminez les flows dont vous n’avez plus besoin. Un sandbox encore en cours d’exécution est réutilisé tel qu’il a été créé, avec les paramètres de la version qui l’a créé.

  • Si vous venez de la version 2.1.0, effectuez les modifications décrites dans De 2.1.0 à 2.2.0 sur .env et les fichiers adjacents avant le démarrage de la nouvelle version. Avec la connexion via Google ou GitHub activée, videz dès maintenant OAUTH_GOOGLE_CLIENT_ID et OAUTH_GITHUB_CLIENT_ID ; la section explique pourquoi.

Docker Compose

  1. Téléchargez les fichiers compose de la nouvelle version à côté de votre .env : docker-compose.yml et le fichier de chaque pile optionnelle que vous exécutez. Le conteneur PentAGI ne reçoit que les variables listées dans son fichier compose, donc les nouveaux paramètres dans .env n’ont aucun effet derrière un fichier plus ancien.

    cd ~/pentagi
    curl -O https://raw.githubusercontent.com/vxcontrol/pentagi/main/docker-compose.yml
    # and the file of each optional stack you run, for example:
    curl -O https://raw.githubusercontent.com/vxcontrol/pentagi/main/docker-compose-langfuse.yml
  2. Tirez les images et redémarrez, avec les mêmes fichiers -f que vous utilisez pour démarrer la pile. Sans pull, up -d conserve les images déjà présentes sur l’hôte.

    docker compose pull && docker compose up -d
  3. Actualisez l’image du sandbox sur l’hôte Docker qui exécute les flows, ce que docker compose pull ne fait pas. Les flows créés ensuite l’utilisent.

    docker pull vxcontrol/kali-linux

Le tag d’image latest suit la branche principale. Pour rester sur une seule version, définissez PENTAGI_IMAGE=vxcontrol/pentagi:<version> dans .env.

Installateur

  1. Téléchargez l’installateur de la nouvelle version depuis Démarrage rapide et exécutez-le avec votre .env. L’installateur 2.1.0 ne peut pas se mettre à jour lui-même.
  2. Pour remplacer les fichiers compose, modifiez un paramètre afin que Apply Changes apparaisse dans le menu, sélectionnez-le et répondez y lorsque l’installateur liste les fichiers obsolètes.
  3. Dans le menu de maintenance, exécutez Update PentAGI pour tirer les nouvelles images, et Update Worker Image lorsque cela vous est proposé. Update PentAGI seul conserve les anciens fichiers compose.

De la version 2.1.0 à la version 2.2.0

Fichiers

  • Le fichier compose monte example.bedrock.provider.yml à côté de lui. L’installateur le crée ; lors d’une installation manuelle, créez-le vous-même, un fichier vide suffit : touch example.bedrock.provider.yml.
  • Remplacez docker-compose-langfuse.yml si vous exécutez Langfuse : le fichier 2.1.0 nomme l’image minio/minio, qui n’est plus publiée, donc docker compose pull échoue avec celui-ci. Si votre .env définit MINIO_IMAGE=minio/minio:…, supprimez cette ligne.
  • Pour le knowledge graph, placez examples/neo4j depuis le dépôt à ./neo4j — Graphiti a besoin de son plugin APOC — et consultez Mémoire et connaissances pour les préréglages de modèle. GRAPHITI_MODEL_NAME n’est plus lu.
  • Huit migrations de base de données s’exécutent au premier démarrage. docker compose logs pentagi affiche « Database schema updated successfully » lorsqu’elles sont terminées.

Connexion et accès

  • Tout le monde doit se reconnecter : les sessions de la version 2.1.0 sont refusées. Les jetons API continuent de fonctionner, et les scripts se déconnectent avec POST /api/v1/auth/logout.
  • Un jeton API reçoit une erreur 403 sur les routes REST /users, /roles et /tokens : gérez les comptes, les rôles et les jetons depuis une session de navigateur connectée.
  • La connexion via Google et GitHub connecte désormais une adresse e-mail vérifiée par le provider au compte existant ayant cette adresse, y compris les comptes locaux, avec le rôle de ce compte. La version 2.1.0 ne peut pas modifier l’e-mail d’un compte, donc si la connexion est activée, effectuez la mise à niveau avec OAUTH_GOOGLE_CLIENT_ID et OAUTH_GITHUB_CLIENT_ID vides, déplacez [email protected] vers une adresse que vous contrôlez sous Settings → Account, puis réactivez la connexion. Le Reset Admin Password de l’installateur trouve l’administrateur uniquement par [email protected].
  • Derrière un proxy inverse, définissez TRUSTED_PROXIES, sinon tous les utilisateurs partagent l’adresse du proxy et une rafale d’échecs de connexion verrouille tout le monde pendant 15 minutes — voir Exposition réseau.

Sandboxes

  • Avec DOCKER_INSIDE=true — le template .env par défaut de la version 2.1.0 et de l’installateur — la version 2.1.0 montait le socket Docker de l’hôte dans chaque sandbox. La version 2.2.0 donne aux agents l’accès à Docker uniquement depuis un daemon séparé défini dans DOCKER_INSIDE_HOST ; sans cela, ils n’y ont pas accès, et le journal indique sandbox DISABLED. Avec DOCKER_INSIDE_HOST, laissez DOCKER_SOCKET= vide, sinon le /var/run/docker.sock du template est toujours monté. Consultez Worker node.
  • Terminez les flows démarrés sur la version 2.1.0 : leurs sandboxes conservent l’ancien montage de socket et les capacités jusqu’à ce que le flow soit terminé.
  • Laissez TENANT_ID vide : sur une installation existante, il pointe PentAGI vers un nouveau schéma vide.

Modèles et prompts

  • Le provider personnalisé nécessite LLM_SERVER_KEY : avec une clé vide, il est désactivé, donc pour un serveur sans authentification, définissez n’importe quelle valeur non vide.
  • LLM_SERVER_LEGACY_REASONING est supprimé. Le provider personnalisé envoie reasoning_effort et transforme un budget reasoning.max_tokens en niveau d’effort ; sur les modèles Kimi K2, GLM avant la version 5.2 et MiniMax M, un budget fait désormais échouer l’appel, donc supprimez-le de ces agents.
  • Dans les fichiers de configuration des providers, une entrée d’agent qui laisse max_tokens, temperature, top_p ou n vide obtient désormais les valeurs par défaut du type de provider au lieu de n’envoyer rien.
  • Les modèles par défaut intégrés ont changé pour chaque provider sauf Bedrock ; les providers enregistrés dans Settings → Providers conservent leurs modèles. Cinq configurations incluses dans l’image ont changé de modèles — openrouter, deepinfra, ollama-cloud, moonshot et deepseek. Si LLM_SERVER_CONFIG_PATH ou OLLAMA_SERVER_CONFIG_PATH pointe vers l’un d’eux sous /opt/pentagi/conf/, conservez le fichier 2.1.0 sur l’hôte et montez-le comme configuration personnalisée ou Ollama à la place.
  • Avec EMBEDDING_URL sur un serveur autre que celui d’OpenAI, définissez EMBEDDING_KEY : OPEN_AI_KEY n’y est plus envoyé.
  • Les agents recherchent via un seul outil web_search. Les prompts personnalisés avec {{.GoogleToolName}} et les autres variables par moteur sont ignorés, avec un avertissement dans le journal, jusqu’à ce qu’ils utilisent {{.WebSearchToolName}} ; rebasez les prompts personnalisés du searcher et du pentester sur les nouvelles valeurs par défaut.

Autres changements

  • Dans les deux minutes suivant le démarrage, puis toutes les trois heures, PentAGI signale sa version et un résumé de l’installation à update.pentagi.com ; Vérification des mises à jour liste ce qu’il envoie, et UPDATE_CHECK_INTERVAL=0 le désactive.
  • Le profiler n’écoute plus sur le port 7777 sauf si PPROF_ADDR est défini.
  • Les nouveaux paramètres optionnels incluent la bascule de provider avec LLM_FALLBACK_PROVIDER, DOCKER_PORTS_BASE pour plusieurs instances, DOCKER_IMAGE_SELECTION_MODE et DOCKER_ALLOWED_IMAGES, le moteur de recherche interne WEB_SEARCH_INTERNAL_ENABLED, ainsi que les clés Mistral, xAI, MiniMax et Firecrawl.

Sauvegarde et retour arrière

PentAGI n’exécute jamais les migrations en sens inverse, et les exécuter manuellement supprime des données, donc le moyen de revenir à la version 2.1.0 est la sauvegarde. Arrêtez les services qui utilisent la base de données, recréez-la et restaurez le dump :

docker compose stop pentagi pgexporter
docker exec pgvector dropdb -U postgres pentagidb
docker exec pgvector createdb -U postgres pentagidb
docker exec -i pgvector pg_restore -U postgres -d pentagidb < pentagi-backup.dump

Ensuite, remettez les fichiers .env et compose sauvegardés, définissez PENTAGI_IMAGE=vxcontrol/pentagi:2.1.0 et démarrez la stack. Conservez le nouveau docker-compose-langfuse.yml : l’image MinIO du fichier 2.1.0 ne peut plus être tirée.

Dernière mise à jour le