n8n sur Kubernetes : Helm Chart, Queue Mode et quand cela en vaut la peine

n8n peut généralement être exploité avec Docker Compose sur un seul serveur en quelques minutes, et pour la grande majorité des petites et moyennes entreprises, cette approche est tout à fait suffisante. Kubernetes avec le Helm Chart officiel ne devient pertinent que lorsque les workflows doivent être répartis sur plusieurs nœuds, mis à l'échelle automatiquement ou redémarrés automatiquement en cas de panne, par exemple en cas de volume de webhooks très élevé ou lorsqu'une plateforme Kubernetes est déjà utilisée dans l'entreprise pour d'autres applications. Le chart officiel est maintenu par n8n lui-même dans le dépôt n8n-io/n8n-hosting et publié via un registre OCI. Selon le README du chart, il prend en charge deux modes de fonctionnement : un mode autonome avec SQLite sans dépendances externes, et un mode file d'attente (Queue Mode) qui nécessite PostgreSQL et Redis et répartit la charge de travail sur des pods worker séparés. État : août 2026.

Que couvre concrètement le Helm Chart officiel de n8n ?

Le chart installe n8n via la commande helm install avec la référence OCI oci://ghcr.io/n8n-io/n8n-helm-chart/n8n et un fichier values.yaml personnalisé pour la configuration. Selon la documentation, Helm 3.12 minimum et un cluster Kubernetes en version 1.25 minimum sont requis. En Queue Mode, qui est le réglage par défaut du chart, l'architecture distingue trois types de pods : les pods main pour l'interface, l'API et les webhooks non productifs, les pods worker qui traitent les workflows depuis la file d'attente Redis et fonctionnent généralement en plusieurs instances, ainsi que des pods webhook dédiés optionnels pour le trafic webhook en production. Le chart apporte également la prise en charge de l'autoscaling horizontal via HPA et KEDA, tant pour les workers que pour les processeurs de webhooks.

Quel est le lien entre Queue Mode et Redis ?

Le Queue Mode est la condition préalable pour que plusieurs workers n8n puissent traiter des workflows en parallèle, et pour cela n8n a besoin de Redis comme file d'attente. Sans Queue Mode, une seule instance n8n traite les workflows séquentiellement dans le même processus qui sert également l'interface, ce qui ne pose pas de problème avec peu de workflows mais devient un goulot d'étranglement en cas de charge élevée. Lorsque le Queue Mode est activé, n8n place les workflows à exécuter dans une file d'attente Redis, dont les pods worker les récupèrent et les traitent indépendamment les uns des autres. Selon les indications du dépôt d'hébergement, Redis version 7 ou supérieure est recommandé pour une utilisation en production, la version 6 étant le minimum requis dès qu'un nom d'utilisateur Redis est configuré. PostgreSQL s'ajoute dans cette configuration en tant que base de données principale, SQLite n'étant pas prévu pour le Queue Mode.

Quels prérequis et quel effort devriez-vous prévoir de manière réaliste ?

Quiconque exploite le Helm Chart en production a besoin, outre un cluster Kubernetes opérationnel, d'expérience dans l'exploitation de PostgreSQL, Redis et la configuration d'ingress, car le chart prend en charge l'orchestration des composants n8n, mais pas l'exploitation des dépendances externes. Selon la documentation du chart, plusieurs instances main pour la haute disponibilité nécessitent en outre une licence Enterprise ainsi qu'une répartition de charge basée sur les sessions au niveau du load balancer. Pour l'isolation de l'exécution de code, le chart propose des task runners dédiés en tant que sidecars séparés, qui nécessitent leur propre authentification. En pratique, cela signifie que la charge opérationnelle supplémentaire par rapport à une installation Docker Compose est notable, de la maintenance du cluster au monitoring en passant par les stratégies de sauvegarde pour Redis et PostgreSQL. Pour une PME disposant d'une poignée d'automatisations qui peuvent se permettre d'attendre quelques secondes de plus dans la file, c'est généralement excessif. Cet effort a surtout du sens lorsque les équipes IT possèdent déjà des compétences Kubernetes ou lorsque n8n devient partie intégrante d'une plateforme plus vaste déjà exploitée sur Kubernetes. Quiconque n'est pas sûr du modèle d'hébergement adapté à sa propre charge d'automatisation devrait clarifier cette question avant la mise en œuvre, par exemple dans le cadre d'un conseil n8n, plutôt que de devoir gérer après coup une infrastructure surdimensionnée. Un coup d'œil au calculateur de ROI permet également de déterminer si l'effort opérationnel supplémentaire d'une solution Kubernetes est proportionné au bénéfice d'automatisation attendu.

Questions fréquentes sur n8n sur Kubernetes

Ai-je absolument besoin de Kubernetes pour n8n ?

Non, pour la plupart des PME, une installation Docker Compose sur un seul serveur suffit amplement. Kubernetes ne devient pertinent que lorsque la mise à l'échelle sur plusieurs nœuds, la tolérance aux pannes automatique ou une plateforme Kubernetes déjà existante dans l'entreprise entrent en jeu. Pour débuter ou pour des projets d'automatisation plus modestes, la charge opérationnelle d'un cluster n'est généralement pas justifiée.

Dois-je impérativement utiliser le Queue Mode avec le Helm Chart ?

Non, le chart officiel prend également en charge un mode autonome avec SQLite et sans dépendances externes telles que Redis ou PostgreSQL. Le Queue Mode ne devient rentable que lorsque plusieurs workers doivent traiter des workflows en parallèle, car c'est alors qu'une file d'attente Redis prend en charge la répartition. Pour un volume unique et gérable de workflows, le mode autonome est nettement plus simple à exploiter.

De quelle version de Kubernetes ai-je besoin pour le chart officiel ?

Selon le README du chart officiel, Helm 3.12 et Kubernetes 1.25 sont requis au minimum. Les versions de cluster plus anciennes ne sont pas officiellement prises en charge par le chart, une mise à niveau du cluster devrait donc être vérifiée avant l'installation. Ces exigences minimales peuvent évoluer avec les futures versions du chart.

Le chart officiel convient-il à la production ou uniquement aux tests ?

Le chart est conçu pour la production et apporte des fonctionnalités telles que l'autoscaling horizontal via HPA et KEDA, ainsi que des pods webhook dédiés pour le trafic en production. La condition préalable est cependant que les dépendances externes telles que PostgreSQL et Redis soient elles-mêmes exploitées de manière prête pour la production, le chart ne prenant en charge que l'orchestration de n8n lui-même. Quiconque ne dispose pas de cette expérience opérationnelle en interne devrait évaluer l'effort de manière réaliste avant de prendre une décision.