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

El autoalojamiento de n8n le brinda ejecuciones ilimitadas de flujos de trabajo y control total, pero los flujos complejos con grandes conjuntos de datos pueden generar errores frustrantes que debe corregir en la configuración de su propio servidor. Si ve «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 y resolver esta limitación, y cómo optimizar la configuración para instalaciones de n8n preparadas para producción.

El problema: cuando fallan las pruebas de flujos de trabajo

Ha configurado correctamente su instancia de n8n y ha configurado una funcionalidad de webhooks sólida, pero ahora está desarrollando flujos de trabajo más sofisticados que procesan archivos, respuestas grandes de API o conjuntos de datos. Todo funciona bien al ejecutar el flujo completo, pero cuando intenta probar un solo nodo o realizar ejecuciones parciales, n8n muestra 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 con flujos sencillos, pero se convierte en un cuello de botella al procesar volúmenes de datos reales.

Lo que solucionará

Al finalizar esta guía, tendrá:

• Un límite de tamaño de carga útil aumentado de 16 MB a 256 MB o a un 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
• Una configuración de monitoreo para seguir el uso de memoria a lo largo del tiempo
• 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 un límite de carga útil de 256 MB)

Comprender 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) se diseñó para respuestas típicas de API y procesamiento sencillo de datos. Sin embargo, los flujos de trabajo modernos suelen manejar:

Escenarios comunes que superan los 16 MB:

