Déployer n8n sur Kubernetes avec Helm : le guide de production

Docker Compose suffit à la grande majorité des instances n8n self-hosted : un service n8n, un postgres, éventuellement un redis en mode queue, et c'est réglé. Kubernetes entre en jeu à un autre moment — quand votre équipe exploite déjà un cluster pour le reste de l'infrastructure, que vous avez besoin d'autoscaling piloté par métriques, ou que la conformité interne impose un déploiement GitOps standardisé. Depuis peu, n8n publie un chart Helm officiel, ce qui change la donne par rapport aux montages artisanaux d'il y a deux ans. Ce guide couvre l'installation, l'architecture queue mode sur K8s, la persistance de la clé de chiffrement, l'ingress et l'autoscaling — et surtout, quand ne pas s'embêter avec tout ça.

Le chart Helm officiel

n8n publie et maintient un chart Helm officiel, distribué comme artefact OCI sur GitHub Container Registry :

helm install n8n oci://ghcr.io/n8n-io/n8n-helm-chart/n8n \
  --version 1.0.0 \
  -f my-values.yaml

C'est une évolution récente : jusqu'ici, la référence communautaire pour héberger n8n sur Kubernetes était le chart tiers 8gears/n8n-helm-chart, toujours activement maintenu et parfaitement viable si vous l'avez déjà en production. Pour un nouveau déploiement, préférez le chart officiel : il suit directement les versions de n8n et couvre nativement le mode queue, le multi-main, les webhook processors et les task runners (voir notre guide des Task Runners pour ce que ce composant isole exactement).

Standalone vs queue mode : ce que le chart déploie réellement

Le chart expose deux modes de déploiement, à choisir selon votre volume réel :

• Standalone : une instance n8n unique avec SQLite sur un volume persistant. Aucune dépendance externe, mais aucune scalabilité horizontale — pertinent seulement pour un usage interne à faible volume ou un environnement de test.
• Queue mode (par défaut) : des pods main (interface, API, scheduling), des pods worker (exécution effective, stateless, scalables horizontalement) et, en option, des pods webhook processor dédiés à l'encaissement du trafic entrant sous forte charge — exactement l'architecture décrite dans notre guide du mode queue avec Redis, simplement orchestrée par Kubernetes plutôt que par docker compose --scale.

Point important à anticiper : le mode queue ne fournit ni PostgreSQL ni Redis. Le chart s'attend à ce que vous pointiez database.postgresdb.host vers une instance PostgreSQL existante (managée ou déployée séparément dans le cluster) et queue.bull.redis.host vers un Redis externe. C'est un choix assumé : faire cohabiter des bases de données stateful et des workloads applicatifs stateless dans le même chart complique la sauvegarde et la montée de version de chacun indépendamment — voir notre guide de sauvegarde PostgreSQL pour n8n pour la même logique appliquée hors Kubernetes.

La clé de chiffrement : le seul secret qui ne pardonne pas

N8N_ENCRYPTION_KEY chiffre tous les credentials stockés en base — clés API OpenAI, tokens Slack, mots de passe SMTP. Sur Kubernetes, cette valeur doit vivre dans un Secret, jamais en clair dans values.yaml versionné :

kubectl create secret generic n8n-encryption-key \
  --from-literal=N8N_ENCRYPTION_KEY="$(openssl rand -hex 32)"

Référencez ensuite ce secret dans values.yaml (extraEnvSecrets ou équivalent selon la version du chart) plutôt que la variable en clair. Le point critique, identique à un déploiement Docker classique mais plus facile à perdre de vue avec plusieurs environnements Kubernetes : si cette clé disparaît, tous les credentials chiffrés en base deviennent définitivement illisibles, sans mécanisme de récupération. Sauvegardez ce secret séparément de vos manifests Kubernetes et de votre dump PostgreSQL — les trois doivent survivre ensemble. Notre guide sur la sécurisation des credentials n8n détaille la rotation de clé et les bonnes pratiques de gestion au-delà du seul déploiement.

Persistance, ingress et webhooks

Activez persistence.enabled pour les pods main (fichiers binaires temporaires, cache), même si l'essentiel de l'état applicatif vit en PostgreSQL. Pour l'exposition publique :

