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 qui permet de créer des applications reposant 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 d’API des modèles. C’est le type d’outil qu’une petite équipe déploie afin que tout le monde s’appuie sur une même base privée, plutôt que de disperser les clés d’API dans des scripts. Si des notions comme agent, tool call et pipeline de retrieval restent floues, commencer par revoir ces concepts depuis le début vous aidera à comprendre les écrans de l’interface de Dify comme des contrôles familiers plutôt que comme un ensemble d’interrupteurs sans libellé.

L’exécuter vous-même implique de gérer de nombreux composants. En octobre 2026, la stack par défaut documentée par Dify démarre 15 conteneurs persistants, ainsi qu’une tâche exécutée une seule fois qui configure les permissions des fichiers avant de s’arrêter. Sept services appartiennent à Dify : le serveur d’API, un serveur websocket, un worker d’arrière-plan, un scheduler, le frontend web, un plugin daemon et un backend d’agent. Les huit autres sont des dépendances : une base de données Postgres, un cache Redis, une base de données vectorielle Weaviate, un point d’entrée nginx, deux code sandboxes et deux proxies SSRF. Docker Compose relie tous ces composants, mais il s’agit bien d’une stack complète, et le minimum documenté par Dify est de 4 GiB de RAM et deux cœurs CPU. Si ce VPS doit également exécuter d’autres services, dimensionnez-le à partir de mesures réelles plutôt qu’à partir des valeurs annoncées, car les besoins réels en RAM de PhotoPrism et 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 des ressources nécessaires. La contention CPU se manifeste de la même manière : une bibliothèque Jellyfin présentée comme un vidéoclub des années 90 consomme presque rien tant qu’elle sert uniquement à parcourir les jaquettes, mais dès qu’un utilisateur lance un transcodage, les workers de Dify passent derrière lui dans la file d’attente. Le point positif 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 prévisible que OpenBot, où chaque collègue IA dispose de son propre conteneur et de son propre navigateur, et où chaque nouvelle recrue augmente encore le besoin minimal en mémoire.

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

Prérequis

Vous avez besoin d’un VPS sous Ubuntu 24.04 avec au moins 4 GiB de RAM et deux cœurs CPU, de Docker avec le plugin Docker Compose installé (Dify nécessite Compose 2.24.0 ou une version ultérieure), ainsi que d’un utilisateur disposant de sudo ou membre du groupe docker. La commande de clonage ci-dessous utilise également git, curl et jq. 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 la dernière release, et non la branche de développement, puis placez-vous dans le répertoire docker :

git clone --branch "$(curl -s https://api.github.com/repos/langgenius/dify/releases/latest | jq -r .tag_name)" https://github.com/langgenius/dify.git
cd dify/docker
cp .env.example .env

Si le clone échoue avec l’erreur « Remote branch null », l’appel à l’API GitHub n’a renvoyé aucun résultat. Choisissez une version dans la page des releases et transmettez-la manuellement à --branch.

Le fichier .env contient la configuration principale. 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. SECRET_KEY est vide dans la configuration fournie. Si vous le laissez ainsi, Dify génère une clé et la conserve dans son répertoire de stockage. Les mots de passe sont un autre problème : le fichier d’exemple utilise la même difyai123456 pour Postgres et Redis, ainsi que des clés fixes et connues publiquement pour le code sandbox, le plugin daemon et Weaviate. Conserver ces valeurs par défaut est la cause la plus fréquente de compromission d’une instance Dify auto-hébergée. Si vous préférez définir votre propre clé secrète, générez-en une :

openssl rand -base64 42

Collez cette valeur dans SECRET_KEY et définissez une valeur forte et unique pour chaque champ de mot de passe et de clé du fichier. Le mot de passe Redis apparaît également dans CELERY_BROKER_URL. Modifiez-le aussi à cet endroit, sinon le worker ne pourra pas joindre Redis.

É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 que les conteneurs sont opérationnels :

docker compose ps

