Index du journalDockup / note de terrain
Note / self-host-langflow

Comment auto-héberger Langflow en 2026 : flows, accès à l’API et état persistant

Auto-hébergez Langflow avec les bons ports, un stockage persistant, HTTPS, des secrets, des sauvegardes et des vérifications de mise à niveau. Découvrez comment résoudre le problème d’un secret qui change après un redémarrage.

Considérez Langflow comme un petit système, et non comme une simple image Docker. L’objectif côté utilisateur est clair : disposer d’un visual builder de workflows LLM qui expose les flows sous forme d’APIs. Le déploiement n’est acceptable que lorsque vous pouvez créer un flow avec des credentials de fournisseur, l’exécuter dans l’éditeur, appeler son API et vérifier la réponse après le redémarrage d’un service.

Cette distinction permet de détecter le problème que les opérateurs rencontrent après les tests locaux : un secret change après un redémarrage ou des dépendances de composants sont absentes. Elle permet également de définir un plan de sauvegarde et de mise à niveau suffisamment précis pour être testé.

Définissez d’abord les critères de réussite de Langflow

Ne laissez pas l’image Langflow imposer par accident l’architecture de production. L’image fournit un processus sur le port 7860 ; le stockage, le routage et les exigences externes nécessitent toujours des cycles de vie définis avec soin. Le contrat réseau de Langflow repose sur Postgres pour l’état durable et sur les credentials des fournisseurs de modèles. Gardez les endpoints privés sur un DNS interne, autorisez uniquement les appels sortants nécessaires et attribuez à Langflow un credential de service aux permissions limitées.

Le déploiement est prêt pour des tests plus approfondis lorsqu’il peut créer un flow avec des credentials de fournisseur, l’exécuter dans l’éditeur, appeler son API et vérifier la réponse après le redémarrage d’un service. Suivez la transaction dans les logs et surveillez l’exécution des composants, la latence des modèles, les appels API parallèles, l’analyse des fichiers et le nombre de connexions à la base de données. Ces observations montrent si la topologie actuelle isole correctement les composants concernés.

Lancez Langflow avec des paramètres par défaut observables

Gardez l’invocation initiale de Langflow suffisamment reproductible pour pouvoir être relue dans une pull request.

docker run -d \
  --name langflow \
  --restart unless-stopped \
  -p 127.0.0.1:7860:7860 \
  -v langflow-data:/app/langflow \
  -e LANGFLOW_SECRET_KEY=replace-with-a-long-random-value \
  langflowai/langflow:latest

Ne vous fiez pas à latest une fois que de vraies données existent. Notez le digest utilisé, l’utilisateur du conteneur et les permissions du montage. Suivez les logs de l’application pendant un test complet — créer un flow avec des credentials de fournisseur, l’exécuter dans l’éditeur, appeler son API et vérifier la réponse après le redémarrage d’un service — et notez les éventuelles migrations avant de placer la route derrière le trafic de production.

Testez Langflow depuis l’extérieur du serveur

Considérez l’URL externe de Langflow comme une configuration qui doit survivre aux redeploys. Commencez par définir l’adresse publique utilisée par les clients API et les callbacks d’authentification, puis routez le hostname vers le port 7860 en conservant l’hôte et le schéma d’origine.

La checklist d’accessibilité du déploiement peut confirmer que les requêtes atteignent le conteneur. Une fois cette étape franchie, le problème connu — un secret qui change après un redémarrage ou des dépendances de composants absentes — doit être recherché dans Langflow, son état ou sa charge de travail, et non dans l’automatisation des certificats.

Séparez les conteneurs remplaçables des données durables

Une image de conteneur peut être téléchargée à nouveau ; les flows, la base de données, les clés API et les fichiers importés, eux, ne le peuvent pas. Montez /app/langflow avant le bootstrap, écrivez quelques données d’exemple inoffensives, puis remplacez le conteneur pour vérifier que ce chemin est réellement persistant. Inspectez le montage effectif au lieu de vous fier au nom d’un fichier Compose, et vérifiez que l’utilisateur d’exécution peut écrire à l’emplacement attendu par Langflow.

Choisissez une durée de conservation et une destination hors hôte, puis répétez la procédure de restauration sans toucher à la production. Le test n’est réussi que lorsque les flows, les utilisateurs, les credentials et les fichiers sont restaurés et qu’un client API existant peut exécuter le flow restauré. Pour un état reposant sur une base de données, associez les snapshots du stockage à des exports cohérents du point de vue de l’application, comme indiqué dans récupération à un instant donné ou snapshots.

Décisions de sécurité propres à Langflow

N’héritez pas des hypothèses de sécurité d’un tutoriel local. Le principal enjeu propre à Langflow est d’exposer la création de flows et les clés de fournisseurs stockées sans authentification. En production, protégez donc le builder, limitez l’accès à l’API et conservez les credentials des modèles dans un stockage chiffré côté serveur.

Traitez LANGFLOW_SECRET_KEY en fonction de son rôle dans Langflow : gardez les valeurs sensibles hors de Git, documentez les effets d’une rotation et ne remplacez jamais un exemple public en production. Limitez les accès au système de fichiers et au réseau, protégez les endpoints de configuration initiale et définissez des limites d’upload, de requêtes ou d’exécution autour de l’exécution des composants, de la latence des modèles, des appels API parallèles, de l’analyse des fichiers et du nombre de connexions à la base de données.

