¿Cuánta RAM necesita n8n? Dimensiona tu VPS sin pasarte (2026)

La respuesta corta: 2 GB para empezar, 4-6 GB para producción. La respuesta útil depende de qué hacen tus workflows — y de dos o tres trampas de memoria que n8n trae de serie y que explican el 90% de los "se me cae n8n aleatoriamente". Esta guía te dice qué máquina necesitas de verdad, sin venderte más servidor del que te hace falta.

Lo que consume n8n en reposo

Una instancia de n8n recién arrancada, sin workflows corriendo, consume 300-500 MB de RAM. A eso súmale el sistema operativo (~200-300 MB en un Ubuntu Server limpio) y, si sigues la instalación con Docker, un Caddy que apenas pesa. Traducción: en un VPS de 2 GB te queda aproximadamente 1 GB libre para lo que de verdad importa — las ejecuciones.

Lo que dispara el consumo por encima de esa base:

• Ejecuciones concurrentes: cada workflow en marcha suma. Diez webhooks a la vez = diez ejecuciones en memoria.
• Datos binarios: por defecto n8n carga los ficheros que mueves (PDFs, imágenes, CSVs) enteros en RAM. Es la causa nº 1 de muertes por memoria.
• Items masivos: un nodo que devuelve 50.000 filas las mantiene todas en memoria mientras el workflow avanza.
• Nodos community y Code nodes: cada dependencia extra pesa, y un bucle descuidado en un Code node puede comerse lo que le eches.

La tabla de dimensionamiento

En nuestro catálogo eso se traduce en el Pulsar Lite (2 GB, 5,99 € + IVA) para el primer escenario y el Pulsar Start (6 GB, 11,99 € + IVA) para producción — los dos con NVMe, que SQLite agradece una barbaridad. La CPU casi nunca es el cuello de botella de n8n; no pagues 8 vCPU para workflows que esperan a APIs externas el 95% del tiempo.

Síntomas de que vas corto de RAM

• Workflows que mueren a mitad sin error claro — el clásico OOM kill. Confírmalo con dmesg | grep -i oom en el VPS.
• El editor va a tirones o tarda en abrir workflows grandes.
• Reinicios espontáneos del contenedor— Docker resucita el proceso tras cada muerte y lo ves como "n8n se reinicia solo".

Antes de pagar más RAM, aplica los dos ajustes que más rinden:

# Binarios a disco en vez de a RAM (imprescindible si mueves ficheros)
N8N_DEFAULT_BINARY_DATA_MODE=filesystem

# Purga el historial de ejecuciones viejas (la DB no crece sin freno)
EXECUTIONS_DATA_PRUNE=true
EXECUTIONS_DATA_MAX_AGE=168

Y para vigilarlo, no necesitas Grafana el primer día: docker stats te dice en vivo cuánta memoria está usando cada contenedor. Si n8n vive por encima del 80% de forma sostenida, toca subir de plan.

Cuándo escalar (y cuándo no)

• No escales por un pico puntual. Un workflow mal hecho que carga un CSV de 500 MB no se arregla con RAM: se arregla troceando los datos en lotes.
• Escala cuando la concurrencia sea real: cientos de ejecuciones/hora sostenidas, varios editores a la vez o agentes AI en bucle. Ahí sí: 8 GB, Postgres y queue mode con workers.
• El disco importa más de lo que crees: SQLite + historial de ejecuciones + binarios en filesystem = mucha I/O pequeña. NVMe no es marketing aquí.

¿Todavía comparando opciones? El desglose completo de costes está en precios de n8n en 2026 y el contraste con las alternativas SaaS en n8n vs Make vs Zapier.

Preguntas frecuentes