[{"data":1,"prerenderedAt":150},["ShallowReactive",2],{"seo-verification":3,"blog-n8n-erreurs-memoire-oom-production-vps-fr":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-n8n-erreurs-memoire-oom-production-vps-fr",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":27,"featuredImage":29,"bgImage":30,"posterImage":31,"relatedSolution":32,"intro":34,"sections":35,"ctaTitle":91,"ctaBody":92,"ctaButton":93,"ctaUrl":94,"relatedPosts":95},420,"n8n-erreurs-memoire-oom-production-vps",{"fr":10,"en":12,"ar":13,"es":14},"n8n-out-of-memory-fix-vps-production","n8n-إصلاح-أخطاء-الذاكرة-heap-vps","n8n-errores-memoria-oom-correccion-vps","n8n out of memory : diagnostic et correction sur VPS","FATAL ERROR heap out of memory sur n8n : identifier la cause exacte (plafond V8, mode webhook, workers non séparés) et corriger sans migrer.",9,0,false,"2026-10-07T00:00:00+00:00","2026-10-07T23:07:24+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":25},2,"Automatisation","automatisation","bg-brand-action\u002F10 text-brand-action",[28],{"id":23,"name":24,"slug":25,"color":26,"icon":25},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fn8n-erreurs-memoire-oom-production-vps-poster.svg",{"categorySlug":25,"appSlug":33},"n8n","Le message `FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory` coupe n8n sans avertissement préalable. Beaucoup d'équipes ajoutent de la RAM et constatent que rien ne change — parce que le plafond V8 est indépendant de la mémoire physique du serveur et qu'il faut le poser explicitement. Cet article détaille les trois causes réelles du crash OOM, la variable d'environnement qui corrige chacune, et la séparation worker\u002Fwebhook qui élimine les rechutes.",[36,40,50,53,78,82,85,88],{"type":37,"title":38,"body":39},"h2","Pourquoi n8n crashe en mémoire, et pas pour la raison qu'on croit","V8, le moteur JavaScript embarqué dans Node.js, dispose d'un plafond de heap indépendant de la RAM physique. Par défaut il oscille entre 512 Mo et 1,5 Go selon la version de Node et la plateforme — sur un VPS à 4 Go ou 8 Go, la machine n'est pas à court de mémoire, mais le processus V8, lui, l'est. Allouer plus de RAM au serveur ne change rien sans `NODE_OPTIONS=--max-old-space-size`.\n\nDeuxième cause fréquente : en mode `main` (le mode par défaut), n8n exécute les workflows dans le même processus qui sert les webhooks et l'API. Un workflow lourd en données — transformation CSV, agrégation de plusieurs milliers de lignes, appel GPT en boucle — monopolise le heap pendant son exécution. Si plusieurs s'accumulent, le plafond V8 est atteint et le processus est tué.\n\nTroisième cause, plus subtile : les jobs s'accumulent en mémoire quand le mode queue est activé sans workers dédiés. La queue (Redis ou BullMQ) déleste le main process des exécutions, mais si aucun worker ne consomme réellement les jobs, ceux-ci s'accumulent, les callbacks restent en attente et le heap grossit.",{"type":41,"title":42,"items":43},"ul","Signaux qui confirment un crash OOM n8n",[44,45,46,47,48,49],"**Message de sortie exact** : `FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory` dans les logs du conteneur (`docker logs n8n`)","**Crash silencieux sous systemd** : le service redémarre automatiquement sans laisser de trace si `Restart=always` est actif — vérifier `journalctl -u n8n --since \"1 hour ago\"`","**OOM kill du noyau** : `dmesg | grep -i oom` montre `Killed process \u003Cpid> (node)` avant le redémarrage, indépendamment de Node","**Corrélation avec un workflow lourd** : le crash survient toujours pendant les exécutions de type « traitement de fichier » ou « boucle sur plusieurs milliers d'items »","**Heap stable pendant des heures puis pic soudain** : un workflow déclenché périodiquement accumule des closures non libérées — le heap monte à chaque run et ne redescend pas complètement","**Charge mémoire normale sur htop** : la RAM système n'est pas saturée au moment du crash, ce qui confirme que le problème est V8, pas la machine",{"type":37,"title":51,"body":52},"Prérequis avant d'intervenir","Ces étapes supposent que n8n tourne déjà sur votre VPS via Docker Compose. Si ce n'est pas le cas, l'article `installer-n8n-vps` couvre le déploiement complet depuis zéro — revenez ici une fois l'instance en place.\n\nCe qu'il vous faut pour appliquer les corrections :\n\n- **Accès SSH root** au VPS et fichier `docker-compose.yml` éditable\n- **Mémoire disponible** : un plafond V8 de 4 096 Mo (`--max-old-space-size=4096`) suppose au moins 6 Go de RAM sur le VPS pour laisser de la marge au système d'exploitation, aux workers et à Redis\n- **Redis** déjà déployé si vous passez en mode queue — `redis:7-alpine` suffit pour un usage mono-VPS\n- **Version n8n** 1.0 ou supérieure : la séparation main\u002Fworker est disponible depuis la version 0.214 mais n'est stable en production qu'à partir de 1.0\n- **Sauvegarde de la base de données** avant toute modification du Compose — les tables de credentials et d'exécutions ne font pas partie de l'image Docker",{"type":54,"title":55,"steps":56},"steps","Corriger l'OOM : du diagnostic à la configuration stable",[57,60,63,66,69,72,75],{"title":58,"body":59},"Confirmer la cause dans les logs","Lisez les 200 dernières lignes du conteneur au moment du crash :\n\n```bash\ndocker logs n8n --tail 200 2>&1 | grep -E \"FATAL|heap|OOM|Killed\"\n```\n\nSi vous voyez `FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory`, c'est un crash V8. Si vous voyez `Killed` seul sans message Node, c'est l'OOM killer du noyau — les deux peuvent coexister sur le même incident.",{"title":61,"body":62},"Poser le plafond V8 dans la variable NODE_OPTIONS","Dans votre `docker-compose.yml`, ajoutez la variable d'environnement `NODE_OPTIONS` sur le service n8n. La valeur recommandée selon la RAM du VPS :\n\n- VPS **4 Go** : `--max-old-space-size=2048`\n- VPS **8 Go** : `--max-old-space-size=4096`\n- VPS **16 Go** : `--max-old-space-size=8192`\n\nRègle : réserver environ la moitié de la RAM disponible après système d'exploitation et services annexes (Redis, proxy). Ne pas dépasser 70 % de la RAM totale.\n\n```bash\nservices:\n  n8n:\n    image: n8nio\u002Fn8n:latest\n    environment:\n      - NODE_OPTIONS=--max-old-space-size=4096\n      # ... autres variables\n```\n\n**Attention :** Ne mettez **pas** `NODE_OPTIONS` à l'intérieur d'un span de backticks dans vos fichiers `.env` si vous utilisez la substitution de variables — la valeur doit être une chaîne littérale.",{"title":64,"body":65},"Vérifier que la valeur est bien prise en compte","Après `docker compose up -d`, vérifiez que Node lit bien le plafond :\n\n```bash\ndocker exec n8n node -e \"const v8=require('v8'); console.log(v8.getHeapStatistics().heap_size_limit \u002F 1024 \u002F 1024, 'MB')\"\n```\n\nLa valeur affichée doit approcher votre `--max-old-space-size`. Si elle affiche encore 512 ou 1500, la variable d'environnement n'est pas transmise au processus — vérifiez que `NODE_OPTIONS` est dans la section `environment:` du service, pas dans `env_file:` avec une valeur mal parsée.",{"title":67,"body":68},"Passer en mode queue avec Redis","Le mode `main` (défaut) exécute tout dans un seul processus. Pour les instances qui traitent plus de 20 workflows simultanés ou des payloads volumineux, séparez les rôles :\n\n```yaml\nservices:\n  redis:\n    image: redis:7-alpine\n    restart: unless-stopped\n    volumes:\n      - redis_data:\u002Fdata\n\n  n8n:\n    image: n8nio\u002Fn8n:latest\n    environment:\n      - NODE_OPTIONS=--max-old-space-size=2048\n      - EXECUTIONS_MODE=queue\n      - QUEUE_BULL_REDIS_HOST=redis\n      - QUEUE_BULL_REDIS_PORT=6379\n    depends_on:\n      - redis\n    ports:\n      - \"5678:5678\"\n\n  n8n-worker:\n    image: n8nio\u002Fn8n:latest\n    command: worker\n    environment:\n      - NODE_OPTIONS=--max-old-space-size=4096\n      - EXECUTIONS_MODE=queue\n      - QUEUE_BULL_REDIS_HOST=redis\n      - QUEUE_BULL_REDIS_PORT=6379\n    depends_on:\n      - redis\n    scale: 2\n\nvolumes:\n  redis_data:\n```\n\nLe service `n8n` devient le **main process** (API + interface + webhooks) avec un plafond modéré. Le service `n8n-worker` prend en charge les exécutions avec un plafond plus généreux. La directive `scale: 2` lance deux workers — ajustez selon vos besoins.",{"title":70,"body":71},"Séparer le webhook process si le trafic l'exige","Sur les instances qui reçoivent beaucoup de webhooks en parallèle, le main process peut être saturé même sans exécuter de workflows. n8n propose un mode webhook dédié :\n\n```yaml\n  n8n-webhook:\n    image: n8nio\u002Fn8n:latest\n    command: webhook\n    environment:\n      - NODE_OPTIONS=--max-old-space-size=1024\n      - EXECUTIONS_MODE=queue\n      - QUEUE_BULL_REDIS_HOST=redis\n      - QUEUE_BULL_REDIS_PORT=6379\n      - N8N_DISABLE_UI=true\n    depends_on:\n      - redis\n    ports:\n      - \"5679:5678\"\n```\n\nConfigurez ensuite votre reverse proxy pour router `\u002Fwebhook\u002F` vers le port 5679 et le reste vers le port 5678 du main process. Le mode webhook est disponible depuis n8n 1.0.",{"title":73,"body":74},"Activer le garbage collector explicite pour les workflows lourds","Pour les workflows qui traitent des fichiers volumineux ou des boucles longues, vous pouvez aider V8 à libérer la mémoire plus agressivement :\n\n```bash\nNODE_OPTIONS=\"--max-old-space-size=4096 --expose-gc\"\n```\n\nCette option expose `global.gc()` — n8n peut l'appeler entre les étapes d'un workflow. À combiner avec le paramètre `EXECUTIONS_DATA_SAVE_ON_SUCCESS=none` si vous n'avez pas besoin de l'historique d'exécution : les données d'exécution conservées en mémoire représentent souvent 30 à 50 % du heap.",{"title":76,"body":77},"Surveiller le heap après correction","Installez un endpoint de métriques n8n pour observer l'évolution du heap sans avoir à intervenir à la main :\n\n```bash\nN8N_METRICS=true\nN8N_METRICS_PREFIX=n8n_\n```\n\nL'endpoint `\u002Fmetrics` (port 5678) expose alors `nodejs_heap_size_used_bytes` et `nodejs_heap_size_total_bytes`, compatibles Prometheus. Un dashboard Grafana basique sur ces deux métriques vous alertera bien avant le prochain crash.",{"type":79,"title":80,"body":81},"tip","Limiter la taille des payloads d'exécution","Le paramètre `EXECUTIONS_DATA_MAX_SIZE` (en bytes, défaut : aucune limite) coupe une exécution avant qu'elle ne puisse faire déborder le heap. Valeur recommandée pour les instances généralistes : `16777216` (16 Mo). Un workflow qui dépasse ce seuil échoue proprement au lieu de tuer le processus entier. Combinez-le avec `EXECUTIONS_DATA_PRUNE=true` et `EXECUTIONS_DATA_MAX_AGE=168` (une semaine) pour éviter l'accumulation des données d'exécution passées en base.",{"type":37,"title":83,"body":84},"Configuration post-correction : variables d'environnement utiles","Une fois l'OOM résolu, ces variables consolidaent la stabilité de l'instance :\n\n- `N8N_DEFAULT_BINARY_DATA_MODE=filesystem` — stocke les fichiers binaires sur disque plutôt qu'en mémoire ; indispensable pour les workflows qui manipulent des fichiers CSV ou PDF volumineux\n- `OFFLOAD_MANUAL_EXECUTIONS_TO_WORKERS=true` — les exécutions manuelles (déclenchées depuis l'éditeur) passent aussi par les workers, évitant de peser sur le heap du main process pendant les tests\n- `N8N_RUNNERS_ENABLED=true` et `N8N_RUNNERS_MAX_CONCURRENCY=5` — active le task runner expérimental (n8n 1.10+) qui isole chaque exécution dans un sous-processus, empêchant un seul workflow de consommer tout le heap disponible\n- `DB_POSTGRESDB_*` — migrer de SQLite à PostgreSQL sur les instances à fort volume : SQLite sérialise toutes les lectures\u002Fécritures et peut bloquer les workers, amplifiant la pression mémoire",{"type":37,"title":86,"body":87},"Dépannage — erreurs réelles et leurs causes","**`FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory`**\nCause directe : le heap V8 a atteint son plafond. Solution : ajouter `NODE_OPTIONS=--max-old-space-size=\u003Cn>` dans les variables d'environnement du conteneur, avec une valeur calibrée sur la RAM disponible (voir étape 2).\n\n**`Killed` dans les logs, sans message Node**\nCause : l'OOM killer du noyau Linux a terminé le processus avant que V8 ne puisse émettre son message. Survient quand la mémoire physique est effectivement épuisée — différent du crash V8 pur. Vérifier avec `dmesg | grep -i oom`. Réduire `--max-old-space-size` ou ajouter de la RAM, et activer `EXECUTIONS_DATA_SAVE_ON_SUCCESS=none` pour alléger l'empreinte.\n\n**Les workers ne consomment pas les jobs malgré `EXECUTIONS_MODE=queue`**\nCause fréquente : `DB_TYPE` et les variables de base de données ne sont pas transmises aux workers. Chaque service du Compose doit avoir ses propres variables de connexion — le worker n'hérite pas de la configuration du main process. Vérifiez avec `docker exec n8n-worker env | grep DB_`.\n\n**Le heap grimpe après chaque run et ne redescend pas**\nCause : une closure retient une référence à un grand tableau entre les exécutions. Activer `--expose-gc` dans `NODE_OPTIONS` et ajouter `EXECUTIONS_DATA_SAVE_ON_SUCCESS=none` pour éviter que les données d'exécution ne s'accumulent. Si le comportement persiste, passer en mode task runner (`N8N_RUNNERS_ENABLED=true`) qui isole chaque workflow.\n\n**`Error: Redis connection failed` après le passage en mode queue**\nCause : `QUEUE_BULL_REDIS_HOST` pointe vers `localhost` au lieu du nom de service Docker. Dans un réseau Compose, le main process et les workers atteignent Redis par son nom de service (`redis` dans l'exemple ci-dessus), pas par `127.0.0.1`.",{"type":37,"title":89,"body":90},"Ressources et prochaines étapes","La documentation officielle n8n sur les erreurs mémoire (\u003Ca href=\"https:\u002F\u002Fdocs.n8n.io\u002Fhosting\u002Fscaling\u002Fmemory-errors\u002F\">docs.n8n.io\u002Fhosting\u002Fscaling\u002Fmemory-errors\u003C\u002Fa>) détaille les valeurs recommandées de `--max-old-space-size` selon la RAM disponible et liste les paramètres de scaling. L'issue GitHub \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fn8n-io\u002Fn8n\u002Fissues\u002F17461\">n8n-io\u002Fn8n#17461\u003C\u002Fa> (OOM en production, ouverte en mars 2026, 80+ commentaires) documente des cas réels — notamment la corrélation entre workflows de traitement CSV et crash heap — et les configurations qui ont stabilisé des instances similaires à la vôtre.\n\nSi vous gérez plusieurs instances n8n pour des clients différents, la séparation main\u002Fworker décrite ici est aussi la base d'une architecture multi-tenant : chaque client peut avoir son propre pool de workers avec un plafond V8 indépendant, sans qu'un workflow lourd d'un compte n'impacte les autres.","Déployez n8n sur un VPS dédié","Un VPS avec accès root, IPv4 dédiée et choix d'OS pour héberger votre instance n8n en mode queue, sans restriction de workflows ni de webhooks.","Voir les templates VPS","\u002Fmarketplace\u002Fautomatisation\u002Fn8n",[96,113,134],{"id":97,"slug":98,"slugs":99,"title":103,"excerpt":104,"readTime":105,"views":23,"isPinned":19,"publishedAt":106,"updatedAt":107,"category":108,"categories":109,"featuredImage":29,"bgImage":30,"posterImage":111,"relatedSolution":112},3,"installer-n8n-vps",{"fr":98,"en":100,"ar":101,"es":102},"install-n8n-on-vps-with-docker-complete-2026-guide","تثبيت-n8n-على-vps-مع-docker-دليل-شامل-2026","instalar-n8n-en-vps-con-docker","Installer n8n sur VPS avec Docker : guide complet 2026","Déployez n8n sur VPS avec Docker, reverse proxy et HTTPS. Crash V8, 502 nginx, migration npm vers Docker et sécurisation des exécutions persistées (advisory août 2026).",16,"2026-06-05T00:00:00+00:00","2026-09-23T15:23:17+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":25},[110],{"id":23,"name":24,"slug":25,"color":26,"icon":25},"\u002Fblog\u002Fcovers\u002Finstaller-n8n-vps-poster.svg",{"categorySlug":25,"appSlug":33},{"id":114,"slug":115,"slugs":116,"title":120,"excerpt":121,"readTime":122,"views":18,"isPinned":19,"publishedAt":123,"updatedAt":124,"category":125,"categories":130,"featuredImage":29,"bgImage":30,"posterImage":132,"relatedSolution":133},410,"n8n-sustainable-use-licence-fair-code-agences",{"fr":115,"en":117,"ar":118,"es":119},"n8n-sustainable-use-license-guide-agencies","n8n-ترخيص-استخدام-مستدام-دليل-وكالات","n8n-licencia-uso-sostenible-guia-agencias","n8n Sustainable Use License : guide pour les agences","La SUL n8n autorise l'usage interne mais interdit de fournir n8n comme service à vos clients sans accord commercial. Ce que cela change pour les agences.",8,"2026-10-04T00:00:00+00:00","2026-10-05T14:05:27+00:00",{"id":126,"name":127,"slug":128,"color":129,"icon":128},10,"Conformité & réglementation","conformite","bg-amber-500\u002F10 text-amber-400",[131],{"id":126,"name":127,"slug":128,"color":129,"icon":128},"\u002Fblog\u002Fcovers\u002Fn8n-sustainable-use-licence-fair-code-agences-poster.svg",{"categorySlug":25,"appSlug":33},{"id":135,"slug":136,"slugs":137,"title":141,"excerpt":142,"readTime":17,"views":18,"isPinned":19,"publishedAt":143,"updatedAt":21,"category":144,"categories":145,"featuredImage":29,"bgImage":30,"posterImage":147,"relatedSolution":148},418,"activepieces-alternative-n8n-self-hosted-mcp-agents-ia",{"fr":136,"en":138,"ar":139,"es":140},"activepieces-the-mit-n8n-alternative-for-agencies-and-ai-agents","activepieces-بديل-n8n-mit-للوكالات-وعملاء-الذكاء-الاصطناعي","activepieces-la-alternativa-mit-a-n8n-para-agencias-y-agentes-ia","Activepieces : l'alternative n8n MIT pour agences et agents IA","n8n restreint l'usage commercial avec sa Sustainable Use License. Activepieces est MIT, self-hosted, et connecte vos agents Claude ou GPT-4o via MCP natif.","2026-10-06T00:00:00+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":25},[146],{"id":23,"name":24,"slug":25,"color":26,"icon":25},"\u002Fblog\u002Fcovers\u002Factivepieces-alternative-n8n-self-hosted-mcp-agents-ia-poster.svg",{"categorySlug":25,"appSlug":149},"activepieces",1791414770364]