Installer Dify sur un VPS avec Docker Compose

Ce qu’est Dify et ce que vous vous apprêtez à exécuter

Dify est une plateforme auto-hébergeable permettant de créer des applications basées sur de grands modèles de langage. Elle fournit une interface web pour concevoir des applications de chat, des agents et des pipelines de retrieval, une API pour les appeler depuis votre propre code, ainsi qu’un emplacement central pour gérer les prompts, les jeux de données et les clés des modèles. C’est le type d’outil qu’une petite équipe déploie afin que chacun travaille sur une même base privée, au lieu de disperser les clés d’API dans des scripts. Si les notions d’agent, d’appel d’outil et de pipeline de retrieval restent floues, commencez par reprendre ces concepts depuis le début : les écrans de création de Dify vous sembleront alors être des contrôles familiers plutôt qu’un ensemble de boutons sans libellé.

L’exécuter vous-même implique plusieurs composants. Dify est fourni sous la forme d’un ensemble de conteneurs Docker : un serveur API, un worker en arrière-plan, une interface web, une base de données Postgres, un cache Redis et une base de données vectorielle, tous reliés avec Docker Compose. C’est plus qu’un simple binaire, mais Compose gère l’intégration entre ces composants, et un VPS disposant de quelques gigaoctets de RAM libres l’exécute confortablement. Si ce VPS doit aussi héberger autre chose, dimensionnez-le à partir de mesures réelles plutôt que des chiffres annoncés, car les besoins réels en RAM de PhotoPrism et d’Immich sont nettement supérieurs à leurs minimums publiés, et un serveur photo partageant la machine privera d’abord la base de données et le stockage vectoriel de Dify de ressources. La contention CPU produit le même effet : une bibliothèque Jellyfin présentée comme un vidéoclub des années 90 consomme presque rien lorsqu’elle sert uniquement à parcourir les jaquettes, mais dès qu’un utilisateur lance un transcodage, les files d’attente des workers de Dify passent derrière. L’avantage est que le nombre de conteneurs de Dify reste fixe, quel que soit le nombre d’applications que vous créez, ce qui produit une facture plus progressive que OpenBot, où chaque collègue IA dispose de son propre conteneur et de son propre navigateur, et chaque nouvelle recrue augmente encore le seuil minimal de mémoire.

Comme Dify contient vos clés d’API de modèles et, souvent, des documents privés que vous avez chargés pour le retrieval, considérez la machine qui l’exécute comme sensible dès le premier instant. Ce guide l’installe, puis la sécurise comme vous le feriez pour tout service qui contient des secrets.

Prérequis

Vous avez besoin d’un VPS sous Ubuntu 24.04 avec Docker et le plugin Docker Compose installés, ainsi que d’un utilisateur disposant de sudo ou membre du groupe docker. Si Docker est nouveau pour vous, les bases de Docker Compose sur un VPS présentent l’installation et les commandes principales utilisées dans ce guide. Il est préférable de disposer d’un nom de domaine pointant vers le serveur, car vous voudrez placer TLS devant Dify plutôt que d’utiliser une simple adresse IP.

Étape 1 : Récupérer Dify et ses fichiers Compose

Dify conserve sa configuration Docker dans le dépôt principal. Clonez-le, puis placez-vous dans le répertoire docker :

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

Le fichier .env contient toute la configuration. Lisez-le avant de démarrer quoi que ce soit. Commencez par vérifier les valeurs qui définissent les mots de passe et les secrets : SECRET_KEY, le mot de passe Postgres et le mot de passe Redis. Le fichier d’exemple contient des valeurs de remplacement. Les conserver est la cause la plus fréquente de la compromission d’une instance Dify auto-hébergée. Générez une véritable clé secrète :

openssl rand -base64 42

Collez-la dans SECRET_KEY et définissez une valeur forte et unique pour chaque champ de mot de passe du fichier.

Étape 2 : démarrer le service

Démarrez la stack :

docker compose up -d

Le premier démarrage télécharge plusieurs images et initialise la base de données. Attendez environ une minute. Vérifiez ensuite que les conteneurs sont en bonne santé :

docker compose ps

Chaque service doit afficher running. Par défaut, Dify sert son interface web via un conteneur nginx inclus, sur le port 80. Lors de votre première visite sur http://YOUR_SERVER/install, créez le compte administrateur. Faites-le immédiatement, avant que quoi que ce soit d’autre puisse atteindre le port. Tant que ce compte n’existe pas, toute personne qui charge la page peut le créer et prendre le contrôle de votre instance.

Étape 3 : Ne l’exposez pas directement. Placez TLS et un pare-feu devant

C’est à ce stade que la plupart des installations rapides s’arrêtent et que la plupart des incidents commencent. Le nginx fourni avec Dify écoute sur le port 80, sans chiffrement, sur toutes les interfaces. Vous ne voulez pas que vos identifiants d’administration et vos clés de modèle circulent en HTTP non chiffré. Vous ne voulez pas non plus que les services internes soient accessibles depuis l’extérieur.

Verrouillez le serveur avec un pare-feu en refus par défaut qui n’autorise que SSH et le trafic web :

sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

N’oubliez pas qu’un pare-feu qui ne filtre que l’IPv4 peut laisser les mêmes ports ouverts en IPv6. C’est la faille du pare-feu IPv6 qui piège tant d’administrateurs de serveurs auto-hébergés. Vérifiez que les deux piles réseau sont bien filtrées.

