Héberger Dify : créer vos applications IA en auto-hébergé

Créer un chatbot métier, un assistant documentaire ou un workflow LLM ne devrait pas imposer de développer toute l’infrastructure IA à la main. Dify fournit une interface visuelle pour assembler des modèles, des prompts, des bases de connaissances, des outils et des API dans une même plateforme.

Dify est une plateforme open source de développement d’applications IA orientée LLMOps. Elle permet de créer des chatbots, des agents, des Chatflows et des workflows, puis de les publier sous forme d’application web ou d’API. Sa couche LLMOps facilite aussi la gestion des prompts, des journaux d’exécution et des différents fournisseurs de modèles.

En l’auto-hébergeant, une entreprise garde la maîtrise de la plateforme et de ses bases de connaissances. Cela en fait une alternative intéressante aux plateformes IA entièrement SaaS. Cette souveraineté reste toutefois conditionnelle : elle dépend directement du modèle et des services connectés à Dify.

Dify est une plateforme multi-conteneurs

Dify n’est pas une petite application web monolithique. Son déploiement Docker Compose lance plusieurs services ayant chacun une fonction distincte :

• api pour le backend et les API
• worker pour les traitements asynchrones
• web pour l’interface
• PostgreSQL pour les données applicatives
• Redis pour le cache et les files de tâches
• Weaviate ou une autre base vectorielle pour le RAG
• Nginx comme point d’entrée HTTP
• des services complémentaires comme le sandbox, le proxy SSRF ou le gestionnaire de plugins selon la version

Le fichier Docker Compose officiel dépasse donc largement deux ou trois conteneurs.

Le dépôt annonce un minimum de 2 coeurs CPU et 4 Gio de RAM. Il faut considérer ces valeurs comme un plancher de démarrage, pas comme un dimensionnement de production. L’indexation de documents, les workers et la base vectorielle peuvent provoquer des pics de consommation. Prévoyez une vraie marge de RAM et surveillez la charge avant d’ouvrir la plateforme à plusieurs équipes.

Prérequis pour héberger Dify

Préparez les éléments suivants :

• un VPS Linux 64 bits avec suffisamment de RAM et d’espace disque
• Docker Engine et le plugin Docker Compose (voir installer Docker sur un VPS)
• Git
• un nom de domaine ou sous-domaine, par exemple dify.exemple.fr
• un enregistrement DNS pointant vers l’adresse IP du VPS
• les ports 80 et 443 accessibles
• une stratégie de sauvegarde hors du serveur

Les VPS TalCloud constituent une base pour ce type de déploiement, avec des serveurs situés en France, du stockage NVMe, la protection Anti-DDoS Netrix et un support humain. Les offres démarrent à 4,99 € par mois, à dimensionner selon la charge réelle.

Aucun GPU n’est annoncé non plus. C’est un point important si vous comptez exécuter Ollama sur le même serveur : les performances dépendront du modèle choisi, de sa quantification, de la RAM disponible et du processeur.

Installer Dify avec Docker Compose

Le déploiement recommandé repose sur le dépôt officiel langgenius/dify. Connectez-vous au VPS, placez-vous dans le répertoire prévu pour les applications, puis clonez le projet :

git clone https://github.com/langgenius/dify.git
cd dify/docker

Créez le fichier de configuration local à partir de l’exemple :

cp .env.example .env

Avant le démarrage, ouvrez .env et vérifiez au minimum les mots de passe, les secrets, les URL publiques, les ports exposés et le choix de la base vectorielle. Ne publiez jamais ce fichier dans un dépôt Git.

Lancez ensuite l’ensemble des services :

docker compose up -d

Contrôlez leur état :

docker compose ps

En cas d’échec, inspectez les journaux :

docker compose logs --tail=200

Les images peuvent être volumineuses et le premier démarrage demande un certain temps, notamment pour initialiser PostgreSQL et les services associés. Reportez-vous au fichier docker/README.md du dépôt officiel pour la procédure correspondant à la version que vous déployez.

Premier accès et création du compte administrateur

Une fois les conteneurs prêts, ouvrez l’adresse suivante :

http://ADRESSE_DU_SERVEUR/install

Avec un domaine déjà configuré, utilisez plutôt :

http://dify.exemple.fr/install

L’écran d’installation permet de créer le premier compte administrateur et l’espace de travail. Choisissez un mot de passe unique et robuste. Après cette initialisation, l’URL /install ne doit plus proposer la création d’un nouvel administrateur.

Avant toute utilisation réelle, configurez le HTTPS. Évitez de déposer des documents internes ou des clés API sur une interface encore accessible en HTTP.

Brancher un modèle : Ollama local ou API externe

Dify orchestre les modèles, mais n’héberge pas automatiquement le LLM. Sans fournisseur configuré, la plateforme ne peut pas générer de réponses.

Deux approches sont possibles.

Option souveraine : Ollama local

