Requisitos de servidor para n8n: cuánta RAM, CPU y disco necesitas
La respuesta rápida
| Escenario | RAM | vCPU | Disco |
|---|---|---|---|
| Probar n8n, flujos simples, SQLite | 2 GB | 1 | 20 GB |
| Producción chica: n8n + PostgreSQL, pocos flujos concurrentes | 4 GB | 2 | 60 GB |
| Producción real: varios flujos activos, nodos de IA, archivos | 8 GB | 4 | 120 GB |
| Alto volumen: modo cola con workers | 16 GB+ | 8+ | 200 GB+ |
Si vienes por un número y nada más: 4 GB de RAM y 2 vCPU es el punto de partida sensato para algo que va a producción. Con 2 GB se arranca, pero se sufre apenas agregas PostgreSQL y un par de flujos concurrentes.
Ahora, el detalle de por qué, que es lo que te va a evitar comprar mal.
RAM: el recurso que se acaba primero
n8n corre sobre Node.js, y Node.js reserva memoria de forma generosa. Un proceso de n8n en reposo ocupa entre 300 y 500 MB. Eso es en reposo, sin ejecutar nada.
Lo que consume memoria de verdad son los datos que pasan por el flujo. n8n mantiene en memoria los ítems de cada nodo mientras la ejecución está viva. Un flujo que trae 10.000 filas de una API y las procesa nodo por nodo puede ocupar un giga sin despeinarse. Y si tienes tres de esos corriendo al mismo tiempo, ya sabes cómo termina.
Reparto aproximado en un servidor de 4 GB:
- Sistema operativo y Docker: ~500 MB
- PostgreSQL: ~300 MB
- n8n en reposo: ~400 MB
- Proxy inverso (Caddy o Nginx): ~50 MB
- Disponible para ejecuciones: ~2,7 GB
Con 2 GB, ese último número baja a unos 700 MB. Alcanza para flujos livianos y para nada más. El síntoma clásico de quedarse corto no es lentitud: es que el contenedor muere sin aviso en medio de una ejecución, porque el kernel lo mató por falta de memoria. Se ve así:
docker inspect n8n --format='{{.State.OOMKilled}}'
Si eso devuelve true, no necesitas optimizar nada: necesitas más RAM.
CPU: importa menos de lo que crees, hasta que importa
La mayoría de los flujos de n8n pasan la vida esperando. Esperan a que responda una API, a que Postgres devuelva una consulta, a que un archivo termine de subir. Eso no consume CPU.
La CPU se vuelve el cuello de botella en tres casos concretos:
- Nodos Code con lógica pesada — transformar, ordenar o cruzar miles de ítems en JavaScript.
- Procesamiento de archivos — convertir imágenes, parsear PDFs, comprimir.
- Muchas ejecuciones simultáneas — cada una compite por el mismo hilo.
Para un uso normal, 2 vCPU son suficientes. Si tus flujos hacen trabajo de cómputo real, 4.
La relación RAM:vCPU que conviene
Acá hay un detalle que se pasa por alto al comparar planes de VPS. Para n8n, la proporción sana es 1 vCPU por cada 2 GB de RAM.
Un plan de 4 vCPU con 4 GB de RAM (relación 1:1) se ve potente en la tabla comparativa, pero para n8n está mal balanceado: te vas a quedar sin memoria mucho antes de aprovechar esos cuatro núcleos. Un plan de 2 vCPU con 4 GB te va a servir mejor y probablemente cueste menos.
Al comparar proveedores, mira la RAM primero.
Disco: el problema silencioso
n8n guarda el historial completo de cada ejecución — entradas y salidas de cada nodo. Es enormemente útil para depurar y es también la razón número uno por la que a la gente se le llena el disco.
Estimación gruesa: entre 5 y 50 KB por ejecución, según cuántos datos muevas. A 10.000 ejecuciones mensuales eso son entre 50 MB y 500 MB al mes, creciendo para siempre si no haces nada.
La solución son dos variables de entorno:
EXECUTIONS_DATA_PRUNE=true
EXECUTIONS_DATA_MAX_AGE=336
336 horas son 14 días de historial. Para la mayoría es más que suficiente — si un flujo falló hace tres semanas y no te enteraste, el log no era tu problema.
30 GB de disco no son suficientes para una instancia de producción que además guarda archivos temporales, imágenes de Docker y respaldos locales. Parte en 60 GB. Y prefiere NVMe sobre SSD SATA: PostgreSQL hace muchas escrituras chicas, que es justamente donde NVMe rinde varias veces mejor.
Base de datos: la decisión que hay que tomar antes
n8n usa SQLite por defecto. Funciona, pero:
- Bloquea escrituras concurrentes, así que las ejecuciones paralelas se hacen fila.
- Respaldarla en caliente es incómodo.
- No sirve para modo cola, porque los workers necesitan una base compartida.
PostgreSQL agrega unos 300 MB de RAM y resuelve las tres cosas. Lo importante: elige antes de la primera ejecución. Migrar de SQLite a PostgreSQL después es un proyecto aparte, no un cambio de configuración.
Cuándo se pasa a modo cola
La configuración de un solo proceso aguanta bien varias decenas de ejecuciones concurrentes. Las señales de que te quedaste corto:
- Ejecuciones que quedan en estado “running” mucho más de lo normal.
- Webhooks que responden lento o con timeout.
- La interfaz se pone pesada mientras corren flujos.
El modo cola agrega Redis como intermediario y reparte el trabajo entre procesos worker separados. Se activa con EXECUTIONS_MODE=queue más la configuración de Redis, y cada worker corre en su propio contenedor.
Presupuesto de recursos para esa arquitectura:
- Proceso principal (interfaz y webhooks): 2 GB
- Redis: 512 MB
- PostgreSQL: 1 GB
- Cada worker: 1,5 a 2 GB
Con dos workers, eso son unos 8 GB. Con cuatro, 12 a 16 GB.
Nodos de IA: el caso que rompe todos los cálculos
Si tus flujos llaman a modelos de lenguaje vía API — OpenAI, Anthropic, Gemini — el consumo lo domina el tamaño de las respuestas, no el modelo. Un flujo que trae 500 respuestas largas y las procesa en memoria puede duplicar tu uso de RAM respecto de lo que estimaste.
Si además usas nodos de base de datos vectorial o embeddings locales, la cuenta cambia por completo: ahí ya no estás dimensionando para n8n, estás dimensionando para el modelo. Parte en 8 GB y mide.
Checklist antes de contratar
- ¿4 GB de RAM o más? Bajo eso, solo para probar.
- ¿La relación es cercana a 1 vCPU por 2 GB de RAM?
- ¿60 GB de disco o más, y es NVMe?
- ¿Puedes escalar RAM después sin reinstalar todo?
- ¿Tienes acceso root? n8n con Docker lo necesita — un hosting compartido con cPanel no sirve.
- ¿Puedes apuntar un subdominio con HTTPS? Sin eso no hay webhooks.
- ¿Dónde está físicamente el servidor? Importa para latencia y para dónde viven tus datos.
Recomendación por caso
| Tu situación | Configuración |
|---|---|
| Estoy aprendiendo n8n | 2 GB / 1 vCPU / 20 GB |
| Automatizo mi propia pyme | 4 GB / 2 vCPU / 60 GB NVMe |
| Agencia con flujos de varios clientes | 8 GB / 4 vCPU / 120 GB NVMe |
| Flujos con IA o archivos pesados | 8 GB mínimo, medir y ajustar |
| Más de 50.000 ejecuciones al mes | Modo cola, 16 GB+ |
Siguiente paso
Si ya sabes qué tamaño necesitas, la guía de instalación completa está acá: cómo instalar n8n en un VPS. Si todavía dudas entre autohospedar o pagar la nube, revisa la comparativa de costos en pesos chilenos.
Y si prefieres saltarte la instalación, nuestros VPS para n8n llegan con n8n, PostgreSQL y HTTPS ya configurados, con infraestructura en Chile y soporte en español.





