tva
← Artículos

n8n 2.x autoalojado: diagnostique los límites de los datos de ejecución y amplíe el payload con seguridad

Un artículo de seguimiento actualizado y orientado a producción que convierte la documentación de los proveedores en controles operativos, decisiones de migración y criterios de despliegue verificables.

Qué ha cambiado en 2026

Retomamos este tema porque los límites operativos han cambiado. Los principios duraderos siguen siendo útiles, pero las versiones actuales hacen que algunos atajos anteriores sean incompletos o arriesgados. Este artículo de seguimiento parte de la documentación oficial disponible el 14 de julio de 2026, separa los hechos de las decisiones locales y trata cada cambio de configuración como una intervención controlada en producción.

Fuentes primarias actuales

Cómo utilizar esta actualización

Consulte primero las fuentes primarias, registre las versiones realmente desplegadas y defina el resultado observable antes de modificar un ajuste. Pruebe la intervención reversible más pequeña en un entorno representativo. Un comando ejecutado con éxito no es un criterio de aceptación: sí lo son la salud del servicio, la integridad de los datos, la latencia, los límites de seguridad y el tiempo de reversión. La secuencia de diagnóstico del artículo anterior que aún resulta útil se conserva como base operativa; los ejemplos dependientes de una versión deben contrastarse con la documentación vigente.

Antes del despliegue guardamos el diff de configuración, una copia de seguridad o instantánea cuya restauración ya se haya probado y los comandos necesarios para revertir la intervención. Una persona observa la primera ventana de producción y otra autoriza la escalada si los indicadores acordados avanzan en la dirección equivocada. Las alertas deben describir el riesgo visible para el usuario, no solo el componente que las emite. Durante el periodo de comprobación comparamos las tasas de error, la profundidad de las colas, la saturación de recursos, la latencia de procesamiento y la completitud de los datos con la línea de base. Revisamos tanto promedios como valores extremos, pues un promedio estable puede ocultar fallos que afectan a una parte pequeña pero importante del trabajo. El cambio solo se cierra cuando terminan los trabajos diferidos, reintentos, tareas programadas y exportaciones posteriores. Toda acción manual de recuperación se documenta; si no figura en el manual operativo, este aún no está completo. Esta disciplina de despliegue genera evidencia reutilizable en la siguiente actualización y evita que el equipo tenga que volver a identificar las mismas dependencias.

Base operativa

El autoalojamiento de n8n le brinda ejecuciones de flujos de trabajo ilimitadas y control total, pero los flujos de trabajo complejos con grandes conjuntos de datos pueden desencadenar errores frustrantes que debe resolver en la configuración de su propio servidor. Si está viendo "Please execute the whole workflow, rather than just the node. (Existing execution data is too large.)" al intentar probar nodos individuales, ha alcanzado el límite de tamaño de carga útil. Le mostraremos cómo identificar, solucionar y optimizar esta limitación para instalaciones de n8n listas para producción.

El problema: cuando las pruebas de flujos de trabajo fallan

Ha configurado correctamente su instancia de n8n y sus webhooks funcionan de forma fiable, pero ahora está construyendo flujos de trabajo más sofisticados que procesan archivos, respuestas grandes de API o conjuntos de datos. Todo funciona bien al ejecutar el flujo de trabajo completo, pero en el momento en que intenta probar un solo nodo o realizar ejecuciones parciales, n8n lanza el temido mensaje de error.

Esto sucede porque n8n tiene un límite predeterminado de 16 MB para los datos de ejecución parcial que funciona bien para flujos de trabajo simples pero se convierte en un cuello de botella tan pronto como comienza a procesar volúmenes de datos del mundo real.

Lo que solucionará

Al finalizar esta guía, tendrá:

  • Límite de tamaño de carga útil aumentado de 16 MB a 256 MB o valor personalizado
  • Ejecuciones parciales funcionales para flujos de trabajo complejos con grandes conjuntos de datos
  • Asignación adecuada de recursos considerando los límites de RAM de su servidor
  • Configuración de monitoreo para seguir la evolución del uso de memoria
  • Configuración lista para producción que maneja flujos de trabajo de procesamiento de archivos
  • Procedimientos de copia de seguridad y reversión para cambios de configuración

