Fichiers volumineux dans n8n : mémoire, binary data et erreurs OOM

Un workflow qui télécharge un PDF de deux pages ou une image de quelques dizaines de kilo-octets tourne sans problème quel que soit le réglage par défaut de n8n. Le jour où ce même workflow reçoit une vidéo de 2 Go, un lot de scans haute résolution ou un export CSV de plusieurs centaines de milliers de lignes, l'instance peut ralentir, puis planter avec une erreur de mémoire — souvent sans message très explicite. Ce guide explique comment n8n gère réellement les données binaires en interne, quelles limites configurer, et comment concevoir un workflow qui absorbe des fichiers volumineux sans mettre le serveur à genoux.

Comment n8n stocke les données binaires en interne

Chaque fois qu'un node manipule un fichier — téléchargement HTTP, pièce jointe email, export Google Drive, upload via un formulaire — n8n encapsule ce contenu dans un objet binaire attaché à l'item qui circule entre les nodes. La façon dont ce contenu est physiquement stocké pendant l'exécution dépend du mode configuré via la variable d'environnement N8N_DEFAULT_BINARY_DATA_MODE :

• default (mémoire) — le réglage par défaut. Le contenu binaire est gardé en RAM pendant toute la durée de l'exécution. Le plus rapide, mais aussi le plus fragile : chaque fichier volumineux, multiplié par les exécutions concurrentes, s'ajoute directement à la consommation mémoire du processus.
• filesystem — les fichiers binaires sont écrits sur le disque de l'instance plutôt que gardés en RAM, et seule une référence circule entre les nodes. Beaucoup plus économe en mémoire pour du contenu volumineux, au prix d'un accès disque légèrement plus lent.
• s3 — le binaire est déporté vers un bucket S3 (ou compatible S3). Réservé aux licences Enterprise, ce mode est pensé pour le mode queue et le multi-worker, où un stockage partagé accessible par toutes les instances devient nécessaire.
• database — le contenu est stocké dans la base de données de n8n elle-même. Pratique en dépannage rapide, mais peu adapté à des volumes réellement importants : la base grossit vite et les performances de lecture/écriture s'en ressentent.

Le mode filesystem n'est pas officiellement supporté en mode queue sans volume réseau partagé entre les workers (type EFS en lecture-écriture) : chaque worker ayant son propre disque local, un fichier écrit par l'un ne serait pas visible par l'autre. C'est l'une des raisons pour lesquelles notre guide sur le mode queue et Redis recommande de vérifier ce point avant de scaler un pipeline qui manipule beaucoup de binaire.

Les limites de taille à connaître

Deux variables d'environnement encadrent la taille des fichiers qu'un self-hosted accepte, avec des valeurs par défaut volontairement conservatrices :

Variable	Valeur par défaut	Ce qu'elle limite
N8N_PAYLOAD_SIZE_MAX	16 Mo	Taille maximale d'un payload JSON reçu (webhook classique, réponse d'API)
N8N_FORMDATA_FILE_SIZE_MAX	200 Mio	Taille maximale d'un fichier envoyé en multipart/form-data (upload via un Form Trigger ou un webhook de type fichier)

Les deux se relèvent sans redéploiement complexe, simplement en ajoutant la variable dans le docker-compose.yml ou la configuration du service. n8n Cloud applique ses propres limites, généralement plus généreuses, sans que l'utilisateur ait la main dessus. Relever ces plafonds ne règle toutefois qu'une partie du problème : au-delà de la taille acceptée en entrée, c'est la RAM réellement disponible sur le serveur qui détermine si le workflow tient la charge — voir notre guide sur le coût réel d'un n8n self-hosted pour dimensionner un VPS en conséquence.

Bonnes pratiques pour absorber les gros fichiers sans faire planter l'instance

Filtrer avant de télécharger. Le réflexe le plus rentable : ne récupérer que ce que le pipeline sait effectivement traiter. Un node qui liste des fichiers Google Drive avant de les télécharger devrait filtrer par type MIME et par taille dès cette étape, comme le recommande notre guide d'automatisation Google Drive — mieux vaut ignorer une vidéo de 2 Go que la charger en mémoire pour la rejeter ensuite.

