Héberger LangFlow sur un VPS : guide complet Docker et HTTPS

LangFlow répond à un cas d'usage précis : concevoir des pipelines IA en glissant-déposant des composants — modèles LLM, retrievers, prompts, mémoire, agents — puis les tester sans écrire une seule ligne de code. C'est l'alternative visuelle à LangChain en mode code-only, adaptée aux équipes qui veulent itérer vite avant de figer une logique en Python.

Sur un VPS, vous obtenez une instance stable et persistante, accessible à toute l'équipe, contrairement à un setup local qui disparaît au redémarrage. Vos flows encodent souvent une logique métier sensible — chaînes de prompts, clés API, connecteurs vers vos bases de données. Ces données ne doivent pas transiter par un SaaS dont vous ne contrôlez pas la politique de rétention.

LangFlow s'appuie sur FastAPI côté serveur et expose chaque flow comme un endpoint REST : vos applications peuvent appeler vos pipelines IA directement, sans code intermédiaire. C'est cette combinaison — interface visuelle pour la conception, API pour l'intégration — qui en fait un outil de prototypage sérieux pour des cas tels que le RAG documentaire, les chatbots d'assistance, les agents multi-étapes ou les pipelines de classification.

LangFlow est plus gourmand en mémoire qu'un outil web classique : son moteur d'exécution charge des modèles et des embeddings en RAM. Prévoyez au minimum 2 vCPU et 4 Go de RAM pour un usage confortable. Si vous connectez un modèle Ollama local pour l'inférence sur le même VPS, passez à 8 Go minimum.

Côté logiciel, il vous faut Docker (version 24 ou supérieure) et Docker Compose v2, installés et opérationnels. Le port 7860 doit être accessible en local (LangFlow écoute sur ce port par défaut). Vous n'exposez pas ce port directement sur Internet : le reverse proxy nginx s'en charge.

Préparez un sous-domaine pointant vers l'IP de votre VPS — par exemple langflow.votre-domaine.com — avec les enregistrements DNS déjà propagés avant de lancer certbot. Enfin, la base PostgreSQL est fortement recommandée pour la production : SQLite, la valeur par défaut, se corrompt sous charge concurrente et ne supporte pas les accès simultanés de plusieurs utilisateurs.

Chaque flow LangFlow est accessible via l'endpoint /api/v1/run/<flow-id>. Vous trouvez l'identifiant du flow dans l'URL de l'éditeur ou dans le menu API du flow. Deux exemples concrets.

Avec curl :

curl -s -X POST \
  https://langflow.votre-domaine.com/api/v1/run/VOTRE-FLOW-ID \
  -H "Content-Type: application/json" \
  -H "x-api-key: VOTRE-CLE-API" \
  -d '{
    "input_value": "Quelle est la capitale de la France ?",
    "input_type": "chat",
    "output_type": "chat"
  }'

Avec Python (bibliothèque requests) :

import requests

FLOW_ID = "VOTRE-FLOW-ID"
BASE_URL = "https://langflow.votre-domaine.com"
API_KEY = "VOTRE-CLE-API"

response = requests.post(
    f"{BASE_URL}/api/v1/run/{FLOW_ID}",
    headers={
        "Content-Type": "application/json",
        "x-api-key": API_KEY,
    },
    json={
        "input_value": "Quelle est la capitale de la France ?",
        "input_type": "chat",
        "output_type": "chat",
    },
    timeout=60,
)

result = response.json()
print(result["outputs"][0]["outputs"][0]["results"]["message"]["text"])

La clé API se génère dans Settings → API Keys de l'interface LangFlow. Elle authentifie chaque appel et peut être révoquée à tout moment sans toucher au flow. Pour des appels depuis un service Node.js, la structure est identique avec fetch ou axios — l'endpoint REST est agnostique au langage.

Le RAG (Retrieval-Augmented Generation) est le cas d'usage central de LangFlow : vous chargez des documents (PDF, texte, Markdown), les découpez en chunks, les embedez dans une base vectorielle, puis un LLM répond aux questions en puisant dans ce contexte.