• Carga y procesamiento de archivos (PDF, imágenes y 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 que falta

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 envía el editor para las ejecuciones parciales. Cuando una solicitud supera el límite, n8n responde con HTTP 413 y el editor muestra este error. En n8n Cloud, n8n gestiona esta configuración por usted; las instancias autoalojadas utilizan 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:

# Check available memory
free -h

# Check current Docker container memory usage
docker stats --no-stream | grep n8n

# Check total system resources
htop

Requisitos de memoria:

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

Identifique el límite actual

Verifique si N8N_PAYLOAD_SIZE_MAX está configurado:

# Navigate to your n8n directory (adjust path as needed)
cd /opt/n8n

# Check current environment variables
cat docker-compose.yml | grep -A 30 "environment:"

# Look for payload size configuration
grep "N8N_PAYLOAD_SIZE_MAX" docker-compose.yml || echo "Not configured - using 16MB default"

Reproduzca el error

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

1. Abra su interfaz de n8n
2. Cree un flujo de trabajo con un gran conjunto de datos (por ejemplo, una solicitud HTTP a una API que devuelva >16 MB)
3. Intente ejecutar solo un nodo posterior
4. Verifique que aparezca el error «Existing execution data is too large»

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

Para una sola instancia de n8n

Si tiene una sola instalación de n8n:

cd /opt/n8n

# Create backup first
cp docker-compose.yml docker-compose.yml.backup_$(date +%Y%m%d_%H%M)

# Edit the configuration
nano docker-compose.yml

Agregue la variable de entorno N8N_PAYLOAD_SIZE_MAX a su configuración existente:

version: '3'

services:
  n8n:
    image: n8nio/n8n:latest
    restart: always
    environment:
      - N8N_HOST=n8n.yourdomain.com
      - NODE_ENV=production
      - N8N_PROTOCOL=https
      - N8N_PORT=5678
      - N8N_EDITOR_BASE_URL=https://n8n.yourdomain.com
      - N8N_EMAIL_MODE=smtp
      - N8N_SMTP_HOST=mailserver
      - N8N_SMTP_PORT=25
      - N8N_SMTP_SSL=false
      - N8N_SMTP_USER=
      - N8N_SMTP_PASS=
      - [email protected]
      - N8N_TRUST_PROXY_HEADER=true
      - N8N_RUNNERS_ENABLED=true
      - WEBHOOK_URL=https://n8n.yourdomain.com
      # ADD THIS LINE - Increases payload limit to 256MB (value in MiB)
      - N8N_PAYLOAD_SIZE_MAX=256
    volumes:
      - ./data:/home/node/.n8n
    networks:
      - proxy
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.n8n.rule=Host(`n8n.yourdomain.com`)"
      - "traefik.http.routers.n8n.entrypoints=https"
      - "traefik.http.routers.n8n.tls.certresolver=letsencrypt"
      - "traefik.http.services.n8n.loadbalancer.server.port=5678"

networks:
  proxy:
    external: true

Para varias instancias de n8n

Si está ejecutando múltiples instancias de n8n, actualice cada una:

# First instance
cd /opt/n8n
cp docker-compose.yml docker-compose.yml.backup_$(date +%Y%m%d_%H%M)
sed -i '/N8N_RUNNERS_ENABLED=true/a\      - N8N_PAYLOAD_SIZE_MAX=256' docker-compose.yml

# Second instance (adjust path as needed)
cd /opt/n8n-team2
cp docker-compose.yml docker-compose.yml.backup_$(date +%Y%m%d_%H%M)
sed -i '/N8N_RUNNERS_ENABLED=true/a\      - N8N_PAYLOAD_SIZE_MAX=256' docker-compose.yml

Reinicie sus contenedores

Aplique los cambios:

# For single instance
cd /opt/n8n
docker compose down && docker compose up -d

# For multiple instances
cd /opt/n8n
docker compose down && docker compose up -d
cd /opt/n8n-team2
docker compose down && docker compose up -d

# Verify containers are running
docker ps | grep n8n

Paso 3: verifique la solución

Revise los registros del contenedor

Verifique que los contenedores se iniciaron correctamente:

# Check main instance logs (adjust container name as needed)
docker logs n8n-n8n-1 --tail 20

# Check for any startup errors
docker logs n8n-n8n-1 | grep -i "error\|failed\|warning"

Pruebe el aumento del tamaño de carga útil

Vuelva al flujo de trabajo de prueba que fallaba:

1. Abra el flujo de trabajo con el conjunto de datos grande
2. Intente ejecutar un solo nodo posterior
3. Verifique que el error «Existing execution data is too large» haya desaparecido
4. Confirme que las ejecuciones parciales ahora funcionan correctamente

Monitoree el uso de memoria

Vigile los recursos del sistema después del cambio:

# Monitor memory usage over time
watch -n 5 'free -h && echo "--- Docker Stats ---" && docker stats --no-stream | grep n8n'

Paso 4: optimice la configuración para su servidor

Tamaños de carga útil recomendados según la RAM del servidor

Elija el tamaño de carga útil adecuado para su hardware:

# For servers with 2GB RAM or less
- N8N_PAYLOAD_SIZE_MAX=64   # 64 MiB

# For servers with 4GB RAM  
- N8N_PAYLOAD_SIZE_MAX=128  # 128 MiB

# For servers with 8GB+ RAM
- N8N_PAYLOAD_SIZE_MAX=256  # 256 MiB

# For high-performance servers with 16GB+ RAM
- N8N_PAYLOAD_SIZE_MAX=512  # 512 MiB

Cálculo del uso de memoria

Estime sus requisitos de memoria:

# Calculate safe payload size (should be <20% of available RAM)
echo "Available RAM: $(free -h | awk 'NR==2{print $7}')"
echo "Current payload limit: $(docker exec n8n-n8n-1 env | grep N8N_PAYLOAD_SIZE_MAX || echo '16 (default, MiB)')"

# Monitor actual usage during large workflow executions
docker stats n8n-n8n-1 | grep -E "MEM|n8n"

Resolución de problemas comunes

Problema: el contenedor no inicia tras cambiar la configuración

Síntomas:

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

Solución:

# Check container exit reason
docker logs n8n-n8n-1

# Reduce payload size if out of memory
cd /opt/n8n
sed -i 's/N8N_PAYLOAD_SIZE_MAX=256/N8N_PAYLOAD_SIZE_MAX=64/' docker-compose.yml
docker compose up -d

Problema: los errores de tamaño de carga útil persisten

Síntomas:

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

Solución:

# Verify environment variable is set correctly
docker exec n8n-n8n-1 env | grep N8N_PAYLOAD_SIZE_MAX

# If missing, recreate container with force
docker compose down
docker compose up -d --force-recreate

# Check if the value is being read
docker logs n8n-n8n-1 | grep -i payload

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:

# Monitor system performance
vmstat 1 5
iostat -x 1 5

# Check swap usage
swapon --show

# Reduce payload size if needed
# From 256MB to 128MB
sed -i 's/N8N_PAYLOAD_SIZE_MAX=256/N8N_PAYLOAD_SIZE_MAX=128/' docker-compose.yml
docker compose down && docker compose up -d

Configuración avanzada

Instancias separadas para distintos tamaños de carga útil

El límite se aplica por instancia de n8n, no por flujo de trabajo. Para usuarios avanzados, considere instancias separadas con distintos límites:

# High-capacity instance for file processing
n8n-files:
  image: n8nio/n8n:latest
  environment:
    - N8N_PAYLOAD_SIZE_MAX=512  # 512 MiB
    - N8N_HOST=files.yourdomain.com

# Standard instance for regular workflows  
n8n-standard:
  image: n8nio/n8n:latest
  environment:
    - N8N_PAYLOAD_SIZE_MAX=64   # 64 MiB
    - N8N_HOST=workflows.yourdomain.com

Límites de recursos del contenedor

Establezca límites de memoria explícitos para prevenir la sobrecarga del sistema:

services:
  n8n:
    image: n8nio/n8n:latest
    environment:
      - N8N_PAYLOAD_SIZE_MAX=256
    deploy:
      resources:
        limits:
          memory: 2G      # Maximum memory usage
        reservations:
          memory: 1G      # Soft reservation, not a hard guarantee
    # ... rest of configuration

Monitoreo del tamaño de las cargas útiles

n8n no informa directamente del tamaño de la carga útil, por lo que conviene crear alertas sobre el uso de memoria del contenedor. Este script supone que docker stats indica la memoria en MiB:

#!/bin/bash
# Create monitoring script: /opt/monitor-payload.sh

CONTAINER_NAME="n8n-n8n-1"
MEMORY_LIMIT_MB=1500  # Alert if memory usage exceeds this

CURRENT_MEMORY=$(docker stats --no-stream --format "{{.MemUsage}}" $CONTAINER_NAME | cut -d'/' -f1 | sed 's/MiB//')

if (( $(echo "$CURRENT_MEMORY > $MEMORY_LIMIT_MB" | bc -l) )); then
    echo "WARNING: n8n memory usage high: ${CURRENT_MEMORY}MB" | logger
    # Add notification logic (email, Slack, etc.)
fi

Consideraciones de seguridad

Protección frente a ataques DoS por agotamiento de recursos

Los límites elevados de carga útil pueden aprovecharse para atacar el sistema. Limite el tamaño de las solicitudes en el proxy inverso, pero mantenga ese límite (en bytes) igual o superior al tamaño que establece N8N_PAYLOAD_SIZE_MAX; de lo contrario, el proxy rechazará las solicitudes grandes con HTTP 413:

# Add to Traefik labels for request size limiting
labels:
  - "traefik.http.middlewares.payload-limit.buffering.maxRequestBodyBytes=268435456"  # 256MB max request, matches N8N_PAYLOAD_SIZE_MAX
  - "traefik.http.routers.n8n.middlewares=payload-limit"

Límites específicos por flujo de trabajo

Considere restricciones basadas en flujos de trabajo:

# Monitor workflows with large payloads
docker exec n8n-n8n-1 n8n execute --help

# Log large executions
(crontab -l 2>/dev/null; echo "*/10 * * * * docker logs n8n-n8n-1 | grep -i 'payload\|memory' >> /var/log/n8n-payload.log") | crontab -

Optimización del rendimiento

Gestión de datos binarios

Para flujos de trabajo de procesamiento de archivos, optimice el almacenamiento de datos binarios. Tenga en cuenta que N8N_BINARY_DATA_TTL no tiene efecto desde n8n 1.9.0; n8n elimina los datos binarios al depurar las ejecuciones:

environment:
  - N8N_PAYLOAD_SIZE_MAX=256
  - N8N_DEFAULT_BINARY_DATA_MODE=filesystem  # Store files on disk, not in memory
  - N8N_BINARY_DATA_TTL=1440                 # Clean up files after 24 hours

Optimización de la base de datos

Las cargas útiles grandes pueden afectar al rendimiento de la base de datos:

# Monitor database size growth
du -sh /opt/n8n/data/

# Clean up old executions more aggressively
# Add to docker-compose.yml environment:
# - EXECUTIONS_DATA_MAX_AGE=168  # 7 days instead of default 14
# - EXECUTIONS_DATA_PRUNE_MAX_COUNT=1000

Copias de seguridad y recuperación

Estrategia de copia de seguridad de la configuración

Siempre haga una copia de seguridad antes de realizar cambios:

#!/bin/bash
# Create backup script: /opt/backup-n8n-config.sh

BACKUP_DIR="/opt/backups/n8n-configs"
mkdir -p $BACKUP_DIR

# Backup all n8n docker-compose files
for instance in n8n n8n-team2; do
    if [ -d "/opt/$instance" ]; then
        cp "/opt/$instance/docker-compose.yml" "$BACKUP_DIR/${instance}-$(date +%Y%m%d_%H%M).yml"
    fi
done

# Delete backups older than 10 days
find $BACKUP_DIR -name "*.yml" -mtime +10 -delete

Procedimiento de reversión rápida

Si necesita revertir los cambios:

# List available backups
ls -la /opt/n8n/docker-compose.yml.backup_*

# Restore specific backup
cd /opt/n8n
cp docker-compose.yml.backup_20241206_1430 docker-compose.yml
docker compose down && docker compose up -d

Impacto en los costos y el rendimiento

Análisis de los costos de memoria

Aumentar los límites de carga útil afecta a los costos del servidor:

Server RAM Requirements:
- 16MB limit (default): 1GB RAM sufficient
- 64MB limit: 2GB RAM recommended  
- 128MB limit: 4GB RAM recommended
- 256MB limit: 8GB RAM recommended
- 512MB limit: 16GB RAM recommended

Hetzner Cloud Costs (legacy plans, deprecated by Hetzner in June 2024; check current pricing):
- CX11 (2GB RAM): €4.51/month
- CX21 (4GB RAM): €8.46/month  
- CX31 (8GB RAM): €16.07/month

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 el valor de N8N_PAYLOAD_SIZE_MAX desde los 16 MB predeterminados hasta un valor adecuado para su servidor permite realizar tareas potentes que antes no eran posibles con ejecuciones parciales. El límite de 256 MB que configuramos cubre bien la mayoría de los escenarios reales y 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: Utilice un límite de 128 MB en un servidor con 4 GB de RAM por menos de 10 EUR/mes (precio del antiguo plan Hetzner CX21 indicado arriba)
• 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.

Si necesita manejar grandes volúmenes de datos o cargas útiles especializadas, considere consultar con expertos en automatización para optimizar su caso de uso y asegurar una asignación adecuada de los recursos del servidor.

Acerca de tva

tva se encarga de la gestión integral de la infraestructura de sistemas de bases de datos, entornos en la nube y cadenas de suministro globales. Nuestro enfoque metódico combina protocolos de seguridad rigurosos con la optimización del rendimiento, mientras que los servicios de asesoría estratégica permiten coordinar con precisión las capacidades digitales y los activos físicos, manteniendo los más altos estándares de excelencia operativa y cumplimiento normativo en todos los proyectos.

Visite tva.sg para más información sobre nuestros servicios y tutoriales adicionales de automatización.