2026 Dify 1.18.0 : KnowledgeFS peut-il être auto-hébergé ? À vérifier avant activation

La publication de Dify 1.18.0 date du 23 octobre 2026 et classe Agent Knowledge Base en version bêta. Conséquence pratique : une équipe dont les flux Classic Knowledge fonctionnent n’a pas de raison de migrer immédiatement. KnowledgeFS est une intégration facultative, décrite comme un service indépendant avec sa propre base de données. En Community Edition, vérifiez d’abord les conditions d’activation et la disponibilité des images ; ne le choisissez pas par défaut pour une base de connaissances de production.

À qui s’adresse ce guide ?
Aux équipes qui exploitent Dify Community Edition et évaluent la mise à niveau vers la version 1.18.0.
Aux responsables de bases documentaires qui doivent comprendre les effets sur les services, les droits et les données.
Aux équipes qui dimensionnent une installation autohébergée et veulent séparer plateforme, connaissances et inférence.

Dernière mise à jour : 26 octobre 2026. Vérification fondée sur la publication officielle de Dify, sa documentation de déploiement et les fichiers de configuration associés.

Dify 1.18.0 et KnowledgeFS : la décision dépend du flux visé

Le numéro de version ne constitue pas un motif suffisant pour remplacer une base de connaissances qui fonctionne. Il faut partir de l’usage attendu et de la forme de déploiement.

• Conserver Classic Knowledge si les flux de récupération actuels répondent aux besoins, que les utilisateurs disposent des bons accès et que les résultats peuvent être contrôlés. La publication de la version 1.18.0 confirme que Classic Knowledge reste disponible ; KnowledgeFS n’est donc pas présenté comme un remplacement obligatoire. Les notes officielles de la version sont la référence pour ce point.
• Évaluer Agent Knowledge Base si l’équipe a besoin des espaces de connaissances destinés aux agents et des fonctions de recherche qui leur sont associées. Il faut confirmer que ces fonctions répondent à un cas d’usage précis avant d’ajouter de nouveaux composants.
• Différer l’activation si l’image nécessaire, le périmètre de prise en charge ou la procédure de restauration restent incertains. Une question d’utilisateur sur un dépôt communautaire ne tranche pas la compatibilité ni le support officiel.

La distinction est importante : Classic Knowledge désigne le parcours existant, tandis que KnowledgeFS porte une nouvelle capacité bêta. Les deux ne doivent pas être confondus avec le modèle de génération lui-même. La base sert à organiser et retrouver des contenus ; le modèle peut être exécuté séparément ou appelé depuis un service externe.

Pour une équipe qui prépare un déploiement professionnel, le bon critère n’est donc pas « la nouvelle fonction est-elle disponible ? », mais « le besoin exige-t-il cette fonction, et peut-on l’exploiter avec un retour arrière maîtrisé ? ».

Des situations de déploiement qui ne se valent pas

Les conditions ne sont pas identiques pour tous les modes d’exploitation. Évaluez chaque cas séparément plutôt que d’appliquer une consigne trouvée pour une autre édition.

• Community Edition en installation locale : la configuration Compose par défaut ne lance pas KnowledgeFS. La documentation de mise à niveau indique qu’une activation explicite via une option de développement est requise. Examinez les paramètres réellement utilisés par votre installation avant de modifier le fichier Compose. Le guide Docker officiel décrit le déploiement et les réglages à consulter.
• Déploiement Enterprise : ne déduisez pas la disponibilité de KnowledgeFS des consignes destinées à Community Edition. Demandez confirmation du périmètre fonctionnel et du support correspondant à votre contrat et à votre méthode d’installation.
• Service Cloud : ses dates de disponibilité et son mode de gestion peuvent différer d’une installation locale. Il faut se fier à la communication officielle la plus récente, plutôt que de transposer une procédure d’auto-hébergement.
• Essai interne : prévoyez un environnement isolé, des données non sensibles et un processus de validation. Une fonction bêta est un motif supplémentaire pour traiter séparément la disponibilité, la sauvegarde et le support.

