~/ / Articles sur l'IA / LLM locaux sur un VPS / Connecter Dify à Ollama sur votre propre VPS

Connecter Dify à Ollama sur votre propre VPS

Dify est une plateforme pour créer des applications d'IA que vous pouvez faire tourner sur votre propre serveur. Ollama fait tourner le modèle. Cet article relie les deux sur un seul VPS : quelle taille de serveur il faut, comment démarrer Dify, quels champs le plugin Ollama demande, et pourquoi l'adresse qui fonctionne sur un portable peut échouer dans Docker. Il indique aussi où s'arrête la documentation, pour que vous sachiez quelles parties tester vous-même.

Publié: 2026-10-27 · 7 min de lecture · Faits vérifiés dans la documentation et les dépôts officiels le 2026-10-27. Dify évolue vite : lisez les notes de version de la version que vous installez.

Ce qu'il faut avant de commencer

Le guide d'auto-hébergement de Dify donne le minimum pour Dify lui-même. Le modèle a besoin de sa propre mémoire en plus, il faut donc additionner les deux chiffres. L'estimateur ci-dessous donne un chiffre pour le modèle. L'ajouter au minimum de Dify est notre règle empirique, et non une affirmation de la documentation de Dify.

Élément	Ce que dit le guide de Dify
CPU	CPU >= 2 Core
Mémoire	RAM >= 4 GiB
Docker Compose	Dify nécessite Docker Compose 2.24.0 ou une version ultérieure.
Git, curl, jq	La commande de clonage ci-dessous utilise git, curl et jq.

Essayer: Local LLM Memory Estimator

Modèle

Tag Ollama qwen3:8b, quantification Q4_K_M, taille de téléchargement 5.2 GB.

Taille du fichier (GB)CouchesKV headsDimension des têtes

Longueur du contexte (jetons)Requêtes parallèlesType de KV cacheRéserve pour l'OS et les autres services (GiB)Mémoire de l'offre (GiB, facultatif)

Estimation

Poids du modèle: 4.84 GiB
KV cache: 0.56 GiB
Réserve: 1.00 GiB
Total: 6.41 GiB (6.88 GB)
Plus petite taille de mémoire courante qui le contient: 8 GiB

Il s'agit d'une estimation. Elle n'inclut pas les tampons de calcul du runtime et suppose que chaque couche a la même forme de KV. Mesurez une vraie exécution avant de choisir une offre.

Données du modèle vérifiées le 2026-10-26.

Sources : Ollama library · Configuration du modèle (config.json) · Ollama FAQ

Tout s'exécute dans votre navigateur. Rien n'est envoyé.

Étape 1 : démarrer Dify avec Docker Compose

Ce sont les commandes du guide d'auto-hébergement de Dify. La première télécharge depuis GitHub le tag de la dernière version publiée, de sorte que vous partez d'une version publiée et non d'une branche inachevée. Au moment de notre vérification, la dernière version était la 1.18.0 (publiée le 2026-10-23).

Étape	Commande
Cloner la dernière version	git clone --branch "$(curl -s https://api.github.com/repos/langgenius/dify/releases/latest \| jq -r .tag_name)" https://github.com/langgenius/dify.git
Aller dans le dossier Docker	cd dify/docker
Copier le fichier de réglages	cp .env.example .env
Créer un token pour le backend d'agent	openssl rand -base64 32
Démarrer Dify	docker compose up -d

Avant de démarrer, placez dans .env, sous le nom DIFY_AGENT_LOCAL_SANDBOX_AUTH_TOKEN, le token qu'openssl affiche. Le guide indique que le backend d'agent et son sandbox ne démarrent pas sans lui.

Étape 2 : créer le compte administrateur

Une fois les conteneurs démarrés, le guide dit d'ouvrir d'abord la page d'initialisation de l'administrateur : http://your_server_ip/install sur un serveur, ou http://localhost/install sur votre propre ordinateur. Créez le compte à cet endroit, puis connectez-vous sur http://your_server_ip.

La documentation ne dit pas qui peut accéder à cette page avant que le compte n'existe. Notre recommandation, qui n'est pas une affirmation de la documentation : créez le compte juste après le démarrage, et lisez l'article sur la protection d'un serveur avant de laisser Dify ouvert sur Internet.

Étape 3 : ajouter le plugin Ollama et le modèle

Dans la documentation actuelle de Dify, les fournisseurs de modèles s'installent depuis Integrations > Model Provider ou depuis Marketplace, puis on clique sur Setup sur la carte du fournisseur. Les noms de menus changent d'une version à l'autre : cherchez la liste des fournisseurs dans votre version. La page Marketplace du plugin Ollama (version 1.0.3 au moment de notre vérification) dit d'installer Ollama, de lancer un modèle et de vérifier que son API locale fonctionne avant de l'ajouter à Dify.

Voici les champs du plugin, tirés de son README et de sa page Marketplace.

