n8n : mémoire saturée et gros volumes, que faire ?

Un workflow qui marchait pour 200 lignes s'arrête à 20 000. L'interface affiche « Connection Lost », l'instance redémarre, et le message le plus utile se trouve dans les journaux du serveur : « JavaScript heap out of memory ». Dans ce cas, le réflexe est d'acheter plus de mémoire. C'est parfois la bonne réponse, rarement la première.

Cet article explique ce que n8n documente sur les erreurs de mémoire : comment les reconnaître, ce qui consomme, et les leviers à actionner dans l'ordre. Les faits viennent de la documentation officielle, citée en fin d'article ; les recommandations d'ordre et de méthode sont notre analyse, à adapter à votre instance.

Reconnaître un problème de mémoire

La documentation de n8n décrit plusieurs signes d'une saturation mémoire :

• le message « Execution stopped at this node (n8n may have run out of memory while executing it) » sur un nœud ;
• dans les journaux du serveur, « Allocation failed - JavaScript heap out of memory » ;
• des messages comme « Problem running workflow », « Connection Lost » ou une erreur 503 « Service Temporarily Unavailable », qui indiquent que l'instance est devenue indisponible.

Avec Docker et sur n8n Cloud, l'instance redémarre automatiquement après l'incident, selon la documentation. Avec une installation npm, il peut falloir la relancer à la main. Un redémarrage automatique masque donc le problème : surveillez les redémarrages (notre article sur la supervision d'une instance n8n détaille les contrôles utiles) au lieu de les subir.

Ce qui consomme de la mémoire

La documentation liste les facteurs qui pèsent sur la mémoire d'une exécution :

• la quantité de données JSON traitées ;
• la taille des données binaires, c'est-à-dire les fichiers (PDF, images, exports) ;
• le nombre de nœuds du workflow ;
• les nœuds gourmands : le nœud Code et l'ancien nœud Function, qui « peuvent augmenter la consommation de mémoire de façon significative » ;
• les exécutions manuelles, qui utilisent plus de mémoire parce que n8n copie les données pour les afficher dans l'interface ;
• les autres workflows qui tournent en même temps.

Ce dernier point compte : un workflow lourd planifié à l'heure où d'autres tournent sature plus vite qu'il ne le ferait seul. Les leviers de la mise à l'échelle (limiter les exécutions simultanées, passer en mode queue avec des workers) répondent à cette cause-là.

Les leviers, dans l'ordre

Voici l'ordre que nous suggérons, du moins coûteux au plus coûteux. Chaque levier correspond à une recommandation de la documentation de n8n.

1. Découper les données en lots

La documentation donne l'exemple de traiter 200 lignes par exécution plutôt que 10 000. Cela suppose de changer la façon de lire la source : une page ou une plage de dates par exécution, plutôt que tout d'un coup. Pour les traitements planifiés, c'est souvent le levier le plus efficace, car la mémoire utilisée ne dépend plus du volume total.

2. Traiter par lots avec Loop Over Items et un sous-workflow

Quand un seul workflow doit parcourir un gros volume, la documentation recommande de découper avec le nœud Loop Over Items, puis d'appeler un sous-workflow pour chaque lot avec le nœud Execute Sub-workflow. Le point qui change tout : la mémoire d'un sous-workflow est libérée à la fin de chaque lot. Il faut donc que le sous-workflow ne renvoie au parent qu'un petit résultat (un statut, un identifiant), pas les données complètes.

Le nœud Loop Over Items a un paramètre Batch Size, qui fixe le nombre d'éléments renvoyés à chaque itération. Il a deux sorties : Loop pour chaque lot, Done une fois tous les lots traités. La documentation précise aussi qu'on n'a souvent pas besoin de ce nœud : n8n traite déjà les listes d'éléments en entrée par défaut. Il sert surtout à traiter par lots pour respecter des limites d'API (voir notre article sur l'erreur 429 et les limites de débit) ou à construire des boucles manuelles. Pour la mémoire, c'est la combinaison avec un sous-workflow qui apporte le gain. Notre article sur les sous-workflows détaille leur construction.

3. Éviter le nœud Code quand un nœud natif suffit

Puisque le nœud Code est cité parmi les nœuds gourmands, la documentation recommande de l'éviter quand c'est possible. Remplacez-le par les nœuds natifs de transformation (Edit Fields, Filter, Aggregate) lorsqu'ils couvrent le besoin, et gardez le code pour ce qu'ils ne savent pas faire.

4. Ne pas lancer les gros traitements à la main

Une exécution manuelle consomme davantage. Pour un test sur un gros volume, travaillez sur un petit échantillon, puis laissez la planification ou le déclencheur réel faire le traitement complet.