Vérifications de capacité et de mise à niveau

La première métrique opérationnelle utile pour Langflow est sa capacité à créer un flow avec des credentials de fournisseur, à l’exécuter dans l’éditeur, à appeler son API et à vérifier la réponse après le redémarrage d’un service. Associez-la aux signaux de saturation liés à l’exécution des composants, à la latence des modèles, aux appels API parallèles, à l’analyse des fichiers et au nombre de connexions à la base de données. Une sonde limitée au processus ne doit pas appeler de dépendances coûteuses ni redémarrer le conteneur parce qu’un service en amont est momentanément indisponible.

Traitez les mises à niveau comme des changements de données, car les packages de composants, les migrations de base de données et les flows sérialisés peuvent changer d’une version de Langflow à l’autre. Épinglez les versions, répétez la procédure sur un état restauré et conservez l’image précédente tant qu’un rollback reste possible. Lorsqu’un secret change après un redémarrage ou que des dépendances de composants sont absentes, conservez les logs précédant le redémarrage ; ils contiennent généralement le message indiquant la cause.

Documentez un déploiement Langflow validé

Transformez le smoke test de Langflow en une commande de release reproductible ou en un court runbook. Sa sortie doit démontrer le résultat suivant : créer un flow avec des credentials de fournisseur, l’exécuter dans l’éditeur, appeler son API et vérifier la réponse après le redémarrage d’un service. Enregistrez avec le résultat la version de l’application, le digest du conteneur, le hostname de la route et l’identifiant des données de test.

Exécutez la même vérification après un remplacement standard du conteneur et après avoir restauré ailleurs les flows, la base de données, les clés API et les fichiers importés. La restauration est réussie lorsque les flows, les utilisateurs, les credentials et les fichiers sont récupérés et qu’un client API existant peut exécuter le flow restauré. Comparez la durée et la consommation liées à l’exécution des composants, à la latence des modèles, aux appels API parallèles, à l’analyse des fichiers et au nombre de connexions à la base de données ; une variation importante mérite une investigation, même si l’action finale réussit toujours.

Exercez ensuite une panne contrôlée : refusez temporairement à l’identité de test l’accès à Postgres pour l’état durable et aux credentials des fournisseurs de modèles. Vérifiez que Langflow signale le problème et revient à la normale sans modifications manuelles destructrices. Conservez uniquement l’extrait de logs nécessaire, après en avoir supprimé les informations sensibles. Cette validation en quatre parties couvre le démarrage, la persistance, la récupération et la gestion des erreurs.

Ce que Dockup devrait automatiser pour Langflow

La couche plateforme de Langflow comprend le port 7860, l’ingress, TLS, la configuration d’exécution, le stockage et l’accessibilité des dépendances. Dockup peut reproduire ces éléments pour sa propre infrastructure ou pour un serveur auquel le client connecte la plateforme.

L’opérateur termine ensuite la couche produit : définir l’adresse publique utilisée par les clients API et les callbacks d’authentification ; appliquer cette règle d’accès — protéger le builder, limiter l’accès à l’API et conserver les credentials des modèles dans un stockage chiffré côté serveur — ; puis exécuter « créer un flow avec des credentials de fournisseur, l’exécuter dans l’éditeur, appeler son API et vérifier la réponse après le redémarrage d’un service ». Enregistrer ce test avec le déploiement évite de confondre le provisioning automatisé avec la disponibilité de l’application.

Foire aux questions

De quoi Langflow a-t-il besoin pour un déploiement en production ?

Routez le conteneur Langflow sur le port 7860 via une origine HTTPS unique. L’exigence réseau complémentaire repose sur Postgres pour l’état durable et sur les credentials des fournisseurs de modèles. Ne considérez pas Langflow comme prêt tant que vous ne pouvez pas créer un flow avec des credentials de fournisseur, l’exécuter dans l’éditeur, appeler son API et vérifier la réponse après le redémarrage d’un service.

Quelles données Langflow doivent figurer dans une sauvegarde ?

Rendez /app/langflow persistant et incluez les flows, la base de données, les clés API et les fichiers importés dans le même manifeste de restauration. Une restauration propre de Langflow n’est validée que lorsque les flows, les utilisateurs, les credentials et les fichiers sont récupérés et qu’un client API existant peut exécuter le flow restauré.

Langflow nécessite-t-il HTTPS derrière un reverse proxy ?

Utilisez HTTPS pour l’origine publique de Langflow et gardez le port 7860 sur la route interne. Appliquez correctement le paramètre Langflow : définissez l’adresse publique utilisée par les clients API et les callbacks d’authentification. Pour Langflow, HTTPS protège les credentials ou le contenu utilisateur pendant leur transfert et garantit un comportement cohérent des clients sensibles à l’origine.

Comment tester une mise à niveau de Langflow ?

Restaurez l’état actuel de Langflow dans un déploiement isolé, appliquez la version candidate et répétez sa transaction de validation. Soyez particulièrement attentif, car les packages de composants, les migrations de base de données et les flows sérialisés peuvent changer d’une version de Langflow à l’autre. Conservez l’image Langflow précédente jusqu’à ce que les limites de migration des données et de rollback soient comprises.