Un échange autour de la publication 1.18.0 peut aider à comprendre les questions soulevées par les utilisateurs, mais ne remplace pas les instructions de déploiement officielles. De même, un problème communautaire sur les images et le parcours de prise en charge rapporte une interrogation d’utilisateur ; ce n’est ni une annonce officielle d’indisponibilité ni la preuve d’un engagement de compatibilité.

Ce que le service supplémentaire change dans l’architecture

La publication de Dify 1.18.0 présente KnowledgeFS comme un service distinct associé à une base de données dédiée. Cela ajoute des éléments à prendre en compte au-delà du déploiement habituel de la plateforme : démarrage du service, configuration, stockage persistant, surveillance et sauvegarde. Les détails doivent être contrôlés pour la version déployée ; ne recopiez pas des variables depuis un exemple destiné à une autre version.

Le fichier officiel d’exemple de configuration KnowledgeFS aide à repérer les paramètres propres au service. Le fichier Compose du dépôt permet de comparer les services déclarés avec ceux présents dans votre environnement. Ce sont des aides à la vérification, pas une garantie que votre installation les active automatiquement.

La séparation produit aussi des conséquences opérationnelles souvent oubliées :

• Persistance : les données de KnowledgeFS doivent avoir un chemin de stockage durable. Un conteneur recréé sans volume correctement configuré peut compromettre des données que l’équipe croyait conservées.
• Sauvegarde : sauvegarder uniquement les fichiers de la plateforme ne démontre pas que la base de données du nouveau service est récupérable. Définissez la sauvegarde et la restauration de chaque composant concerné, puis faites un essai de restauration.
• Droits et périmètre : une nouvelle fonction de connaissance peut modifier la manière dont des agents accèdent aux contenus. Vérifiez qui peut ajouter, consulter et rechercher les documents, et si ces droits restent cohérents dans les flux réels.
• Dépendances de version : le fichier Compose, l’image et les variables doivent correspondre à une même procédure prise en charge. Un assemblage de références provenant de branches ou de versions différentes rend le diagnostic plus difficile.
• Retour arrière : une base de connaissances migrée ou modifiée peut ne pas se réintégrer automatiquement dans le parcours antérieur. Définissez ce qui sera conservé, comment interrompre l’essai et comment revenir aux flux existants avant d’injecter des données utiles.

Une limitation fréquente des déploiements autohébergés est de traiter le lancement du conteneur comme une validation complète. Or, un service qui démarre ne prouve ni que les droits sont corrects, ni que les données persistent après redémarrage, ni qu’une sauvegarde est restaurable. Ces vérifications doivent faire partie du test d’acceptation.

Séparer Dify, les connaissances et l’inférence

Pour estimer les ressources, séparez trois charges plutôt que de les attribuer indistinctement à « Dify ».

1. La plateforme Dify orchestre les applications et les flux.
2. Le stockage et la recherche documentaire comprennent les composants déjà utilisés et, si KnowledgeFS est activé, les dépendances correspondantes.
3. L’inférence correspond au calcul nécessaire pour produire des réponses à partir d’un modèle.

Cette distinction évite de dimensionner le serveur de la plateforme comme s’il devait forcément exécuter le modèle. Si les applications utilisent une API de modèle externe, la charge d’inférence ne se confond pas avec celle des services Dify et de la base documentaire. Il faut néanmoins examiner quelles données sont envoyées au service externe, quelles informations y transitent et quelles règles de confidentialité s’appliquent. Pour structurer cette analyse, consultez les informations sur la confidentialité et établissez le parcours des documents avant de connecter les flux.

Si l’inférence locale est envisagée, vérifiez séparément le modèle, sa licence, la quantification, la longueur de contexte et le budget mémoire. Le seul fait qu’un serveur dispose de mémoire ne permet pas de déduire une vitesse de génération ou un niveau de concurrence. L’entraînement et l’inférence à forte charge ne sont pas des objectifs à traiter comme de simples extensions de KnowledgeFS.