Ollama permet d’exécuter un modèle open source sur une infrastructure que vous contrôlez. Pour préserver la souveraineté, installez Ollama sur le même serveur ou sur une machine privée joignable uniquement depuis Dify. Consultez notre guide pour héberger un LLM avec Ollama afin de préparer ce service et choisir un modèle adapté.

Dans Dify, ouvrez les paramètres de l’espace de travail, puis la section des fournisseurs de modèles. Installez ou activez le fournisseur Ollama et renseignez son URL interne.

Attention à l’adressage Docker : localhost utilisé depuis le conteneur Dify désigne ce conteneur, pas automatiquement l’hôte. Utilisez une adresse accessible depuis le réseau Docker, une passerelle configurée ou un service Ollama placé sur un réseau commun.

Pour une application RAG entièrement locale, configurez à la fois :

• un modèle de conversation
• un modèle d’embeddings pour vectoriser les documents et les requêtes

Cette solution limite les sorties de données, mais consomme les ressources du serveur. Un grand modèle exécuté sans GPU peut offrir une latence élevée.

Option API externe

Dify peut aussi appeler OpenAI ou d’autres fournisseurs. Cette configuration est souvent plus rapide à mettre en place et évite d’exécuter le modèle localement.

En contrepartie, les prompts et les extraits de documents envoyés au modèle quittent votre infrastructure. L’auto-hébergement de Dify ne rend donc pas automatiquement l’ensemble du traitement souverain. Vérifiez les conditions contractuelles, la localisation des traitements, la conservation des données et les paramètres de confidentialité du fournisseur.

Créer un premier assistant RAG

Un assistant documentaire constitue un bon premier projet. Le principe du RAG consiste à rechercher les passages pertinents dans une base de connaissances, puis à les transmettre au modèle comme contexte.

Dans Dify :

1. Ouvrez la section des connaissances et créez une nouvelle base.
2. Importez quelques documents représentatifs, par exemple des PDF, fichiers DOCX ou TXT.
3. Configurez le découpage des textes et le modèle d’embeddings.
4. Attendez la fin de l’indexation.
5. Utilisez le test de récupération avec plusieurs questions précises.
6. Dans Studio, créez une application de chat ou un Chatflow.
7. Associez la base de connaissances à l’application.
8. Ajoutez un prompt demandant au modèle de répondre à partir des sources et d’indiquer lorsqu’une information manque.
9. Testez les réponses, les sources retournées et les cas hors périmètre.

Dify prend en charge l’importation de fichiers, leur découpage en segments et leur indexation asynchrone.

Ne validez pas seulement les réponses faciles. Testez les questions ambiguës, les documents contradictoires, les informations absentes et les tentatives d’injection de prompt présentes dans les fichiers.

Exposer Dify en HTTPS

Le sous-domaine public doit pointer vers un reverse proxy chargé de terminer TLS et de transmettre les requêtes à Dify. Vous pouvez utiliser le Nginx fourni par la stack et son intégration Certbot, ou conserver un reverse proxy déjà installé sur le serveur, comme Nginx Proxy Manager.

Dans ce second cas, faites écouter le Nginx de Dify sur un port local non public, puis transmettez https://dify.exemple.fr vers ce port. Configurez aussi les URL publiques correspondantes dans .env.

N’exposez directement ni PostgreSQL, ni Redis, ni Weaviate. Seuls SSH, HTTP et HTTPS doivent être ouverts selon vos besoins. Activez ensuite la redirection permanente de HTTP vers HTTPS et vérifiez la taille maximale des fichiers autorisée par le proxy.

Sécuriser l’instance

Pour une utilisation professionnelle :

• utilisez des clés SSH et désactivez l’authentification SSH par mot de passe si possible
• limitez les comptes administrateurs
• protégez les clés des fournisseurs et le fichier .env
• contrôlez les plugins et outils autorisés à appeler des services externes
• appliquez un filtrage réseau entre Dify, Ollama et les bases de données avec le pare-feu
• surveillez les journaux, l’espace disque et les redémarrages de conteneurs
• définissez une durée de conservation pour les conversations et les logs
• documentez les flux de données pour votre conformité RGPD

Un hébergement en France facilite la maîtrise de la localisation de l’infrastructure, mais il ne remplace pas l’analyse des sous-traitants et des API externes utilisées.

Mettre à jour et sauvegarder Dify

Sauvegardez l’instance avant chaque mise à jour. Depuis le dépôt :

cd /chemin/vers/dify
git pull
cd docker
docker compose pull
docker compose up -d
docker compose ps

Lisez les notes de version et comparez .env avec .env.example, car de nouvelles variables ou migrations peuvent être ajoutées.

La sauvegarde doit couvrir au minimum PostgreSQL, la base vectorielle et docker/volumes/app/storage. Préférez un export cohérent de PostgreSQL, le mécanisme de sauvegarde adapté au moteur vectoriel, puis une copie du stockage des fichiers. Conservez ces sauvegardes sur un emplacement séparé et testez régulièrement une restauration complète.