JavaScript heap out of memory : corriger les problèmes de mémoire n8n

L'erreur « JavaScript heap out of memory » se produit dans n8n quand une exécution de workflow demande plus de mémoire que le processus Node.js de n8n n'en dispose. Les causes les plus fréquentes sont les fichiers binaires volumineux, les grandes quantités de données JSON, le Code-Node ainsi que les exécutions manuelles, où n8n conserve une copie supplémentaire des données pour l'interface. Le problème peut être résolu en augmentant la mémoire disponible pour le processus n8n via la variable d'environnement NODE_OPTIONS avec le paramètre --max-old-space-size, en basculant le traitement des données binaires vers le mode système de fichiers, ainsi que par Execution-Pruning régulier, qui supprime automatiquement les anciennes données d'exécution. État : juillet 2026.

Pourquoi n8n affiche-t-il l'erreur « JavaScript heap out of memory » ?

L'erreur se produit parce que n8n, en tant qu'application Node.js, n'utilise par défaut qu'une quantité limitée de mémoire pour la taille du tas (heap) du moteur V8, et cette limite est dépassée lors de workflows gourmands en mémoire.

Selon la documentation officielle de n8n sur la résolution des problèmes de mémoire la consommation de mémoire d'une exécution dépend principalement de la quantité de données JSON, de la taille des données binaires, du nombre d'exécutions simultanées et de l'utilisation du Code-Node. Les exécutions manuelles via l'éditeur augmentent également la consommation, car n8n conserve une copie supplémentaire des données pour l'aperçu en direct dans le frontend.

• Grandes quantités de données : De nombreux objets JSON ou fichiers binaires volumineux par exécution.
• Code-Node : La logique JavaScript personnalisée peut augmenter considérablement la consommation de mémoire.
• Exécution manuelle : Copie de données supplémentaire pour l'affichage en direct dans l'éditeur.
• Exécutions parallèles : Plusieurs workflows exécutés simultanément s'accumulent.

Comment fournir plus de mémoire à n8n via NODE_OPTIONS ?

Vous augmentez la mémoire utilisable en transmettant le paramètre --max-old-space-size avec une limite de mémoire plus élevée en mégaoctets au processus Node.js via la variable d'environnement NODE_OPTIONS.

Selon la documentation, en cas d'erreur « JavaScript heap out of memory », il est judicieux d'agrandir la région Old-Memory (ancien tas) du moteur V8, soit via la ligne de commande, soit via NODE_OPTIONS. Pour les instances auto-hébergées, cela signifie concrètement : vous définissez par exemple NODE_OPTIONS avec la valeur --max-old-space-size=4096 pour allouer environ quatre gigaoctets de mémoire de tas ancien au processus, puis redémarrez n8n. Il est important de noter : ce paramètre n'a d'effet que si le serveur ou le conteneur dispose réellement d'une mémoire physique suffisante. Si ce n'est pas le cas, la documentation recommande d'équiper l'instance de plus de ressources en général ou de choisir un plan plus grand dans n8n Cloud.

Comment éviter les problèmes de mémoire avec les données binaires ?

n8n conserve par défaut les données binaires comme les fichiers, images ou PDF directement en mémoire, c'est pourquoi les fichiers volumineux causent rapidement des arrêts si vous ne basculez pas le mode de stockage vers le système de fichiers.

Selon la documentation sur la gestion des données binaires n8n stocke les données binaires en mémoire par défaut, ce qui peut causer des arrêts avec des fichiers volumineux. La variable d'environnement N8N_DEFAULT_BINARY_DATA_MODE permet de basculer le mode vers filesystem, de sorte que n8n écrit les données sur le disque à la place. En mode Queue, le mode système de fichiers n'est pas pris en charge selon la documentation, le mode de base de données est utilisé à la place. Il est important de savoir que : le nettoyage des données binaires fonctionne également via le modèle de stockage actif. Si vous changez de mode, les données anciennes restent dans l'emplacement de stockage précédent jusqu'à ce qu'elles soient supprimées manuellement.

Comment Execution-Pruning aide-t-il à contenir la croissance de la consommation de mémoire ?