Requisitos previos

  • Instalación funcional de n8n (preferiblemente de nuestra guía de configuración en Hetzner)
  • n8n ejecutándose en contenedores Docker
  • Acceso SSH a su servidor
  • Comprensión básica de las variables de entorno de Docker Compose
  • Al menos 3 GB de RAM disponible (recomendado para límite de carga útil de 256 MB)

Comprendiendo la causa raíz

Por qué n8n autoalojado tiene límites de carga útil

Cuando realiza ejecuciones parciales (probando nodos individuales), n8n necesita serializar y transmitir el estado del flujo de trabajo y los datos al backend. Esto incluye:

  • Todos los datos de entrada de nodos anteriores
  • Lógica del flujo de trabajo y configuraciones de nodos
  • Contexto de ejecución y variables
  • Datos binarios y contenido de archivos

El valor predeterminado N8N_PAYLOAD_SIZE_MAX=16 (16 MiB; el valor se expresa en MiB) fue diseñado para respuestas típicas de API y procesamiento simple de datos. Sin embargo, los flujos de trabajo modernos frecuentemente manejan:

Escenarios comunes que exceden 16 MB:

  • Carga y procesamiento de archivos (PDF, imágenes, hojas de cálculo)
  • Respuestas grandes de API de fuentes de datos
  • Transformaciones masivas de datos
  • Flujos de trabajo de múltiples pasos con datos acumulados

Qué sucede después de la solución:

  • Las ejecuciones parciales funcionan con grandes conjuntos de datos
  • Los flujos de trabajo de procesamiento de archivos se pueden probar
  • Las transformaciones complejas de datos se pueden depurar nodo por nodo

La configuración faltante

La solución es la variable de entorno N8N_PAYLOAD_SIZE_MAX, que establece el tamaño máximo de la carga útil de las solicitudes en MiB, incluidos los datos que el editor envía para las ejecuciones parciales. Cuando una solicitud supera ese límite, n8n responde con HTTP 413 y el editor muestra este error. En n8n Cloud, n8n administra esta configuración por usted; las instancias autoalojadas usan el valor conservador predeterminado de 16 MiB.

Paso 1: diagnostique su configuración actual

Verifique los recursos de su servidor

Antes de aumentar los límites de carga útil, verifique que su servidor pueda manejar asignaciones de memoria más grandes:

Requisitos de memoria:

  • Límite de carga útil de 64 MB: mínimo 1 GB de RAM disponible
  • Límite de carga útil de 128 MB: mínimo 2 GB de RAM disponible
  • Límite de carga útil de 256 MB: mínimo 3 GB de RAM disponible

Identifique el límite actual

Verifique si N8N_PAYLOAD_SIZE_MAX está definido en su archivo de Compose. Si no lo está, n8n usa el valor predeterminado de 16 MiB.

Pruebe la condición de error

Cree un flujo de trabajo de prueba para reproducir el problema:

  • Abra su interfaz de n8n
  • Cree un flujo de trabajo con un gran conjunto de datos (por ejemplo, una solicitud HTTP a una API que devuelve >16 MB)
  • Intente ejecutar solo un nodo posterior
  • Confirme que aparece el error "Existing execution data is too large"

Paso 2: solucione el problema principal: aumente el tamaño de carga útil

Para una instancia única de n8n

Si tiene una sola instalación de n8n, primero haga una copia de seguridad de docker-compose.yml y luego edítelo.

Agregue la variable de entorno N8N_PAYLOAD_SIZE_MAX a su configuración existente. El valor se expresa en MiB, por lo que N8N_PAYLOAD_SIZE_MAX=256 establece un límite de 256 MiB.

Para múltiples instancias de n8n

Si está ejecutando múltiples instancias de n8n, actualice cada una. El límite se aplica por instancia.

Reinicie sus contenedores