• ingress.enabled=true génère un Ingress standard — combinez-le avec cert-manager pour le TLS automatique, le pendant Kubernetes de ce que couvre notre guide HTTPS avec Traefik ou Caddy hors cluster.
• Si vous activez des webhook processors dédiés, routez le trafic /webhook/* vers ce service spécifiquement plutôt que vers les pods main, pour que les déclenchements externes (Stripe, Typeform, WhatsApp) ne rivalisent jamais avec le chargement de l'éditeur.

Autoscaling : HPA natif et KEDA

Le chart expose des HorizontalPodAutoscaler pour les workers et les webhook processors, calés par défaut sur l'utilisation CPU — un signal simple mais imparfait pour anticiper un pic. Thanh-Tung Nguyen et ses co-auteurs, dans Horizontal Pod Autoscaling in Kubernetes for Elastic Container Orchestration (Sensors, 2020), montrent qu'un seuil CPU mal calibré produit soit un scaling trop lent (les pods existants saturent avant que de nouveaux démarrent), soit des oscillations coûteuses (scale up/down répétés sur des pics courts) — leurs mesures recommandent de coupler le seuil à la latence réelle des jobs plutôt qu'au seul CPU brut. Pour n8n spécifiquement, l'indicateur le plus pertinent n'est pas le CPU des workers mais la longueur de la file Redis : c'est exactement ce que permet l'intégration KEDA, qui scale directement sur le nombre de jobs en attente plutôt que sur une métrique indirecte. Réservez KEDA aux volumes qui justifient déjà le mode queue — sous 1 000 exécutions par jour, un workerReplicaCount fixe à 2 ou 3 se règle en une ligne et évite la complexité opérationnelle d'un autoscaler à surveiller.

Haute disponibilité : ce qui est Enterprise, ce qui ne l'est pas

Le multi-main — plusieurs pods main actifs simultanément avec anti-affinité automatique — est une fonctionnalité Enterprise du chart, nécessitant une licence. En édition self-hosted standard, un seul pod main tourne à la fois ; la résilience réelle vient plutôt du mode queue lui-même : les workers sont stateless et redémarrables sans perte, et un Deployment Kubernetes classique relance automatiquement un pod main qui plante, avec une brève interruption plutôt qu'une perte de données. Pour la plupart des équipes, cette résilience de base suffit largement ; le multi-main ne se justifie que si l'indisponibilité de quelques secondes lors d'un redémarrage de pod est réellement inacceptable pour votre activité.

Pourquoi Kubernetes plutôt que Docker Compose, concrètement

Kubernetes n'est pas plus fiable que Docker Compose par nature : c'est un système qui automatise des tâches (redémarrage, placement, scaling) que vous feriez sinon manuellement. Brendan Burns et ses co-auteurs, dans Borg, Omega, and Kubernetes (ACM Queue, 2016), reviennent sur une décennie de systèmes d'orchestration chez Google et notent que leur valeur vient précisément de là : décharger les opérateurs des décisions répétitives de placement et de reprise sur panne, pour se concentrer sur la configuration déclarative du système souhaité. Pour n8n, cela ne devient un vrai gain que si vous gérez déjà plusieurs services sur Kubernetes ailleurs dans votre organisation — sinon, le coût d'apprentissage et d'exploitation d'un cluster dédié à une seule application dépasse largement ce qu'il fait gagner. Notre comparatif du coût réel du self-hosting n8n et notre guide de choix de VPS restent le bon point de départ si Kubernetes n'est pas déjà une brique existante chez vous.

En résumé

Le chart Helm officiel de n8n couvre proprement le mode queue, la persistance, l'ingress et l'autoscaling (HPA natif ou KEDA sur la file Redis), avec la haute disponibilité multi-main réservée à l'édition Enterprise. Kubernetes se justifie quand votre organisation l'exploite déjà, pas comme premier choix d'hébergement pour une instance n8n isolée — Docker Compose avec le mode queue couvre l'immense majorité des besoins de production. Dans les deux cas, les workflows des packs FlowKit s'importent à l'identique : le Pack Conformité & Audit (149 €), pensé pour des équipes qui gardent la main sur leur infrastructure et leur piste d'audit, tourne aussi bien sur un cluster Kubernetes existant que sur un simple VPS.