Pour le stockage, additionnez les besoins des services persistants, des bases documentaires, des journaux et des sauvegardes que vous gardez localement. Ne confondez pas la capacité disponible dans le système avec l’espace réellement utilisable après configuration et rétention. Les exigences officielles du déploiement et les mesures de votre propre environnement sont préférables à un seuil mémoire inventé ou extrapolé depuis une installation différente.

Une vérification décisionnelle avant l’activation

La liste suivante permet de décider si un essai est suffisamment encadré. Une case non cochée indique un point à résoudre avant de connecter des données importantes.

• [ ] Le besoin fonctionnel est décrit : l’équipe sait ce qu’Agent Knowledge Base doit apporter au-delà de ses flux Classic Knowledge.
• [ ] La version et l’édition sont identifiées : la procédure retenue correspond bien à Dify 1.18.0 et à Community Edition, Enterprise ou Cloud selon le cas.
• [ ] Les consignes officielles actuelles confirment l’activation, et l’équipe a vérifié la configuration Compose utilisée plutôt qu’un exemple isolé.
• [ ] La provenance et la disponibilité de l’image requise sont vérifiées dans les sources officielles correspondant à la version.
• [ ] Les services, la base de données, les variables et les volumes persistants sont recensés ; l’équipe sait où sont écrites les données.
• [ ] Une sauvegarde de l’environnement existant est disponible et un essai de restauration a démontré le retour des données nécessaires.
• [ ] Le test utilise un jeu de données adapté ; les droits, les résultats de recherche, les journaux et les flux d’agents sont contrôlés.
• [ ] La procédure d’arrêt de KnowledgeFS et de retour au parcours antérieur est écrite et comprise par les personnes qui exploitent la plateforme.

Pour un essai, cochez au minimum les points sur la prise en charge, l’image, la persistance et la restauration avant d’ajouter des données non remplaçables. Pour la production, validez aussi les règles d’accès, le comportement des agents et l’exploitation après mise à jour.

Une notation éditoriale peut aider à rendre le choix explicite, sans la confondre avec une mesure de performance. L’échelle ci-dessous est un outil de décision fondé sur les critères décrits dans cet article, pas un résultat de test :

• Conserver Classic Knowledge — 5/5 lorsque les flux actuels répondent au besoin et qu’aucune fonction Agent nouvelle n’est requise.
• Essayer KnowledgeFS en environnement isolé — 3/5 lorsque le besoin est identifié, mais que l’équipe doit encore valider l’image, l’exploitation ou la restauration.
• Basculer directement une base de production — 1/5 tant que le support, les droits, la sauvegarde et le retour arrière ne sont pas démontrés.

La note ne mesure pas la qualité du logiciel. Elle traduit le niveau de prudence conseillé au vu du caractère bêta et des vérifications de déploiement nécessaires. Une équipe qui obtient des confirmations officielles supplémentaires peut réévaluer sa décision ; elle ne devrait pas remplacer ces confirmations par une supposition fondée sur le seul statut du code.

FAQ sur l’auto-hébergement de KnowledgeFS

L’édition communautaire de Dify peut-elle faire tourner KnowledgeFS sur un serveur privé ?

La documentation de Dify 1.18.0 indique une activation explicite pour le déploiement local en Community Edition, tandis que la configuration Compose par défaut laisse la fonction désactivée. Cela ne suffit pas à établir que chaque image ou parcours de déploiement est pris en charge. Vérifiez les instructions officielles et la disponibilité de l’image avant de réserver un environnement d’essai.

En quoi l’Agent Knowledge Base diffère-t-elle d’une base Classic Knowledge ?

Classic Knowledge correspond aux bases et aux flux de récupération déjà utilisés dans les projets Dify. Agent Knowledge Base vise un espace de connaissances destiné aux agents et aux nouveaux usages de recherche associés. La publication la présente comme une fonction bêta facultative, pas comme un remplacement imposé. Le choix dépend donc des fonctions nécessaires à votre flux, pas du seul numéro de version.

KnowledgeFS ajoute-t-il des composants à l’installation existante ?