Aplique los cambios recreando los contenedores con docker compose down y docker compose up -d; docker compose restart no aplica los valores de entorno modificados.

Paso 3: verifique la solución

Revise los registros del contenedor

Verifique que los contenedores se iniciaron correctamente revisando sus registros en busca de errores.

Pruebe el aumento del tamaño de carga útil

Regrese a su flujo de trabajo de prueba que estaba fallando:

  • Abra el flujo de trabajo con el gran conjunto de datos
  • Intente ejecutar un solo nodo posterior
  • Verifique que el error "Existing execution data is too large" haya desaparecido
  • Confirme que las ejecuciones parciales ahora funcionan correctamente

Monitoree el uso de memoria

Vigile los recursos del sistema después del cambio, por ejemplo con free -h y docker stats.

Paso 4: optimice para su servidor

Tamaños de carga útil recomendados por RAM del servidor

Elija el tamaño de carga útil adecuado para su hardware. Como punto de partida: 64 MiB para servidores con 2 GB de RAM o menos, 128 MiB para 4 GB, 256 MiB para 8 GB y 512 MiB para 16 GB o más.

Cálculo del uso de memoria

Estime sus requisitos de memoria: mantenga el límite de carga útil por debajo del 20 % de la RAM disponible y observe el uso real de memoria durante las ejecuciones de flujos de trabajo grandes.

Resolución de problemas comunes

Problema: el contenedor no inicia después del cambio de configuración

Síntomas:

  • El contenedor se cierra inmediatamente después del inicio
  • Estado "OOMKilled" en Docker
  • El servidor deja de responder

Solución: Revise los registros del contenedor para conocer el motivo de la salida. Si el contenedor se quedó sin memoria, reduzca N8N_PAYLOAD_SIZE_MAX (por ejemplo, de 256 a 64) e inícielo de nuevo.

Problema: aún recibe errores de tamaño de carga útil

Síntomas:

  • El error persiste después del cambio de configuración
  • La variable de entorno no parece tener efecto

Solución: Confirme el valor dentro del contenedor con docker exec y env. Si falta, recree el contenedor con docker compose up -d --force-recreate.

Problema: degradación del rendimiento del servidor

Síntomas:

  • Tiempos de respuesta más lentos
  • Alto uso de memoria
  • Aumento del uso del archivo de intercambio

Solución: Revise el uso de memoria, la E/S de disco y el espacio de intercambio. Si es necesario, reduzca N8N_PAYLOAD_SIZE_MAX (por ejemplo, de 256 a 128) y recree el contenedor.

Configuración avanzada

Instancias separadas para diferentes tamaños de carga útil

El límite se aplica por instancia de n8n, no por flujo de trabajo. Los usuarios avanzados pueden considerar instancias separadas con distintos límites, por ejemplo una instancia de alta capacidad para procesar archivos y una estándar para los flujos de trabajo habituales.

Límites de recursos del contenedor

Establezca límites de memoria explícitos en la sección deploy.resources de Compose para prevenir la sobrecarga del sistema. Una reserva de memoria es un límite flexible, no una garantía.

Monitoreo del uso de carga útil

n8n no informa directamente del tamaño de la carga útil, por lo que conviene generar alertas sobre el uso de memoria del contenedor, por ejemplo con un script que lea docker stats.

Consideraciones de seguridad

Protección contra DoS basada en recursos

Los límites grandes de carga útil pueden ser explotados. Limite el tamaño de las solicitudes en el proxy inverso y mantenga ese límite igual o superior a N8N_PAYLOAD_SIZE_MAX para que las solicitudes legítimas no se rechacen con HTTP 413.

Límites específicos por flujo de trabajo

Considere restricciones basadas en flujos de trabajo, como registrar qué flujos de trabajo producen ejecuciones grandes.

Optimización del rendimiento

Manejo de datos binarios

Para los flujos de trabajo que procesan archivos, almacene los datos binarios en disco con N8N_DEFAULT_BINARY_DATA_MODE=filesystem en lugar de en memoria. n8n no admite el modo filesystem con el modo de cola; para este último, su documentación recomienda el modo de base de datos.