Pour TLS, la méthode la plus propre consiste à lier le port web de Dify à loopback et à placer devant un reverse proxy avec un certificat Let’s Encrypt. Le proxy en HTTPS est alors le seul composant exposé sur Internet. .env de Dify permet de modifier le port exposé. Configurez-le pour lier le service à 127.0.0.1, puis faites pointer le proxy vers cette adresse. Les principes de sécurisation d’un agent présentés dans exécuter un agent IA en toute sécurité sur un VPS s’appliquent également ici : gardez les composants sur loopback, n’exposez que ce qui doit être public et faites gérer TLS par un point d’entrée unique et correctement durci. Lorsqu’une interface vous est réservée et n’a jamais besoin d’un certificat, n’utilisez pas de proxy. Accédez-y par un tunnel SSH, comme dans auto-héberger le scanner de sécurité open-kritt, où le tableau de bord reste lié à loopback et est transféré vers votre ordinateur portable au lieu d’être publié. Si toute une équipe doit utiliser Dify, mais que le service ne doit pas être accessible depuis Internet, un réseau overlay permet d’étendre cette approche au-delà d’un seul ordinateur portable : annoncer le sous-réseau privé du serveur sur votre tailnet permet à chaque appareil autorisé d’atteindre le builder via une adresse privée, tandis que le pare-feu reste fermé à tout le trafic sauf SSH. Si vous administrez ce serveur avec un coding agent plutôt que manuellement, définissez le niveau d’autonomie autorisé avant de lui donner les clés, car le mode d’autorisation dans lequel vous laissez Claude Code détermine s’il s’arrête pour demander confirmation avant de réécrire .env ou de redémarrer la stack. Si une session suit les logs des conteneurs pendant qu’une autre modifie la configuration du proxy, ces deux sessions peuvent s’échanger du texte sur le même serveur, ce qui évite de copier la sortie entre les terminaux à chaque redémarrage de la stack.

Étape 4 : Maintenir le système à jour

Dify évolue rapidement et ses mises à jour incluent des correctifs de sécurité. Pour mettre à jour l’installation, effectuez un pull puis un redémarrage depuis le répertoire docker :

git pull
docker compose pull
docker compose up -d

Lisez les notes de version avant de passer à une version majeure, car Dify modifie parfois le schéma .env entre deux versions. Une nouvelle variable que vous n’avez pas définie peut empêcher un conteneur de démarrer.

Étape 5 : Sauvegardez ce que vous ne pouvez pas recréer

Deux éléments d’une instance Dify sont irremplaçables : la base de données Postgres, qui contient vos applications, vos utilisateurs et vos paramètres, ainsi que le volume qui stocke les documents importés et l’index vectoriel. Les deux se trouvent dans des Docker volumes sous le répertoire docker. Créez des snapshots selon une planification et copiez-les hors du serveur. Ces snapshots contiennent toutes les clés de modèles et tous les documents importés dans un seul fichier. Chiffrez-les donc avant de les transférer hors du serveur, pour la même raison que une sauvegarde de Vaultwarden devient le point faible d’un serveur de mots de passe par ailleurs robuste. Une clé d’API de modèle peut être renouvelée ; l’application que vous avez passé une semaine à construire ne peut pas l’être. Le même raisonnement s’applique à tout agent dont l’état doit survivre à la machine qui l’exécute : maintenir KiroCrew en fonctionnement dans un conteneur permanent revient à sauvegarder la mémoire et les planifications qui disparaîtraient au prochain redémarrage.

Lorsque vous voulez que les agents construits ici dépassent vos propres jeux de données et recherchent sur le Web en temps réel, les connecter à une instance SearXNG auto-hébergée maintient le flux de requêtes sur du matériel que vous contrôlez. Il est toutefois recommandé de vous renseigner sur la surface d’attaque liée à l’injection de prompts avant de l’activer. Pour un agent plus autonome capable d’exécuter du code, consultez l’auto-hébergement d’Agent Zero. La page construire votre propre agent IA sur un VPS présente les bases communes à tous ces agents.

FAQ

Quelle est la configuration requise pour auto-héberger Dify ?

Dify fonctionne sous la forme d’une stack Docker Compose d’environ six conteneurs. Prévoyez donc un VPS avec au moins 2 GB de RAM disponibles, idéalement 4 GB, ainsi que quelques cœurs CPU et suffisamment d’espace disque pour vos documents importés et l’index vectoriel. La pression sur la mémoire vient de la base de données et du vector store, pas de Dify lui-même.

Est-il sûr d’exposer directement Dify sur le port 80 ?

Non. Le serveur web fourni avec Dify écoute en HTTP non chiffré et protège votre connexion d’administration ainsi que vos clés d’API de modèles. Placez un reverse proxy avec un certificat Let’s Encrypt devant Dify, liez le port de Dify à la loopback et laissez uniquement le proxy HTTPS être exposé sur Internet. Ajoutez un pare-feu en refus par défaut qui couvre IPv4 et IPv6.

Comment mettre à jour une instance Dify auto-hébergée ?

Depuis le répertoire docker, exécutez git pull, puis docker compose pull et docker compose up -d pour récupérer les nouvelles images et redémarrer les conteneurs. Lisez d’abord les notes de version, car Dify ajoute parfois de nouvelles variables .env entre les versions. Une variable manquante peut empêcher un conteneur de démarrer.

Quelle est la première chose à faire après l’installation de Dify ?

Accédez à /install et créez immédiatement le compte d’administration. Tant que ce compte n’existe pas, toute personne pouvant atteindre la page peut le récupérer. Configurez-le dès que les conteneurs sont opérationnels, avant d’ouvrir le pare-feu à Internet.