Comment héberger Flowise sur un VPS

Flowise manipule des données sensibles : clés API OpenAI/Anthropic, documents internes vectorisés, historiques de conversation, logiques métier de vos agents. En version cloud partagée, ces éléments transitent par une infrastructure que vous ne contrôlez pas. Sur un VPS dédié, le canvas Flowise, la base de données et les embeddings restent chez vous. Vous gardez la main sur les versions (les flux évoluent vite entre releases), sur les connecteurs activés, et sur la facturation des modèles puisque vous branchez vos propres clés. Un VPS vous permet aussi d'exposer les flux en API REST pour les intégrer à vos propres applications, sans quota imposé par un éditeur.

Autre raison pratique : les plans SaaS de Flowise Cloud limitent le nombre de flux actifs, le nombre d'exécutions mensuelles et l'accès aux nœuds avancés. Sur votre VPS, aucune de ces limites ne s'applique — vous définissez vous-même les ressources allouées.

Flowise lui-même est léger, mais l'usage réel dépend des embeddings et des bases vectorielles. Comptez au minimum 2 vCPU et 2 Go de RAM pour un usage de test, et 4 vCPU / 4 à 8 Go de RAM si vous indexez des documents volumineux ou faites tourner plusieurs flux concurrents. Prévoyez 20 Go de disque pour les conteneurs, les stores vectoriels et les éventuels modèles locaux.

Côté logiciel : Docker et Docker Compose installés, un nom de domaine ou sous-domaine (ex. flowise.votre-domaine.com) pointant vers l'IP du VPS, et le port 443 ouvert. Si vous envisagez un LLM local via Ollama, augmentez la RAM à 8 Go minimum (16 Go pour des modèles 7B+ en quantification 4 bits). Les clés API des fournisseurs LLM que vous comptez utiliser sont à préparer en amont.

Pour des flux RAG performants et sans coût d'API externe, branchez Flowise sur un conteneur Ollama tournant sur le même VPS via le réseau Docker interne (http://ollama:11434). Vous combinez ainsi embeddings et génération en local : aucune donnée ne sort du serveur, et la latence chute car tout transite par le réseau privé du host.

Dans votre docker-compose.yml, ajoutez le service Ollama sur le même réseau Docker que Flowise :

services:
  ollama:
    image: ollama/ollama
    volumes:
      - ollama_data:/root/.ollama
    networks:
      - flowise_net

  flowise:
    image: flowiseai/flowise
    networks:
      - flowise_net
    ...

Dans Flowise, lorsque vous ajoutez un nœud Ollama (Chat Model ou Embeddings), renseignez http://ollama:11434 comme base URL. Téléchargez un modèle depuis le conteneur : docker exec -it <id_ollama> ollama pull llama3.2. Pour les embeddings, nomic-embed-text est un bon point de départ sur 4 Go de RAM.

Flowise expose une vingtaine de variables de configuration. Les plus utiles en production :

FLOWISE_USERNAME et FLOWISE_PASSWORD — authentification de l'interface admin. Obligatoires dès qu'on ouvre le port public.

FLOWISE_SECRETKEY_OVERWRITE — clé de chiffrement des credentials stockés en base. Si vous changez cette valeur après un premier démarrage, les credentials existants deviennent illisibles.

DATABASE_TYPE — par défaut sqlite. Pour une charge plus lourde ou un déploiement redondant, passez à postgres et renseignez DATABASE_HOST, DATABASE_PORT, DATABASE_USER, DATABASE_PASSWORD, DATABASE_NAME.

CORS_ORIGINS — liste des origines autorisées à appeler l'API de prédiction depuis un navigateur. Exemple : https://votre-app.com. Sans cette variable, les appels CORS depuis une autre origine seront bloqués.

BLOB_STORAGE_PATH — chemin de stockage des fichiers uploadés (documents RAG). Par défaut dans ~/.flowise/storage ; montez un volume dédié si vous indexez de gros corpus.

LOG_LEVEL — valeurs : error, warn, info, verbose, debug. En production, warn suffit pour limiter les logs.

Flowise sort des mises à jour régulières qui ajoutent des nœuds et corrigent des comportements de flux. La mise à jour est non destructive si vos données sont dans un volume nommé.

docker compose pull
docker compose up -d

Flowise migre automatiquement la base SQLite au démarrage. Avant chaque mise à jour, exportez vos flux importants via le bouton Export du canvas (fichier JSON) — c'est le filet de sécurité le plus simple.

Si vous utilisez PostgreSQL, vérifiez les notes de release avant de tirer l'image : certaines versions introduisent des migrations de schéma irréversibles. Conservez une sauvegarde de la base (pg_dump) avant de mettre à jour.

Le canvas ne se charge pas ou les nœuds disparaissent. Vérifiez que votre reverse proxy propage bien les WebSockets. Avec nginx, les en-têtes Upgrade et Connection doivent être présents. Avec Caddy, ils le sont automatiquement.

Error: FLOWISE_SECRETKEY_OVERWRITE is required. Cette variable n'était pas obligatoire dans les versions antérieures, mais l'est devenue. Ajoutez-la dans votre compose et redémarrez — les credentials déjà saisis restent valides si la valeur est cohérente avec celle utilisée lors de leur stockage.

La base vectorielle perd ses documents après redémarrage. Vérifiez que le chemin du volume Docker correspond bien à BLOB_STORAGE_PATH et à DATABASE_PATH. Un volume bind-mount mal configuré porte les données dans un dossier ephémère du conteneur.

Les appels à Ollama échouent avec ECONNREFUSED. Le service Ollama doit être sur le même réseau Docker que Flowise. Si Ollama tourne en dehors de Compose (service systemd, par exemple), utilisez l'IP de la passerelle Docker (172.17.0.1:11434) plutôt que localhost.

Les credentials OpenAI/Anthropic sont refusés après migration. Si FLOWISE_SECRETKEY_OVERWRITE a changé entre deux déploiements, les secrets chiffrés avec l'ancienne clé ne peuvent plus être déchiffrés. Supprimez et re-saisissez les credentials dans l'interface.