Champ	Quoi saisir
Model Name	Le modèle Ollama, par exemple gemma3, qwen3, deepseek-r1 ou gpt-oss.
Base URL	La racine de l'hôte Ollama, http://<your-ollama-host>:11434 pour un Ollama local. N'incluez pas /api, car le plugin ajoute lui-même /api/chat, /api/generate et /api/embed.
API Key	Facultative pour un Ollama local. Obligatoire seulement pour Ollama cloud.
Model Type	Chat pour le chat, l'appel d'outils et la vision. La page Marketplace mentionne aussi les embeddings de texte et le rerank.
Model Context Length	À faire correspondre à la fenêtre de contexte du modèle.
Upper bound for max tokens	La plus grande valeur de max tokens (num_predict) que Dify autorise.
Vision support / Function call support	Choisissez Yes seulement pour un modèle qui le prend en charge.
Attach Dify app_id as request headers	Désactivé par défaut. Une fois activé, Dify ajoute les en-têtes X-Dify-App-Id et X-Dify-Source à ses appels vers Ollama. Ollama ne les utilise pas.

Pour savoir quels modèles prennent en charge la vision et l'appel d'outils, voyez l'article sur ce que savent faire les modèles de la bibliothèque Ollama.

Étape 4 : l'adresse qui fonctionne depuis l'intérieur de Docker

Dify tourne dans des conteneurs, et Ollama tourne sur le serveur lui-même. Dans un conteneur, localhost désigne le conteneur, pas le serveur. Le README du plugin dit : utilisez une adresse d'hôte que le conteneur Dify peut atteindre, comme http://host.docker.internal:11434 ou une adresse IP du LAN.

La documentation de Docker explique ce nom. L'option --add-host accepte une valeur spéciale, host-gateway, qui se résout en l'adresse IP interne de l'hôte, et il est d'usage d'employer host.docker.internal pour ce nom. Elle précise aussi que Docker Desktop résout ce nom automatiquement. L'exemple de la documentation est --add-host host.docker.internal=host-gateway.

Ce que nous avons vérifié	Résultat
Le docker-compose.yaml de Dify définit-il host.docker.internal ?	Non. Nous n'avons trouvé ni host.docker.internal ni entrée extra_hosts dans le fichier de la branche main.
La référence de Docker Compose décrit-elle extra_hosts ?	Oui, comme des correspondances de noms d'hôte de la forme HOSTNAME=IP qui vont dans /etc/hosts. La page que nous avons lue ne mentionne pas host-gateway pour extra_hosts.
Ollama écoute-t-il sur d'autres adresses que 127.0.0.1 ?	Pas par défaut. La FAQ d'Ollama dit qu'il se lie à 127.0.0.1 sur le port 11434, et que la variable d'environnement OLLAMA_HOST change l'adresse de liaison.

Notre lecture, qui n'est pas une affirmation de la documentation : sur un serveur Linux, vous ajoutez vous-même le nom d'hôte, ou vous utilisez l'adresse du serveur, et vous devrez peut-être aussi changer l'adresse sur laquelle Ollama écoute. Nous n'avons pas testé cette combinaison. Si vous changez OLLAMA_HOST, le port 11434 devient accessible depuis d'autres machines, et Ollama n'a pas de mot de passe propre : fermez donc ce port vers l'extérieur dans le pare-feu. Les articles sur l'installation d'Ollama et sur la mise en place de nginx devant lui décrivent les réglages.

Étape 5 : les embeddings, et ce que le plugin ne fait pas

La page Marketplace du plugin dit qu'il prend en charge le streaming, le raisonnement (thinking), la vision, l'appel d'outils et les embeddings de texte, et que les vecteurs d'embedding sont L2-normalized. Pour les embeddings, vous ajoutez un second modèle de type embeddings de texte, avec un modèle d'embedding de la bibliothèque Ollama.

Elle liste aussi ce qui n'est pas inclus. Ollama n'a pas de point d'accès rerank natif : un modèle de rerank demande donc un service de rerank compatible OpenAI. La recherche web n'est pas fournie non plus. Elle demande un plugin d'outil Dify distinct ou un workflow externe.

Si la connexion échoue

Lancez ollama ps pour vérifier que le modèle est chargé, et ouvrez http://127.0.0.1:11434 sur le serveur pour voir qu'Ollama répond.
Vérifiez la Base URL. C'est la racine de l'hôte, avec le port et sans /api.
Vérifiez que les conteneurs Dify peuvent atteindre l'adresse. La documentation de Dify dit que ses requêtes sortantes passent par un proxy qui bloque les plages d'adresses IP internes et privées. La page nomme les nœuds HTTP et les téléchargements d'images, et elle ne dit pas si les requêtes des fournisseurs de modèles suivent le même chemin. Si vous utilisez une adresse privée et qu'elle est refusée, c'est un endroit où regarder.
Lisez les journaux des conteneurs avec docker compose logs. Nous n'avons pas trouvé de liste de messages d'erreur dans la documentation.

Garder Dify à jour

Le guide dit que les étapes de mise à niveau varient d'une version à l'autre : suivez donc le guide de mise à niveau de la version vers laquelle vous passez, qui se trouve sur la page Releases de Dify. Après une mise à niveau, comparez .env.example avec votre .env pour repérer les variables nouvelles ou modifiées. Si vous avez modifié docker-compose.yaml, appliquez de nouveau vos changements au fichier de la nouvelle version, car une version peut ajouter des services indispensables.