Passer en mode filesystem dès que le binaire dépasse quelques dizaines de Mo en routine. Le gain mémoire est immédiat, et l'impact sur la latence reste marginal pour la plupart des workflows d'automatisation (par opposition à un usage temps réel critique). C'est le réglage à activer en premier avant même d'augmenter la RAM du serveur.

Éviter de faire transiter le binaire entier à travers tout le workflow. Quand seule une métadonnée est nécessaire en aval (nom, taille, hash), extrayez-la tôt et laissez le binaire de côté plutôt que de le faire voyager de node en node jusqu'à la fin. Un node Code placé juste après le téléchargement peut ne conserver que ce qui sert réellement à la suite.

Traiter par lots plutôt qu'en un seul bloc. Pour un traitement sur une liste de fichiers (scans à OCR, factures à extraire), le pattern Loop Over Items évite d'avoir tous les fichiers en mémoire simultanément — la charge reste bornée à la taille du lot, quel que soit le volume total à traiter. Le même principe protège des erreurs 429 en cas d'appel à une API IA sur chaque fichier, comme détaillé dans notre guide sur les rate limits.

Streamer vers la destination finale plutôt que tout charger puis tout renvoyer. Pour un pipeline de type téléchargement → stockage cloud, mieux vaut que le node de destination consomme directement le flux binaire reçu plutôt que d'accumuler une étape intermédiaire inutile. C'est particulièrement vrai pour les workflows de transcription de réunions, où les fichiers audio ou vidéo sources peuvent facilement dépasser plusieurs centaines de Mo.

Filesystem, S3 ou base : lequel choisir

Situation	Recommandation
Instance unique, fichiers occasionnels < 50 Mo	Mode mémoire (par défaut) suffit
Instance unique, fichiers réguliers > 50 Mo (scans, vidéos, exports)	Mode filesystem
Mode queue avec plusieurs workers, licence Enterprise disponible	Mode S3
Mode queue, sans licence Enterprise, binaire réellement volumineux	Repenser le workflow pour limiter le binaire transporté, ou volume réseau partagé en filesystem
Dépannage ponctuel, très faibles volumes	Mode base de données, à titre temporaire seulement

Dans un pipeline proche de celui du Pack Assistant RAG (119 €), qui ingère des PDF vers une base vectorielle Supabase, le mode filesystem évite qu'un lot de contrats scannés de plusieurs dizaines de Mo chacun ne sature la mémoire de l'instance pendant l'extraction de texte et le découpage en chunks. Le même raisonnement s'applique à un pipeline d'audit qui archive des pièces justificatives volumineuses, comme dans le Pack Conformité & Audit (149 €) : la piste d'audit elle-même doit rester légère, tandis que les documents source sont traités par lots et ne transitent jamais tous en mémoire au même instant.

Une question plus ancienne que n8n

Le choix entre stocker un objet volumineux dans une base de données ou sur un système de fichiers n'est pas propre à n8n : c'est une question classique de conception de systèmes. Une étude de référence de Microsoft Research, To BLOB or Not To BLOB: Large Object Storage in a Database or a Filesystem? (Sears, van Ingen & Gray, 2006 — voir sur Google Scholar), a mesuré ce compromis à grande échelle et conclut qu'en dessous d'environ 256 Ko, stocker l'objet dans la base reste plus performant, tandis qu'au-delà d'environ 1 Mo, le système de fichiers l'emporte nettement — l'écart se creusant encore avec la taille. Le seuil exact dépend du matériel et a beaucoup évolué depuis 2006, mais le principe reste d'actualité : les modes filesystem et s3 de n8n existent précisément parce qu'au-delà d'une certaine taille, faire porter le binaire par la base de données de l'instance (ou par sa mémoire vive) devient le mauvais choix architectural, pas juste un détail de configuration.

Pour aller plus loin

Un workflow qui manipule des fichiers volumineux mérite les mêmes réflexes que n'importe quel pipeline critique : un Error Workflow qui capture proprement un échec de téléchargement, une politique de retry avec backoff plutôt qu'un abandon sec, et une surveillance de la mémoire de l'instance décrite dans notre guide de supervision n8n. Combinés à un mode de stockage binaire adapté au volume réel traité, ces réglages transforment un point de fragilité classique en pipeline d'automatisation qui tient la charge sur la durée.