5. Gérer les fichiers : le mode de stockage binaire

Par défaut, n8n garde les données binaires en mémoire, ce qui peut provoquer des plantages avec de gros fichiers, d'après la documentation. Le réglage N8N_DEFAULT_BINARY_DATA_MODE=filesystem enregistre ces données sur le disque plutôt qu'en mémoire.

Attention aux limites :

• en mode queue, le mode filesystem n'est pas pris en charge ; la documentation indique d'utiliser le mode database à la place ;
• le nettoyage des données binaires est intégré à l'élagage des exécutions et ne s'applique qu'au mode actif : si vous changez de mode, seules les données du mode actuel sont purgées. Notre article sur la purge des anciennes exécutions explique ce mécanisme.

Pensez donc à l'espace disque : déplacer les fichiers de la mémoire vers le disque règle la mémoire et peut créer un problème de stockage.

6. Augmenter les ressources

Si les leviers précédents ne suffisent pas, la documentation propose d'augmenter la mémoire : plus de mémoire provisionnée pour une instance auto-hébergée (avec le coût d'hébergement correspondant), ou un forfait supérieur sur n8n Cloud.

Pour l'erreur « JavaScript heap out of memory » en auto-hébergement, la documentation indique aussi de relever la limite de mémoire de V8 avec l'option --max-old-space-size=TAILLE, en ligne de commande ou via la variable d'environnement NODE_OPTIONS. Cette limite doit rester cohérente avec la mémoire réellement disponible sur la machine ou le conteneur : la relever au-dessus de ce que le serveur peut offrir ne fait que déplacer l'arrêt brutal.

Un exemple de découpage

Prenons un workflow qui lit chaque nuit toutes les factures d'un outil comptable, les enrichit puis les écrit dans un entrepôt de données. Il plante dès que le volume grandit.

1. Lire par plage de dates plutôt que tout l'historique : seules les factures modifiées depuis la dernière exécution entrent dans le workflow.
2. Boucler par lots de quelques centaines d'éléments avec Loop Over Items.
3. Déléguer l'enrichissement et l'écriture à un sous-workflow, qui renvoie seulement le nombre de lignes écrites.
4. Garder une trace du dernier lot réussi pour reprendre au bon endroit après une erreur, avec un workflow d'alerte sur erreur.

La mémoire utilisée ne dépend alors plus du nombre total de factures, mais de la taille d'un lot.

Checklist avant de relever la mémoire

1. Relever le message exact et le nœud concerné.
2. Vérifier la quantité de données entrantes et la présence de fichiers.
3. Vérifier si le workflow tourne en même temps que d'autres.
4. Réduire la quantité traitée par exécution.
5. Passer par Loop Over Items et un sous-workflow léger.
6. Remplacer les nœuds Code remplaçables.
7. Choisir le bon mode de stockage binaire, en tenant compte du mode queue.
8. Seulement ensuite, augmenter les ressources, et surveiller les redémarrages.

Questions fréquentes

Que signifie « JavaScript heap out of memory » dans n8n ?

C'est l'erreur qui apparaît dans les journaux du serveur lorsque le processus manque de mémoire. La documentation de n8n la cite parmi les signes d'une saturation, avec « Connection Lost » et les erreurs 503.

Faut-il toujours augmenter la mémoire du serveur ?

Non. La documentation place d'abord le découpage des données et l'usage de sous-workflows. Augmenter les ressources est le levier qui coûte le plus et ne corrige pas un workflow qui charge tout en une fois.

Pourquoi mon workflow plante-t-il en manuel mais pas en planifié ?

La documentation indique que les exécutions manuelles consomment plus de mémoire, car n8n copie les données pour l'interface. Un plantage uniquement en manuel peut donc être un effet de ce mode, pas du workflow.

Où stocker les fichiers volumineux ?

Le mode par défaut les garde en mémoire. Selon la documentation, vous pouvez les écrire sur le disque avec N8N_DEFAULT_BINARY_DATA_MODE=filesystem, sauf en mode queue où il faut utiliser le mode database.

Fiabiliser vos automatisations avec InfiniteLab

Une automatisation qui plante dès que les volumes montent coûte cher en reprises manuelles. Si vous voulez qu'un regard extérieur revoie la conception de vos workflows (découpage, reprise sur erreur, supervision), parlons de votre projet. Vous pouvez aussi consulter nos offres et notre méthode.

Sources

• n8n, Memory-related errors, documentation consultée le 1er novembre 2026.
• n8n, Binary data, documentation consultée le 1er novembre 2026.
• n8n, Loop Over Items (Split in Batches), documentation consultée le 1er novembre 2026.
• n8n, Sub-workflows, documentation consultée le 1er novembre 2026.