Oui. La publication de Dify 1.18.0 décrit KnowledgeFS comme un service indépendant avec une base de données dédiée. Il faut donc vérifier les dépendances, les variables de configuration, la persistance et le chemin de sauvegarde séparément des services déjà en place. Le dépôt d’exemple de configuration aide à repérer ces paramètres, sans prouver à lui seul la compatibilité de chaque image.

Une base Classic Knowledge doit-elle être migrée après la mise à niveau ?

Pas uniquement parce que Dify 1.18.0 est installé. Si les bases, les recherches et les flux existants répondent aux besoins, conservez-les et testez KnowledgeFS à part seulement si ses fonctions Agent sont utiles. Avant toute migration, documentez les données concernées, vérifiez les droits, réalisez une sauvegarde restaurable et définissez une procédure de retour à l’ancien flux.

Choisir l’infrastructure après avoir clarifié le besoin

Pour une équipe qui conserve Classic Knowledge, le meilleur choix peut être de ne pas ajouter de service et de ne pas modifier une architecture stable. À l’inverse, un essai séparé devient pertinent lorsque les fonctions Agent répondent à un besoin identifié et que l’équipe a confirmé le parcours de déploiement.

Un environnement partagé peut convenir à une charge réduite ou à une expérimentation courte, mais les ressources partagées peuvent rendre les performances moins prévisibles ; les offres peuvent aussi imposer des limites de configuration, de stockage ou de facturation. Un serveur physique dédié est plus adapté lorsque l’équipe veut maîtriser durablement les ressources et les services qu’elle héberge. Il ne valide toutefois ni la compatibilité de KnowledgeFS ni son niveau de support : ces points restent à confirmer auprès de la documentation de Dify.

Lorsque l’architecture et les besoins sont clarifiés, comparez les ressources nécessaires aux informations actuelles de l’offre NodeKVM, sans présumer qu’un service est préinstallé ou validé pour KnowledgeFS. Les conditions et les caractéristiques à jour sont consultables sur la page des offres NodeKVM. Si l’image, la restauration ou le périmètre de prise en charge restent incertains, gardez Classic Knowledge en production et limitez KnowledgeFS à un essai isolé.

Questions

1. Q
   L’édition communautaire de Dify peut-elle faire tourner KnowledgeFS sur un serveur privé ?

   La documentation de Dify 1.18.0 indique une activation explicite pour le déploiement local en Community Edition, tandis que la configuration Compose par défaut laisse la fonction désactivée. Cela ne suffit pas à établir que chaque image ou parcours de déploiement est pris en charge. Vérifiez les instructions officielles et la disponibilité de l’image avant de réserver un environnement d’essai.

2. Q
   En quoi l’Agent Knowledge Base diffère-t-elle d’une base Classic Knowledge ?

   Classic Knowledge correspond aux bases et aux flux de récupération déjà utilisés dans les projets Dify. Agent Knowledge Base vise un espace de connaissances destiné aux agents et aux nouveaux usages de recherche associés. La publication la présente comme une fonction bêta facultative, pas comme un remplacement imposé. Le choix dépend donc des fonctions nécessaires à votre flux, pas du seul numéro de version.

3. Q
   KnowledgeFS ajoute-t-il des composants à l’installation existante ?

   Oui. La publication de Dify 1.18.0 décrit KnowledgeFS comme un service indépendant avec une base de données dédiée. Il faut donc vérifier les dépendances, les variables de configuration, la persistance et le chemin de sauvegarde séparément des services déjà en place. Le dépôt d’exemple de configuration aide à repérer ces paramètres, sans prouver à lui seul la compatibilité de chaque image.

4. Q
   Une base Classic Knowledge doit-elle être migrée après la mise à niveau ?

   Pas uniquement parce que Dify 1.18.0 est installé. Si les bases, les recherches et les flux existants répondent aux besoins, conservez-les et testez KnowledgeFS à part seulement si ses fonctions Agent sont utiles. Avant toute migration, documentez les données concernées, vérifiez les droits, réalisez une sauvegarde restaurable et définissez une procédure de retour à l’ancien flux.