Pourquoi héberger Dify sur un VPS ?
Utiliser la version cloud de Dify implique de confier vos prompts, vos données métier et vos clés API à un serveur tiers, avec des limitations sur le nombre d'applications et les modèles accessibles. En auto-hébergeant Dify sur un VPS, vous éliminez ces contraintes : aucun abonnement mensuel lié à l'usage, aucune donnée sensible transmise à l'extérieur, et la liberté de connecter n'importe quel fournisseur de modèles (OpenAI, Anthropic, Ollama en local, etc.). C'est la solution idéale pour les équipes qui souhaitent construire des pipelines IA robustes dans un environnement sous leur contrôle total.
Ce que vous pouvez faire avec Dify
- Créer des chatbots et agents IA personnalisés connectés à vos propres sources de données (RAG)
- Orchestrer des workflows multi-étapes combinant plusieurs modèles de langage et outils externes
- Brancher Dify sur OpenAI, Anthropic Claude, Mistral, ou un modèle local via Ollama
- Exposer vos applications IA via une API REST ou un widget intégrable dans votre site
- Gérer les accès de votre équipe avec un système de rôles et d'espaces de travail
- Suivre les logs d'utilisation, les coûts par modèle et les performances de vos pipelines
Prérequis : bien dimensionner votre VPS
Dify fait tourner une flotte de services Docker en parallèle : un serveur API, un worker Celery pour les embeddings et les tâches asynchrones, le frontend web, PostgreSQL, Redis, Weaviate (base vectorielle pour la RAG), un sandbox d'exécution de code et un proxy interne.
Minimum absolu : 2 vCPU · 4 Go de RAM · 40 Go de stockage SSD. Avec ces specs, Dify démarre et permet de tester les fonctions de base.
Usage réel recommandé : 4 vCPU · 8 Go de RAM · 80 Go de stockage. Dès que vous indexez des documents volumineux ou que plusieurs utilisateurs requêtent simultanément, la génération d'embeddings et la base vectorielle saturent les 4 Go. L'offre VPS-4 ServOrbit convient à un usage équipe sans modèle local.
Avec un modèle local (Ollama) : ajoutez les besoins du modèle. Un modèle Llama 3 8B quantisé (Q4) requiert ~6 Go de VRAM ou de RAM dédiée. Comptez 16 Go de RAM au minimum sur le VPS pour faire cohabiter Dify et Ollama sans swap.
Le système d'exploitation recommandé est Ubuntu 22.04 LTS avec Docker 24+ et Docker Compose v2 installés.
Installer Dify sur votre VPS ServOrbit
Commander un VPS Cloud ServOrbit
Rendez-vous sur la page /vps-cloud et choisissez une offre adaptée à votre usage (minimum 2 vCPU / 4 Go RAM, recommandé 4 vCPU / 8 Go). Sélectionnez Ubuntu 22.04 LTS comme système d'exploitation, puis finalisez la commande. Votre VPS est provisionné en moins d'une minute.
Cloner le dépôt et copier la configuration
Connectez-vous en SSH à votre VPS, puis exécutez :
git clone https://github.com/langgenius/dify.git
cd dify/docker
cp .env.example .envLe fichier .env concentre toutes les variables de configuration (clés secrètes, URLs, variables de comportement). Ouvrez-le et changez au minimum SECRET_KEY et POSTGRES_PASSWORD avant de lancer les conteneurs.
Démarrer la stack Docker Compose
Depuis le dossier dify/docker, lancez :
docker compose up -dDocker télécharge les images et démarre les conteneurs : dify-api, dify-worker, dify-web, db (PostgreSQL), redis, weaviate, sandbox, ssrf_proxy et nginx. Vérifiez que tout est Up avec docker compose ps. L'opération dure généralement 3 à 5 minutes selon la bande passante.
Créer le compte administrateur
Ouvrez l'URL http://[IP-de-votre-VPS] dans votre navigateur. Dify redirige automatiquement vers /install lors du premier accès.
⚠️ Faites-le immédiatement : tant que le compte admin n'existe pas, la page /install est accessible à n'importe qui — le premier arrivé devient propriétaire de votre instance.
Saisissez votre adresse e-mail et un mot de passe fort. Ce compte est le propriétaire de l'espace de travail par défaut.
Pointer un nom de domaine et activer HTTPS
Pour une utilisation en production, associez un nom de domaine à l'IP de votre VPS et déployez un certificat TLS. Le docker-compose.yaml de Dify inclut un nginx interne qui écoute sur le port 80. La configuration la plus directe consiste à installer Certbot sur l'hôte et à créer un vhost nginx externe qui proxifie vers localhost:80 :
sudo apt install nginx certbot python3-certbot-nginx -y
sudo certbot --nginx -d votre-domaine.comMettez ensuite à jour les variables CONSOLE_API_URL, CONSOLE_WEB_URL, SERVICE_API_URL et APP_WEB_URL dans le fichier .env avec https://votre-domaine.com, puis redémarrez les conteneurs avec docker compose up -d.
Configuration post-installation : modèles, API et espace de travail
Une fois connecté, la première étape est de déclarer un fournisseur de modèles. Dans les paramètres (icône en haut à droite) → Fournisseurs de modèles, ajoutez votre clé API OpenAI, Anthropic, Mistral ou tout autre fournisseur supporté. Pour un modèle local, entrez l'URL de votre instance Ollama (http://[IP-hôte]:11434).
Dify expose aussi sa propre API REST pour intégrer vos applications dans des pipelines externes. Vous trouverez les clés d'API dans Paramètres → Clés d'API. Ces clés permettent d'interroger vos applications Dify depuis n8n, Zapier ou tout script Python sans passer par l'interface graphique.
L'espace de travail par défaut est celui créé lors de la première connexion. Vous pouvez inviter des membres via Paramètres → Membres et leur attribuer les rôles Admin, Normal ou Dataset operator.
Plugins offline : contourner l'erreur 500/404 sur les instances self-hosted
Depuis novembre 2025 (issue GitHub #27720), de nombreux utilisateurs self-hosted constatent que l'installation de plugins depuis le marketplace Dify retourne une erreur HTTP 500 ou 404 sur l'endpoint /api/v1/plugins/download/. Les mêmes plugins s'installent sans problème sur Dify Cloud, mais les instances auto-hébergées ne parviennent pas à joindre le backend de distribution.
Contournement 1 — Fichier .difypkg local. La méthode la plus fiable consiste à télécharger manuellement le fichier .difypkg du plugin depuis le marketplace Dify, puis à l'installer via l'option « Installer depuis un fichier local » dans l'interface Dify. Cette méthode fonctionne indépendamment de la connectivité à l'endpoint de téléchargement.
Contournement 2 — Désactiver la vérification de signature. Si vous souhaitez installer des plugins non signés ou développer vos propres plugins, ajoutez la variable suivante dans votre fichier .env :
FORCE_VERIFYING_SIGNATURE=falsePuis redémarrez le service plugin_daemon :
docker compose restart plugin_daemon⚠️ Attention : désactiver la vérification de signature supprime un garde de sécurité. Réservez ce réglage aux environnements de développement ou aux plugins dont vous maîtrisez la source. Pour un usage en production avec des utilisateurs tiers, préférez l'installation par fichier .difypkg vérifié.
Maillage avec Ollama et n8n
Dify devient particulièrement puissant en combinaison avec d'autres outils self-hosted.
Ollama vous permet de faire tourner un LLM directement sur votre VPS ou sur un serveur du même réseau, sans dépendre d'une API externe. Après avoir déployé Ollama, déclarez-le dans Dify comme fournisseur de modèles avec l'URL http://[IP-Ollama]:11434. Toute la génération reste alors sur votre infrastructure — zéro fuite de prompt vers l'extérieur.
n8n est un orchestrateur de workflows qui peut piloter Dify via son API REST. Créez un nœud HTTP Request dans n8n pointant vers https://votre-domaine.com/v1/chat-messages avec votre clé d'API Dify en header Authorization. Vous pouvez ainsi déclencher une conversation Dify depuis un formulaire web, un e-mail entrant ou un webhook Slack, et renvoyer la réponse IA vers n'importe quelle destination.
Dépannage : les erreurs les plus fréquentes
Conteneur worker qui redémarre en boucle. Le worker Celery dépend de Redis et de PostgreSQL. Vérifiez leur statut avec docker compose ps db redis et consultez les logs : docker compose logs worker --tail=50. Si Redis n'est pas encore prêt au démarrage, un simple docker compose restart worker suffit.
plugin_daemon : erreur de connexion à PostgreSQL. Après une mise à jour de Dify, le plugin_daemon peut échouer avec failed to connect to host=db. Vérifiez que le conteneur db est healthy (docker compose ps db). Si le problème persiste, attendez 30 secondes après le démarrage complet avant de redémarrer : docker compose restart plugin_daemon.
Weaviate ne démarre pas (vm.max_map_count). Weaviate requiert un paramètre noyau Linux élevé. Si le conteneur sort immédiatement, appliquez : sudo sysctl -w vm.max_map_count=262144. Pour le rendre permanent, ajoutez vm.max_map_count=262144 dans /etc/sysctl.conf.
Plugins marketplace : erreur 500/404. Voir la section « Plugins offline » ci-dessus. Si le problème vient d'un blocage réseau entre les conteneurs Docker et marketplace.dify.ai, vérifiez que le port 443 sortant n'est pas bloqué par votre pare-feu : docker compose exec api curl -I https://marketplace.dify.ai.
WebSocket déconnecté derrière un reverse proxy. Si le streaming des réponses IA s'interrompt, votre proxy nginx externe ne transmet pas les en-têtes WebSocket. Ajoutez dans votre bloc location / : proxy_set_header Upgrade $http_upgrade; et proxy_set_header Connection "upgrade";.
Activez les sauvegardes automatiques ServOrbit pour protéger le volume PostgreSQL de Dify (vos applications, prompts et historiques de conversations). Une snapshot quotidienne du disque couvre l'ensemble des volumes Docker, dont dify_db et dify_weaviate. En cas de mise à jour ratée, un rollback se fait en quelques minutes depuis l'espace client.
La documentation officielle
Pour la configuration avancée, les variables d'environnement complètes et les notes de version, consultez la documentation officielle de Dify. Le fichier docker-compose.yaml du dépôt officiel reste la source de vérité pour les versions des images et les dépendances inter-services.