Quel VectorStore sur un VPS ? Sur un serveur à ressources limitées, Chroma (ChromaDB) est le choix le plus léger : il tourne en-process dans le même conteneur LangFlow, ne demande aucun service supplémentaire, et persiste ses données dans un répertoire local. Qdrant convient si vous avez plus de RAM et souhaitez un service dédié en conteneur voisin.

Construire le pipeline d'indexation dans LangFlow :

Dans l'éditeur, assemblez la chaîne suivante en glissant les composants :

1. File (ou Directory) → charge le PDF ou le dossier de documents.
2. Split Text → découpe en chunks (taille recommandée : 500 à 800 tokens, chevauchement 50).
3. OpenAI Embeddings (ou Ollama Embeddings pour rester entièrement local) → transforme chaque chunk en vecteur.
4. Chroma DB → stocke les vecteurs. Pointez le champ Persist Directory vers un volume monté dans Docker pour que l'index survive aux redémarrages.

Pour le volume Chroma, ajoutez dans votre docker-compose.yml :

  langflow:
    volumes:
      - chromadb:/data/chroma

volumes:
  pgdata:
  chromadb:

Et définissez dans LangFlow la variable globale CHROMA_PERSIST_DIR avec la valeur /data/chroma.

Pipeline de requête :

Une fois l'index peuplé, créez un second flow (ou une branche du même) : Text Input → Chroma DB (en mode recherche, avec le même répertoire) → Prompt (injectez les chunks retrouvés) → LLM → Chat Output. Chaque question déclenche une recherche vectorielle, récupère les passages les plus proches et les soumet au modèle avec le contexte.

LangFlow permet de créer des composants Python sur mesure, sans forker le projet. Un composant est une classe qui hérite de Component et déclare ses entrées, ses sorties et son code.

Exemple minimal — un composant qui nettoie et met en majuscules le texte reçu :

from langflow.custom import Component
from langflow.io import MessageTextInput, Output
from langflow.schema import Data

class UpperCaseComponent(Component):
    display_name = "Uppercase Text"
    description = "Convertit le texte en majuscules."

    inputs = [
        MessageTextInput(
            name="input_text",
            display_name="Texte d'entrée",
        )
    ]

    outputs = [
        Output(
            display_name="Texte traité",
            name="output_text",
            method="process_text",
        )
    ]

    def process_text(self) -> Data:
        result = self.input_text.strip().upper()
        return Data(text=result)

Pour ajouter ce composant à votre instance : dans l'interface LangFlow, allez dans Settings → Custom Components, collez le code et sauvegardez. Le composant apparaît immédiatement dans la barre latérale, prêt à être glissé dans un flow. Vous pouvez ainsi encapsuler n'importe quelle logique métier — appel à une API interne, transformation de données, accès à une base propriétaire — et l'exposer comme un bloc réutilisable dans tous vos flows.

LangFlow publie régulièrement de nouvelles versions (la branche 1.x est la branche stable active en octobre 2026). Avant toute mise à jour, faites systématiquement une sauvegarde de la base :

docker exec langflow-postgres-1 pg_dump -U langflow langflow \
  > /opt/backups/langflow-avant-maj-$(date +%F).sql

Mettez ensuite à jour l'image et relancez la stack :

cd /opt/langflow
docker compose pull
docker compose up -d

Suivez les logs pour détecter d'éventuelles migrations de schéma automatiques :

docker compose logs -f langflow

Points de vigilance sur les montées de version v1.x. Les versions 1.x peuvent inclure des migrations de base (le conteneur les applique au démarrage). Si un flow cesse de fonctionner après la mise à jour, consultez le CHANGELOG sur GitHub (langflow-ai/langflow) pour identifier les breaking changes : certains composants sont renommés ou refactorisés entre mineures. Exportez vos flows en JSON avant la montée de version — c'est le moyen le plus rapide de les restaurer dans un état connu si une migration pose problème.

Si vous épinglez une version précise (préférable en production), remplacez latest par le tag voulu dans votre docker-compose.yml :

image: langflowai/langflow:1.12.4

LangFlow expose plusieurs variables d'environnement pour adapter l'instance à votre contexte. LANGFLOW_SECRET_KEY chiffre les données sensibles stockées en base — changez la valeur par défaut avant le premier démarrage, car une rotation ultérieure invalide les données chiffrées existantes. LANGFLOW_AUTO_LOGIN à false oblige toujours un login explicite, même depuis localhost. LANGFLOW_WORKERS contrôle le nombre de processus Uvicorn : la valeur par défaut (1) convient pour un usage modéré, augmentez à 2 ou 4 si plusieurs utilisateurs exécutent des flows simultanément.