Chaque service qui s’exécute en continu doit afficher running. La tâche de permissions ponctuelle s’arrête une fois son travail terminé. Par défaut, Dify fournit 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 propre nginx de Dify écoute sur le port 80, sans chiffrement, sur toutes les interfaces, et publie également le port 443. 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 couvre que l’IPv4 peut laisser ces mêmes ports ouverts en IPv6. C’est la faille du pare-feu IPv6 qui piège tant d’utilisateurs de serveurs auto-hébergés. Vérifiez que les deux piles réseau sont filtrées. Sachez également que les ports publiés par Docker sont gérés par les propres règles de pare-feu de Docker, et non par celles d’ufw. La configuration par défaut publie le port de débogage du daemon de plugins, 5003, sur toutes les interfaces. Définissez EXPOSE_PLUGIN_DEBUGGING_PORT dans .env sur 127.0.0.1:5003, sauf si vous devez réellement déboguer les plugins depuis une autre machine.

Pour TLS, la solution la plus propre consiste à lier le port web de Dify à loopback et à placer devant un reverse proxy avec un certificat Let’s Encrypt. Ainsi, le proxy HTTPS est le seul élément exposé sur Internet. Le paramètre .env de Dify permet de modifier le port exposé. Configurez-le pour qu’il se lie à 127.0.0.1, puis faites pointer votre proxy vers cette adresse. Faites de même pour EXPOSE_NGINX_SSL_PORT, car le nginx de Dify réserve par défaut le port 443 de l’hôte et votre proxy en a besoin. 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 l’être et utilisez une seule porte d’entrée renforcée pour TLS. Lorsqu’une interface est uniquement destinée à votre usage et n’a pas besoin de certificat, ignorez le proxy et utilisez-la via un tunnel SSH, comme dans auto-héberger le scanner de sécurité open-kritt, qui lie son dashboard à loopback et le transfère vers votre ordinateur portable au lieu de le publier. Si toute une équipe doit utiliser Dify sans que le service soit exposé sur 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 sauf SSH. Si vous administrez ce serveur avec un agent de programmation plutôt que manuellement, définissez le niveau d’autonomie que vous lui accordez 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 : Maintenez-le à jour

Dify évolue rapidement et les mises à jour incluent des correctifs de sécurité. Comme vous avez cloné un tag de release, la mise à jour consiste à sélectionner le tag suivant plutôt qu’à tirer une branche. Sauvegardez d’abord la base de données, puis, depuis le répertoire docker :

docker compose down
git fetch --tags
git checkout NEW_VERSION
docker compose pull
docker compose up -d

Les migrations de base de données s’exécutent automatiquement au démarrage. Certaines ne peuvent pas être annulées, d’où l’importance de commencer par la sauvegarde. Lisez les notes de version avant chaque mise à niveau, et pas uniquement avant les mises à niveau majeures : Dify indique que les étapes de mise à niveau varient selon les releases. Par exemple, les notes de version de la 1.17.1 (septembre 2026) demandent aux utilisateurs du Weaviate inclus avec des données existantes de ne pas passer directement à cette version, mais de suivre chaque release mineure. Dify modifie également le schéma .env entre les releases. Après avoir sélectionné un nouveau tag, comparez donc .env.example avec votre .env et reportez vos modifications, car 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 système requise pour auto-héberger Dify ?

Dify indique un minimum de 4 GiB de RAM et de deux cœurs CPU, ainsi que Docker Compose 2.24.0 ou version ultérieure. Cette configuration minimale correspond à la taille de la stack par défaut : 15 conteneurs persistants et une tâche d’initialisation exécutée une seule fois, en octobre 2026. Prévoyez suffisamment d’espace disque pour vos documents importés et l’index vectoriel, ainsi que davantage de mémoire si d’autres services utilisent le serveur.

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 interface 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 n’exposez sur Internet que le proxy HTTPS. Associez cette configuration à un firewall en refus par défaut couvrant IPv4 et IPv6.

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

Sauvegardez la base de données, puis exécutez depuis le répertoire docker les commandes docker compose down, git fetch --tags, git checkout, le nouveau tag de release, docker compose pull et docker compose up -d. Lisez d’abord les notes de release, car les étapes de mise à niveau varient selon les releases, les migrations peuvent être irréversibles et Dify ajoute parfois de nouvelles variables .env. Si l’une d’elles manque, un conteneur peut ne pas 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 administrateur. Tant que ce compte n’existe pas, toute personne pouvant atteindre la page peut le créer à votre place. Configurez-le dès que les conteneurs sont en état de fonctionner et avant d’ouvrir le firewall à Internet.