Optimización de la base de datos

Las cargas útiles grandes pueden afectar al rendimiento de la base de datos. Monitoree su crecimiento y depure las ejecuciones antiguas con mayor frecuencia mediante EXECUTIONS_DATA_MAX_AGE y EXECUTIONS_DATA_PRUNE_MAX_COUNT.

Copia de seguridad y recuperación

Estrategia de copia de seguridad de configuración

Siempre haga una copia de seguridad de docker-compose.yml antes de realizar cambios, con una marca de tiempo en el nombre del archivo.

Procedimiento de reversión rápida

Si necesita revertir los cambios, restaure un archivo de copia de seguridad específico y luego ejecute docker compose down y docker compose up -d.

Impacto en costos y rendimiento

Análisis de costos de memoria

Los límites de carga útil aumentados afectan los costos del servidor, porque los límites más altos requieren más RAM.

Beneficios de rendimiento

Los límites de carga útil más altos permiten:

  • Procesamiento de archivos: manejar documentos, imágenes, videos
  • Integración de datos: procesar respuestas grandes de API
  • Operaciones masivas: transformar conjuntos de datos de manera eficiente
  • Depuración: probar flujos de trabajo complejos nodo por nodo

Conclusión

Aumentar N8N_PAYLOAD_SIZE_MAX del valor predeterminado de 16 MB a un valor adecuado para su servidor habilita potentes capacidades de flujo de trabajo que eran previamente imposibles con ejecuciones parciales. El límite de 256 MB que configuramos proporciona una excelente cobertura para la mayoría de los escenarios del mundo real mientras mantiene la estabilidad del servidor.

Beneficios clave de esta configuración

  • Productividad: depure flujos de trabajo complejos nodo por nodo con muchas menos restricciones de tamaño
  • Capacidad: procese archivos y grandes conjuntos de datos de manera eficiente
  • Rentable: procese conjuntos de datos más grandes en un servidor autoalojado de recursos modestos
  • Fiable: configuración probada en producción con gestión adecuada de recursos
  • Escalable: ajuste fácilmente los límites a medida que sus flujos de trabajo crecen en complejidad

Esta configuración se basa en nuestra guía original de configuración de n8n y la guía de resolución de problemas de webhooks para crear una plataforma de automatización completa y lista para producción, capaz de manejar flujos de trabajo de procesamiento de datos de nivel empresarial.

Para requisitos de carga útil de alto volumen o especializados, considere consultar con expertos en automatización para optimizar su caso de uso específico y asegurar una asignación óptima de recursos del servidor.

De la configuración a una decisión operativa

La cuestión práctica no es si una plataforma se puede configurar. Es si el equipo puede explicar quién es responsable, detectar desviaciones, recuperar el servicio sin improvisar y demostrar que el cambio mejoró el resultado previsto. Por eso asociamos la configuración con un responsable, una línea de base, una vía de reversión y un periodo de verificación del resultado registrado. Así, una corrección puntual se convierte en una capacidad operativa. El registro de producción debe incluir el motivo del cambio, la evidencia revisada, el alcance exacto y la persona autorizada para detenerlo o revertirlo. Después del despliegue, compare los indicadores acordados con la línea de base y guarde el resultado junto con el registro del cambio. Si la mejora prevista no se produce, la reversión es un resultado válido, no un fracaso. Esta disciplina importa más que cualquier valor de configuración individual. El mismo registro ofrece al siguiente operador un punto de partida fiable y convierte la optimización posterior en una decisión basada en mediciones, no en otra ronda de conjeturas.

Artículos relacionados

Artículos relacionados

Guía completa de solución de problemas de n8n autoalojado 2025: tamaño de los datos de ejecución y webhooks con Traefik

Cómo resolver el error «Existing execution data is too large» de n8n: solución completa para instancias autoalojadas

Resolver problemas de webhooks en n8n: guía completa para instancias autoalojadas