Pour les flows qui appellent des modèles locaux via Ollama, définissez OLLAMA_BASE_URL dans les variables globales de LangFlow plutôt que dans l'environnement Docker : la valeur est alors gérée par l'interface et peut être changée sans redémarrage.

Si vous mettez à jour LangFlow, faites toujours un pg_dump avant docker compose pull && docker compose up -d : certaines montées de version touchent au schéma de la base.

Erreur OOM (Out of Memory). Si le conteneur LangFlow se redémarre spontanément, consultez docker compose logs langflow et recherchez Killed. La cause est le manque de RAM. Réduisez LANGFLOW_WORKERS à 1 et, si le problème persiste, augmentez la RAM du VPS ou évitez d'exécuter des flows chargés simultanément.

RuntimeError: CUDA out of memory. Cette erreur survient lorsqu'un composant tente d'utiliser un GPU (via PyTorch ou un modèle Hugging Face) alors que le VPS n'en dispose pas ou que la mémoire GPU est insuffisante. Forcer l'exécution CPU en ajoutant la variable d'environnement CUDA_VISIBLE_DEVICES="" au service langflow dans le docker-compose.yml. Si l'erreur vient d'un modèle Hugging Face, sélectionnez une variante CPU (suffixe -cpu ou gguf) dans le composant.

Port 7860 déjà occupé. Si docker compose up -d échoue avec address already in use, un autre processus écoute sur ce port. Identifiez-le avec ss -tlnp | grep 7860 et arrêtez-le, ou changez le port hôte dans le docker-compose.yml ("127.0.0.1:7861:7860" par exemple) et mettez à jour la configuration nginx en conséquence.

ImportError: No module named 'torch' ou dépendance manquante. Certains composants avancés (embeddings Hugging Face, modèles locaux) nécessitent des bibliothèques lourdes non incluses dans l'image de base. Créez un Dockerfile dérivé qui installe les dépendances manquantes, ou utilisez l'image langflowai/langflow-backend avec les extras requis.

Connexion refusée à Ollama. Si LangFlow ne peut pas joindre Ollama tournant sur le même VPS, vérifiez que Ollama écoute sur 0.0.0.0 et non sur 127.0.0.1 uniquement. Dans docker-compose.yml, ajoutez extra_hosts: ["host-gateway:host-gateway"] au service LangFlow et utilisez l'adresse http://host-gateway:11434 dans les composants Ollama.

Canvas blanc ou WebSocket coupé. Vérifiez que les en-têtes Upgrade et Connection sont bien transmis par nginx. Un proxy intermédiaire (Cloudflare en mode Full Strict, load balancer) peut intercepter les WebSockets : assurez-vous que le protocole WebSocket est bien configuré en proxy.

Logs de flow absents ou incomplets. LangFlow stocke les logs d'exécution en base. Si la base PostgreSQL n'était pas prête au démarrage de LangFlow, les premières requêtes échouent silencieusement. Le healthcheck dans l'exemple de docker-compose.yml ci-dessus résout ce problème.

Une fois LangFlow opérationnel, plusieurs intégrations élargissent son périmètre d'usage.

Si vous souhaitez un modèle LLM entièrement local (sans appel API externe), installez Ollama sur le même VPS et connectez-le à LangFlow via le composant Ollama : vos pipelines n'envoient plus de données hors de votre infrastructure. Ollama expose une API compatible OpenAI sur le port 11434.

Pour un RAG documentaire plus robuste, passez de Chroma à Qdrant — une base vectorielle open source que vous déployez en conteneur voisin et qui offre de bonnes performances sur de grands corpus (plusieurs dizaines de milliers de documents).

Enfin, si plusieurs équipes utilisent l'instance, envisagez d'isoler les flows par espace de travail (feature disponible selon la version) ou de déployer une instance LangFlow par projet avec le template ServOrbit, qui configure automatiquement Docker Compose, PostgreSQL et le reverse proxy.