Execution-Pruning supprime automatiquement les exécutions terminées ainsi que les données d'exécution et binaires associées selon l'âge ou le nombre, de sorte que la base de données et la mémoire ne croissent pas sans contrôle.

Selon la documentation sur la gestion des données d'exécution Pruning est activé par défaut et s'exécute dès qu'une exécution est plus ancienne que la valeur de EXECUTIONS_DATA_MAX_AGE en heures (par défaut : 336 heures, soit 14 jours) ou lorsque le nombre total d'exécutions dépasse la valeur de EXECUTIONS_DATA_PRUNE_MAX_COUNT (par défaut : 10 000). Les exécutions en cours, en attente ou nouvelles, ainsi que les exécutions avec des étiquettes ou des évaluations, ne sont jamais supprimées. De plus, un tampon de sécurité via la variable EXECUTIONS_DATA_HARD_DELETE_BUFFER (par défaut : une heure) garantit que vous pouvez toujours consulter les exécutions récemment terminées, tandis que la mémoire est libérée en arrière-plan.

• EXECUTIONS_DATA_PRUNE : Active le nettoyage automatique, actif par défaut.
• EXECUTIONS_DATA_MAX_AGE : Supprime les exécutions après l'âge en heures, par défaut 336.
• EXECUTIONS_DATA_PRUNE_MAX_COUNT : Limite le nombre total d'exécutions stockées, par défaut 10 000.

Quels ajustements de workflow réduisent davantage la consommation de mémoire ?

Au-delà des paramètres côté serveur, la manière la plus efficace de réduire la consommation de mémoire est de l'adapter directement dans la conception du workflow, en traitant les données par petites portions au lieu de tout charger à la fois.

La documentation de n8n recommande concrètement de diviser les données en blocs plus petits, de traiter environ 200 au lieu de 10 000 enregistrements par exécution, d'éviter le Code-Node si possible et d'exécuter les grandes quantités de données via un déclencheur plutôt que manuellement. Pour les très grandes quantités de données, la documentation suggère de diviser le workflow en sous-workflows en utilisant le Loop-Over-Items-Node et le Execute-Workflow-Node, de sorte que seules les données du lot actuel soient conservées en mémoire puis libérées par la suite. Si vous utilisez n8n en production pour des automatisations plus complexes et ne souhaitez pas reconstruire ces leviers vous-même, NordFlux vous accompagne pour la mise en place et sécurisation des workflows n8n ainsi que la configuration serveur appropriée.

Questions fréquentes sur les problèmes de mémoire n8n

Combien de mémoire un serveur n8n devrait-il avoir au minimum ?

La documentation n'indique pas de valeur minimale fixe, mais indique que les besoins dépendent de la quantité de données et du nombre d'exécutions parallèles. En pratique, vous devriez allouer suffisamment de mémoire pour que la max-old-space-size définie via NODE_OPTIONS soit également couverte physiquement, sinon le problème se déplace simplement.

Un paramètre NODE_OPTIONS plus élevé résout-il chaque problème de mémoire ?

Non, une limite de tas plus élevée ne fournit qu'un tampon plus important, mais ne résout pas la cause profonde comme les workflows inefficaces ou la croissance incontrôlée des données binaires. Selon la documentation, vous devriez également réduire la quantité de données par exécution et maintenir Execution-Pruning actif afin que la consommation de mémoire reste contrôlée à long terme.

Que se passe-t-il si je désactive Execution-Pruning ?

Sans Pruning, les exécutions terminées ainsi que les données d'exécution et binaires s'accumulent sans limite dans la base de données. Cela conduit à long terme à une consommation de mémoire croissante selon la documentation, c'est pourquoi n8n active le nettoyage par défaut.

Pourquoi l'erreur se produit-elle principalement lors des exécutions manuelles ?

Parce que n8n conserve une copie supplémentaire des données d'exécution pour l'affichage en direct dans le frontend lors d'une exécution manuelle via l'éditeur. Avec de grandes quantités de données, cela augmente notablement la consommation de mémoire, c'est pourquoi la documentation recommande de commencer les traitements volumineux via un déclencheur plutôt que manuellement.