[{"data":1,"prerenderedAt":151},["ShallowReactive",2],{"seo-verification":3,"blog-n8n-errores-memoria-oom-correccion-vps-es":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-n8n-errores-memoria-oom-correccion-vps-es",{"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":35,"sections":36,"ctaTitle":92,"ctaBody":93,"ctaButton":94,"ctaUrl":95,"relatedPosts":96},420,"n8n-errores-memoria-oom-correccion-vps",{"fr":12,"en":13,"ar":14,"es":10},"n8n-erreurs-memoire-oom-production-vps","n8n-out-of-memory-fix-vps-production","n8n-إصلاح-أخطاء-الذاكرة-heap-vps","n8n out of memory: diagnóstico y corrección en VPS","FATAL ERROR heap out of memory en n8n: identificar la causa (límite V8, modo webhook, workers no separados) y corregir sin migrar.",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,"Automatización","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":33,"appSlug":34},"automatizacion","n8n","El mensaje `FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory` detiene n8n sin previo aviso. Muchos equipos añaden más RAM y no ven cambio alguno — porque el límite del heap V8 es independiente de la memoria física del servidor y debe configurarse explícitamente. Este artículo cubre las tres causas reales del crash OOM, la variable de entorno que corrige cada una, y la separación worker\u002Fwebhook que evita recaídas.",[37,41,51,54,79,83,86,89],{"type":38,"title":39,"body":40},"h2","Por qué n8n falla por memoria, y no por la razón que crees","V8, el motor JavaScript integrado en Node.js, tiene un límite de heap independiente de la RAM física. Por defecto oscila entre 512 MB y 1,5 GB según la versión de Node y la plataforma — en un VPS de 4 GB u 8 GB, la máquina no se queda sin memoria, pero el proceso V8 sí. Añadir más RAM al servidor no cambia nada sin `NODE_OPTIONS=--max-old-space-size`.\n\nSegunda causa frecuente: en modo `main` (el predeterminado), n8n ejecuta los workflows en el mismo proceso que sirve los webhooks y la API. Un workflow pesado en datos — transformación CSV, agregación de miles de filas, llamadas GPT en bucle — monopoliza el heap durante su ejecución. Si varios se acumulan, se alcanza el límite V8 y el proceso se mata.\n\nTercera causa, más sutil: los jobs se acumulan en memoria cuando el modo queue está activado sin workers dedicados. La queue (Redis o BullMQ) descarga las ejecuciones del proceso principal, pero si ningún worker consume realmente los jobs, se acumulan, los callbacks permanecen en espera y el heap crece.",{"type":42,"title":43,"items":44},"ul","Señales que confirman un crash OOM en n8n",[45,46,47,48,49,50],"**Mensaje de salida exacto**: `FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory` en los logs del contenedor (`docker logs n8n`)","**Crash silencioso bajo systemd**: el servicio se reinicia automáticamente sin dejar rastro si `Restart=always` está activo — comprobar con `journalctl -u n8n --since \"1 hour ago\"`","**OOM kill del kernel**: `dmesg | grep -i oom` muestra `Killed process \u003Cpid> (node)` antes del reinicio, independientemente de Node","**Correlación con un workflow pesado**: el crash ocurre siempre durante ejecuciones de tipo «procesamiento de archivo» o «bucle sobre miles de elementos»","**Heap estable durante horas y luego pico repentino**: un workflow lanzado periódicamente acumula closures no liberadas — el heap sube en cada ejecución y no baja completamente","**Carga de memoria normal en htop**: la RAM del sistema no está saturada en el momento del crash, lo que confirma que el problema es V8, no la máquina",{"type":38,"title":52,"body":53},"Requisitos previos antes de intervenir","Estos pasos asumen que n8n ya está corriendo en tu VPS mediante Docker Compose. Si no es así, el artículo `installer-n8n-vps` cubre el despliegue completo desde cero — vuelve aquí una vez la instancia esté en marcha.\n\nLo que necesitas para aplicar las correcciones:\n\n- **Acceso SSH root** al VPS y fichero `docker-compose.yml` editable\n- **Memoria disponible**: un límite V8 de 4096 MB (`--max-old-space-size=4096`) requiere al menos 6 GB de RAM en el VPS para dejar margen al sistema operativo, workers y Redis\n- **Redis** ya desplegado si cambias al modo queue — `redis:7-alpine` es suficiente para uso en un solo VPS\n- **Versión n8n** 1.0 o superior: la separación main\u002Fworker está disponible desde la versión 0.214 pero solo es estable en producción a partir de 1.0\n- **Copia de seguridad** de la base de datos antes de cualquier modificación del Compose — las tablas de credentials y ejecuciones no forman parte de la imagen Docker",{"type":55,"title":56,"steps":57},"steps","Corregir el OOM: del diagnóstico a la configuración estable",[58,61,64,67,70,73,76],{"title":59,"body":60},"Confirmar la causa en los logs","Lee las últimas 200 líneas del contenedor en el momento del crash:\n\n```bash\ndocker logs n8n --tail 200 2>&1 | grep -E \"FATAL|heap|OOM|Killed\"\n```\n\nSi ves `FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory`, es un crash V8. Si ves `Killed` solo sin mensaje Node, es el OOM killer del kernel — ambos pueden coexistir en el mismo incidente.",{"title":62,"body":63},"Establecer el límite V8 mediante NODE_OPTIONS","En tu `docker-compose.yml`, añade la variable de entorno `NODE_OPTIONS` al servicio n8n. Valor recomendado según la RAM del VPS:\n\n- VPS **4 GB**: `--max-old-space-size=2048`\n- VPS **8 GB**: `--max-old-space-size=4096`\n- VPS **16 GB**: `--max-old-space-size=8192`\n\nRegla: reserva aproximadamente la mitad de la RAM disponible tras el sistema operativo y servicios auxiliares (Redis, proxy). No superar el 70% de la RAM total.\n\n```bash\nservices:\n  n8n:\n    image: n8nio\u002Fn8n:latest\n    environment:\n      - NODE_OPTIONS=--max-old-space-size=4096\n      # ... otras variables\n```",{"title":65,"body":66},"Verificar que el valor se lee correctamente","Tras `docker compose up -d`, verifica que Node lee el límite:\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\nEl valor mostrado debe aproximarse a tu `--max-old-space-size`. Si sigue mostrando 512 o 1500, la variable de entorno no se está pasando al proceso — verifica que `NODE_OPTIONS` está en la sección `environment:` del servicio.",{"title":68,"body":69},"Cambiar al modo queue con Redis","El modo `main` (predeterminado) ejecuta todo en un único proceso. Para instancias que gestionan más de 20 workflows simultáneos o payloads voluminosos, separa los roles:\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\nEl servicio `n8n` se convierte en el **proceso principal** (API + UI + webhooks) con un límite moderado. El servicio `n8n-worker` gestiona las ejecuciones con un límite mayor. La directiva `scale: 2` lanza dos workers — ajusta según tus necesidades.",{"title":71,"body":72},"Separar el proceso webhook si el tráfico lo requiere","En instancias que reciben muchos webhooks en paralelo, el proceso principal puede saturarse incluso sin ejecutar workflows. n8n ofrece un modo webhook dedicado:\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\nConfigura tu reverse proxy para enrutar `\u002Fwebhook\u002F` al puerto 5679 y el resto al puerto 5678 del proceso principal. El modo webhook está disponible desde n8n 1.0.",{"title":74,"body":75},"Activar el garbage collector explícito para workflows pesados","Para workflows que procesan archivos grandes o bucles largos, puedes ayudar a V8 a liberar memoria de forma más agresiva:\n\n```bash\nNODE_OPTIONS=\"--max-old-space-size=4096 --expose-gc\"\n```\n\nEsto expone `global.gc()` — n8n puede llamarlo entre los pasos de un workflow. Combínalo con `EXECUTIONS_DATA_SAVE_ON_SUCCESS=none` si no necesitas el historial de ejecución: los datos de ejecución retenidos suelen representar el 30-50% del heap.",{"title":77,"body":78},"Monitorizar el heap tras la corrección","Activa las métricas de n8n para observar la evolución del heap sin intervención manual:\n\n```bash\nN8N_METRICS=true\nN8N_METRICS_PREFIX=n8n_\n```\n\nEl endpoint `\u002Fmetrics` (puerto 5678) expone `nodejs_heap_size_used_bytes` y `nodejs_heap_size_total_bytes`, compatibles con Prometheus. Un dashboard básico de Grafana sobre estas dos métricas te alertará mucho antes del próximo crash.",{"type":80,"title":81,"body":82},"tip","Limitar el tamaño del payload de ejecución","El parámetro `EXECUTIONS_DATA_MAX_SIZE` (en bytes, sin límite por defecto) corta una ejecución antes de que pueda desbordar el heap. Valor recomendado para instancias de propósito general: `16777216` (16 MB). Un workflow que supere este umbral falla de forma limpia en lugar de matar todo el proceso. Combínalo con `EXECUTIONS_DATA_PRUNE=true` y `EXECUTIONS_DATA_MAX_AGE=168` (una semana) para evitar la acumulación de datos de ejecuciones pasadas.",{"type":38,"title":84,"body":85},"Configuración post-corrección: variables de entorno útiles","Una vez resuelto el OOM, estas variables consolidan la estabilidad de la instancia:\n\n- `N8N_DEFAULT_BINARY_DATA_MODE=filesystem` — almacena los archivos binarios en disco en lugar de en memoria; indispensable para workflows que manipulan archivos CSV o PDF voluminosos\n- `OFFLOAD_MANUAL_EXECUTIONS_TO_WORKERS=true` — las ejecuciones manuales (lanzadas desde el editor) también pasan por los workers, evitando presión sobre el heap del proceso principal durante las pruebas\n- `N8N_RUNNERS_ENABLED=true` y `N8N_RUNNERS_MAX_CONCURRENCY=5` — activa el task runner experimental (n8n 1.10+) que aísla cada ejecución en un subproceso, impidiendo que un único workflow consuma todo el heap disponible\n- `DB_POSTGRESDB_*` — migrar de SQLite a PostgreSQL en instancias de alto volumen: SQLite serializa todas las lecturas\u002Fescrituras y puede bloquear a los workers, amplificando la presión de memoria",{"type":38,"title":87,"body":88},"Resolución de problemas — errores reales y sus causas","**`FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory`**\nCausa directa: el heap V8 ha alcanzado su límite. Solución: añadir `NODE_OPTIONS=--max-old-space-size=\u003Cn>` en las variables de entorno del contenedor, con un valor calibrado según la RAM disponible (ver paso 2).\n\n**`Killed` en los logs, sin mensaje Node**\nCausa: el OOM killer del kernel Linux ha terminado el proceso antes de que V8 pudiera emitir su mensaje. Ocurre cuando la memoria física está realmente agotada — distinto de un crash V8 puro. Verificar con `dmesg | grep -i oom`. Reducir `--max-old-space-size` o añadir RAM, y activar `EXECUTIONS_DATA_SAVE_ON_SUCCESS=none`.\n\n**Los workers no consumen jobs pese a `EXECUTIONS_MODE=queue`**\nCausa frecuente: `DB_TYPE` y las variables de base de datos no se pasan a los workers. Cada servicio del Compose debe tener sus propias variables de conexión. Verificar con `docker exec n8n-worker env | grep DB_`.\n\n**El heap sube tras cada ejecución y no baja**\nCausa: un closure retiene una referencia a un array grande entre ejecuciones. Activar `--expose-gc` en `NODE_OPTIONS` y añadir `EXECUTIONS_DATA_SAVE_ON_SUCCESS=none`. Si persiste, cambiar al modo task runner (`N8N_RUNNERS_ENABLED=true`).\n\n**`Error: Redis connection failed` tras cambiar al modo queue**\nCausa: `QUEUE_BULL_REDIS_HOST` apunta a `localhost` en lugar del nombre de servicio Docker. En una red Compose, el proceso principal y los workers alcanzan Redis por su nombre de servicio (`redis` en el ejemplo), no `127.0.0.1`.",{"type":38,"title":90,"body":91},"Recursos y próximos pasos","La documentación oficial de n8n sobre errores de memoria (\u003Ca href=\"https:\u002F\u002Fdocs.n8n.io\u002Fhosting\u002Fscaling\u002Fmemory-errors\u002F\">docs.n8n.io\u002Fhosting\u002Fscaling\u002Fmemory-errors\u003C\u002Fa>) detalla los valores recomendados de `--max-old-space-size` según la RAM disponible y lista los parámetros de escalado. El issue de GitHub \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fn8n-io\u002Fn8n\u002Fissues\u002F17461\">n8n-io\u002Fn8n#17461\u003C\u002Fa> (OOM en producción, abierto en marzo de 2026, 80+ comentarios) documenta casos reales — incluyendo la correlación entre workflows de procesamiento CSV y crash heap — y configuraciones que han estabilizado instancias similares a la tuya.\n\nSi gestionas varias instancias de n8n para distintos clientes, la separación main\u002Fworker descrita aquí es también la base de una arquitectura multi-tenant: cada cliente puede tener su propio pool de workers con un límite V8 independiente, sin que un workflow pesado de una cuenta afecte a las demás.","Despliega n8n en un VPS dedicado","Un VPS con acceso root, IPv4 dedicada y elección de SO para alojar tu instancia n8n en modo queue, sin restricciones de workflows ni webhooks.","Ver templates VPS","\u002Fmarketplace\u002Fautomatizacion\u002Fn8n",[97,114,135],{"id":98,"slug":99,"slugs":100,"title":104,"excerpt":105,"readTime":106,"views":23,"isPinned":19,"publishedAt":107,"updatedAt":108,"category":109,"categories":110,"featuredImage":29,"bgImage":30,"posterImage":112,"relatedSolution":113},3,"instalar-n8n-en-vps-con-docker",{"fr":101,"en":102,"ar":103,"es":99},"installer-n8n-vps","install-n8n-on-vps-with-docker-complete-2026-guide","تثبيت-n8n-على-vps-مع-docker-دليل-شامل-2026","Instalar n8n en un VPS con Docker: guía completa 2026","Despliegue n8n en VPS con Docker, reverse proxy y HTTPS. Crash V8, 502 nginx, migración de npm a Docker y seguridad de ejecuciones persistidas (advisory agosto 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},[111],{"id":23,"name":24,"slug":25,"color":26,"icon":25},"\u002Fblog\u002Fcovers\u002Finstaller-n8n-vps-poster.svg",{"categorySlug":33,"appSlug":34},{"id":115,"slug":116,"slugs":117,"title":121,"excerpt":122,"readTime":123,"views":18,"isPinned":19,"publishedAt":124,"updatedAt":125,"category":126,"categories":131,"featuredImage":29,"bgImage":30,"posterImage":133,"relatedSolution":134},410,"n8n-licencia-uso-sostenible-guia-agencias",{"fr":118,"en":119,"ar":120,"es":116},"n8n-sustainable-use-licence-fair-code-agences","n8n-sustainable-use-license-guide-agencies","n8n-ترخيص-استخدام-مستدام-دليل-وكالات","n8n Sustainable Use License: guía para agencias","La SUL de n8n permite el uso interno pero prohíbe ofrecer n8n como servicio a clientes sin acuerdo comercial. Lo que esto implica para las agencias.",8,"2026-10-04T00:00:00+00:00","2026-10-05T14:05:27+00:00",{"id":127,"name":128,"slug":129,"color":130,"icon":129},10,"Cumplimiento y normativa","conformite","bg-amber-500\u002F10 text-amber-400",[132],{"id":127,"name":128,"slug":129,"color":130,"icon":129},"\u002Fblog\u002Fcovers\u002Fn8n-sustainable-use-licence-fair-code-agences-poster.svg",{"categorySlug":33,"appSlug":34},{"id":136,"slug":137,"slugs":138,"title":142,"excerpt":143,"readTime":17,"views":18,"isPinned":19,"publishedAt":144,"updatedAt":21,"category":145,"categories":146,"featuredImage":29,"bgImage":30,"posterImage":148,"relatedSolution":149},418,"activepieces-la-alternativa-mit-a-n8n-para-agencias-y-agentes-ia",{"fr":139,"en":140,"ar":141,"es":137},"activepieces-alternative-n8n-self-hosted-mcp-agents-ia","activepieces-the-mit-n8n-alternative-for-agencies-and-ai-agents","activepieces-بديل-n8n-mit-للوكالات-وعملاء-الذكاء-الاصطناعي","Activepieces: la alternativa MIT a n8n para agencias y agentes IA","n8n restringe el uso comercial con su Sustainable Use License. Activepieces es MIT, self-hosted, y conecta tus agentes Claude o GPT-4o mediante MCP nativo.","2026-10-06T00:00:00+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":25},[147],{"id":23,"name":24,"slug":25,"color":26,"icon":25},"\u002Fblog\u002Fcovers\u002Factivepieces-alternative-n8n-self-hosted-mcp-agents-ia-poster.svg",{"categorySlug":33,"appSlug":150},"activepieces",1791414884664]