VPS para n8n: cuánta RAM necesitas y cuánto cuesta

Tamaños orientativos

Reserva espacio para sistema, Docker, proxy y base. Configura swap como margen, no sustituto.

Factores de consumo

Ejecuciones simultáneas, datos binarios, nodos Code, IA, Puppeteer, reintentos y retención de historial elevan RAM y disco. Reduce datos guardados, limpia ejecuciones y almacena binarios de forma apropiada.

Base y arquitectura

Para producción usa PostgreSQL y backups. Al crecer, el modo cola permite workers y Redis, pero añade operación. No adoptes esa arquitectura con pocos flujos: primero mide duración, concurrencia y fallos.

Cuánto cuesta

En la página de VPS Terranode los precios publicados parten de USD 2,99 para 1 GB, USD 5 para 2 GB, USD 9 para 4 GB y USD 18,50 para 8 GB al mes. Confirma precios y regiones vigentes antes de contratar.

Para una instancia pequeña de producción, 4 GB por USD 9 es un punto de partida razonable, no una garantía. Suma backups, dominio y tiempo de administración.

Instalación y seguridad

Sigue la guía instalar n8n con Docker y Nginx. Usa HTTPS, cifra secretos, limita registro, actualiza con rollback y nunca publiques directamente la base o Redis.

Por qué contar workflows no sirve para dimensionar

Un workflow inactivo no consume recursos y uno solo puede saturar el servidor. La diferencia está en lo que procesa, cuántas ejecuciones coinciden y cuánto tiempo conserva datos. Un webhook que valida un JSON pequeño puede terminar en milisegundos; un flujo que descarga un PDF, lo transforma y llama a un modelo mantiene memoria, CPU y datos binarios durante mucho más tiempo.

Inventaría disparadores, frecuencia, duración y tamaño máximo. Señala nodos Code, hojas extensas, imágenes, navegadores y ramas que multiplican elementos. Después calcula concurrencia: una ejecución cada minuto no implica una sola activa si cada una tarda cinco minutos. Los reintentos durante una caída externa también pueden acumular trabajo.

El número útil no es “tenemos 80 flujos”, sino “en el pico coinciden seis ejecuciones, dos manipulan archivos de 20 MB y la más larga dura cuatro minutos”. Con esa descripción puedes probar un plan y establecer límites.

Memoria de n8n, PostgreSQL y el sistema

n8n se ejecuta sobre Node.js y utiliza memoria para el proceso, datos de cada ejecución y editor. El VPS también aloja Docker, proxy inverso, sistema y, normalmente, PostgreSQL. Si reservas toda la RAM para el contenedor principal, la base o el kernel terminarán compitiendo durante el pico.

Con 4 GB, crea un presupuesto: una parte para sistema y Docker, otra para PostgreSQL, otra para n8n y un margen para actualizaciones y tareas. No fijes el heap de Node igual a toda la RAM. Un límite alto permite que el proceso desplace a la base; uno demasiado bajo lo cierra aunque el host tenga capacidad.

Observa los contenedores durante una carga representativa:

docker stats --no-stream
free -h
journalctl -k | grep -i -E 'out of memory|killed process'

El código de salida 137 o un reinicio sin error claro suele apuntar a memoria. Relaciona la hora con el historial de ejecuciones antes de ampliar.

Cuándo 2 GB pueden ser suficientes

Dos gigabytes sirven para aprender, validar integraciones o ejecutar pocos flujos pequeños con baja concurrencia. Mantén la instalación simple, limita retención y evita procesar archivos completos. Si la base comparte el VPS, el margen será estrecho durante actualizaciones y copias.

No uses “el contenedor arrancó” como prueba de producción. Ejecuta el flujo más pesado varias veces, abre el editor y deja correr las tareas programadas. Si aparece swap sostenida, reinicios o lentitud severa, 2 GB no ofrecen reserva.

Para un servicio interno tolerante a una interrupción, ese riesgo puede ser aceptable. Para webhooks que reciben pedidos o procesos que no pueden perderse, 4 GB suelen dar una base más prudente.

Qué cambia al pasar a 4 u 8 GB

Cuatro gigabytes permiten convivir con PostgreSQL y varias ejecuciones moderadas, siempre que controles datos y concurrencia. Es un buen punto inicial para producción pequeña porque deja espacio para sistema, proxy y una copia temporal. No garantiza cualquier nodo: un navegador o archivo grande todavía puede consumir el margen.

Ocho gigabytes tienen sentido cuando coinciden más trabajos, se transforman documentos, crece el historial o existen otros servicios. La memoria adicional puede beneficiar a la caché de PostgreSQL y reducir presión de disco. Aprovecharla exige revisar límites; si el contenedor conserva un tope antiguo, ampliar el VPS no cambia su comportamiento.

Escala después de medir el evento que falla. Si la CPU permanece al máximo, duplicar RAM no acelera un nodo de código. Si el tiempo se pierde en una API externa, la solución puede ser controlar reintentos y concurrencia.

CPU: duración y concurrencia importan más que el promedio

La mayoría de integraciones espera red y no usa CPU de forma continua. Los nodos Code, compresión, transformación de datos, cifrado y navegador sí pueden ocuparla. Un promedio diario bajo oculta cinco minutos críticos en los que todos los trabajos compiten.

Revisa carga por núcleo durante el pico y duración de ejecuciones. Más vCPU ayuda cuando existen tareas listas para correr en paralelo; no acelera una secuencia que espera a un tercero. Aumentar concurrencia sin CPU disponible alarga todos los flujos y puede crear una cola mayor.

Prueba con el volumen máximo razonable y compara percentiles de duración. El objetivo no es solo que finalicen, sino que lo hagan antes del siguiente disparo y dentro del plazo del negocio.

Datos binarios: el consumidor silencioso

Cuando un flujo descarga archivos, n8n puede mantener datos binarios mientras avanza entre nodos. Varias ejecuciones con imágenes, CSV o PDF multiplican memoria y almacenamiento temporal. Evita pasar archivos enormes por ramas innecesarias y elimina datos intermedios cuando ya no se necesitan.

Para volúmenes altos, estudia un modo de almacenamiento apropiado y entrega referencias en lugar de cargar siempre el contenido. Divide lotes grandes. Un CSV de cientos de miles de filas procesado de una sola vez puede fallar en un servidor que maneja miles de webhooks pequeños sin problemas.

Incluye el tamaño máximo, no el promedio, en la prueba. El archivo excepcional suele ser el que revela un límite demasiado optimista.

Retención de ejecuciones y crecimiento del disco

Guardar entradas, salidas y errores facilita diagnóstico, pero hace crecer PostgreSQL. Define cuánto historial necesita realmente el equipo y activa poda. Conservar para siempre cada payload puede llenar el volumen y también ralentizar consultas del editor.

Antes de reducir retención, identifica obligaciones de auditoría y evita guardar secretos o datos personales innecesarios. Los logs técnicos y el historial funcional no sustituyen un sistema de archivo empresarial. Si necesitas evidencia prolongada, exporta la información adecuada a un destino diseñado para ello.

Vigila tamaño de base, espacio libre y tasa de crecimiento. Un plan con RAM suficiente puede caer porque el disco alcanzó 100 %. Reserva margen para actualización, backup y restauración.

SQLite o PostgreSQL según etapa

SQLite reduce piezas para una prueba local o instancia pequeña. Vive en un archivo y simplifica el arranque. A medida que crece la concurrencia, una base separada como PostgreSQL ofrece una operación más adecuada y es necesaria para arquitecturas distribuidas.

Migrar no consiste en cambiar variables y asumir que los flujos aparecen. Prepara exportación o procedimiento compatible, respalda la clave de cifrado y prueba credenciales. La clave es tan importante como la base: sin ella, una restauración puede contener flujos pero no descifrar accesos.

En producción nueva, comenzar con PostgreSQL evita una migración temprana si ya esperas actividad. En una prueba de pocas horas, añadirlo puede ser complejidad sin valor.

Cuándo adoptar queue mode y workers

El modo cola permite separar la instancia principal de los workers y distribuir ejecuciones con Redis. Resuelve necesidades de concurrencia y escalamiento; añade Redis, coordinación, redes, observabilidad y más destinos de backup. No es una mejora gratuita para un servidor pequeño.

Adóptalo cuando la cola y los tiempos demuestren que una instancia no sostiene trabajo legítimo, o cuando necesites aislar ejecuciones del editor. Define cuántos workers y concurrencia por worker caben en la RAM. Multiplicar workers sin límites puede saturar base y servicios externos.

En una arquitectura de varios nodos, todos deben compartir configuración y clave de cifrado. Redis no debe exponerse a Internet. Prueba qué pasa si un worker se detiene y cómo reanuda la ejecución.

Controlar concurrencia antes de comprar más servidor

Si diez trabajos pesados comienzan juntos, limitar su concurrencia puede estabilizar el sistema a cambio de una cola más larga. Esa solución es válida cuando el negocio acepta demora. Si cada ejecución tiene un plazo estricto, necesitarás capacidad o separación.

Evita cron idénticos a la misma hora. Distribuye tareas y aplica lotes. Configura reintentos con espera para no convertir una caída de API en una tormenta de nuevas llamadas. Los límites protegen también al proveedor externo y reducen bloqueos por tasa.

Mide longitud de cola, edad del trabajo más antiguo y tasa de llegada. La RAM describe una parte; una cola que crece continuamente indica que la capacidad de proceso es menor que la demanda.

Precio total: VPS, copias y administración

El precio mensual del plan es solo la base. Añade almacenamiento externo para backups, dominio, correo transaccional si aplica y tiempo de mantenimiento. Una instancia autogestionada puede ser económica cuando el equipo ya opera servidores; puede resultar cara si cada actualización interrumpe a alguien durante horas.

Compara con una plataforma gestionada usando el mismo volumen y necesidades. Autoalojar gana control, ausencia de límites comerciales específicos y cercanía a datos internos. El servicio administrado reduce parches, base, copias y recuperación. No todas las empresas valoran igual esas tareas.

Revisa el precio vigente en la página del proveedor antes de decidir. Documenta además el siguiente tamaño y si puede ampliarse sin migración; el coste de crecer forma parte de la elección inicial.

Backups que realmente recuperan n8n

Protege PostgreSQL, volumen de n8n, archivo de entorno, Compose, configuración del proxy y, especialmente, la clave de cifrado. Guarda copias fuera del VPS. Una imagen del contenedor no contiene tus datos y puede descargarse otra vez.

Haz una restauración en otra máquina: levanta la base, monta el volumen, aplica la misma clave y abre un flujo. Ejecuta una integración de prueba con credenciales no críticas. Ese ensayo descubre permisos, nombres de volumen y secretos faltantes antes de una emergencia.

Define frecuencia según ejecuciones y cambios. Si perder un día de flujos o credenciales no es aceptable, una copia nocturna no cumple el objetivo.

Seguridad del editor, webhooks y servicios internos

Expón solo HTTPS mediante el proxy. El puerto de n8n debe escuchar en la interfaz local o red interna; PostgreSQL y Redis no necesitan acceso público. Activa autenticación fuerte, protege SSH con llaves y aplica parches al host y las imágenes.

Los webhooks son entradas públicas por diseño. Valida firmas o secretos en cada integración y no confíes solo en una URL difícil de adivinar. Limita tamaño de cuerpo y tasa cuando sea posible. Revisa workflows importados: un nodo de código puede acceder a datos disponibles para el proceso.

Guarda secretos en configuración protegida y controla quién edita flujos. n8n conecta sistemas sensibles; comprometerlo puede abrir CRM, correo, almacenamiento y pagos a la vez.

Prueba de capacidad antes de dirigir tráfico

Carga una copia representativa, no datos sensibles innecesarios. Ejecuta simultáneamente los flujos más pesados, simula fallos externos y observa memoria, CPU, cola, base y disco. Verifica que los reintentos no dupliquen acciones como enviar o facturar.

Después detén y reinicia contenedores para confirmar persistencia. Restaura un backup y revisa que las credenciales sigan utilizables. Ejecuta un webhook desde fuera para validar DNS, TLS y proxy.

Da por aceptado el plan cuando sostiene el pico, conserva margen, procesa la cola dentro del plazo y se recupera de un reinicio sin intervención improvisada.

Señales claras para escalar

Amplía RAM cuando hay presión u OOM bajo trabajo legítimo ya controlado. Añade CPU cuando tareas listas mantienen núcleos ocupados. Aumenta disco cuando el crecimiento proyectado no deja espacio para retención y restauración. Separa workers cuando necesitas concurrencia o aislamiento, no por moda.

Registra el antes y el después. Si al cambiar el plan no mejora duración, cola ni errores, revisa la hipótesis. También vuelve a dimensionar cuando incorpores documentos, IA, navegador o un aumento fuerte de frecuencia: esos cambios transforman más la carga que añadir varios workflows sencillos.

Medir cuánta memoria consume un workflow real

La forma más fiable de dimensionar n8n es ejecutar una muestra representativa y observar el máximo, no mirar el consumo del editor vacío. Elige un flujo que incluya los pasos más costosos —archivo grande, transformación de muchos elementos, nodo Code o varias llamadas concurrentes— y pruébalo con un volumen cercano al pico esperado.

Si instalaste n8n con Docker Compose, registra antes y durante la ejecución:

docker stats --no-stream
docker compose top
free -h
vmstat 1 60

docker stats muestra memoria del contenedor; free revela el margen del host y vmstat si el kernel empieza a mover páginas hacia swap. Repite la prueba varias veces: la primera ejecución puede descargar datos o calentar cachés, mientras ejecuciones posteriores muestran el comportamiento estable. También prueba dos o más disparos simultáneos, porque la concurrencia multiplica datos vivos aunque cada corrida aislada sea pequeña.

Mide por etapas. Una ejecución que descarga un archivo, lo descomprime, lo convierte a JSON y luego lo envía puede mantener al mismo tiempo varias copias del contenido. Si el pico aparece en un único nodo, cambia el diseño antes de comprar RAM: procesa por lotes, reduce campos, evita unir ramas masivas y almacena temporalmente fuera de memoria. Si todos los flujos crecen de forma proporcional al negocio, ampliar capacidad sí responde a una necesidad real.

Al terminar, confirma que la memoria vuelve a una banda estable. Que el RSS no regrese exactamente al valor inicial no demuestra una fuga: el runtime y el sistema conservan memoria para reutilizarla. Una tendencia ascendente durante muchas ejecuciones equivalentes, acompañada de reinicios u OOM, sí merece aislar el workflow, revisar nodos comunitarios y comparar con una versión controlada.

Nodos Code, IA y binarios: tres perfiles que cambian el tamaño

Un flujo de webhooks que mueve pequeños objetos JSON puede manejar muchas ejecuciones con poca memoria. Un nodo Code que construye arreglos completos, un flujo de IA con respuestas extensas o una automatización de archivos tiene otro perfil aunque el contador de workflows sea el mismo.

En nodos Code evita copiar colecciones innecesariamente. Operaciones como mapear, filtrar y volver a combinar miles de elementos pueden conservar varias estructuras a la vez. Divide en lotes y elimina campos que ya no necesitarás. Un loop controlado tarda quizá un poco más, pero mantiene el máximo dentro del VPS y reduce la probabilidad de que el kernel mate el contenedor.

Los nodos de IA suelen consumir más por el contenido que preparan que por la llamada remota. Historiales de conversación, documentos recuperados y resultados intermedios se convierten en objetos antes de enviar la petición. Limita contexto desde el diseño y almacena referencias en vez de repetir documentos completos entre nodos. Si ejecutas un modelo local, ya no estás dimensionando solo n8n: memoria del modelo y aceleración requieren un cálculo separado.

Con binarios, decide dónde viven durante la ejecución. Guardarlos dentro de los datos de ejecución puede inflar memoria y base de datos; mantenerlos en almacenamiento externo o en un modo de archivos compatible reduce esa presión, pero añade permisos, limpieza y backups. Prueba restauración y eliminación: un registro sin su archivo asociado no es una ejecución recuperable, y un archivo sin retención puede llenar el disco aunque PostgreSQL permanezca pequeño.

No uses un timeout enorme como solución a un flujo que procesa demasiado. El timeout limita duración, no memoria, y una ejecución larga puede retener recursos mientras nuevas corridas se acumulan. Aplica límites de tamaño al webhook, valida metadatos antes de descargar y manda trabajos pesados a una cola con concurrencia explícita.

Dimensionar con un presupuesto de memoria

En una instalación de un solo VPS, reparte RAM entre sistema, Docker, n8n, base de datos, proxy y margen de pico. No asignes el cien por ciento a contenedores: el kernel necesita caché y memoria para red, filesystem y operaciones de persistencia.

Construye el presupuesto con mediciones propias:

RAM necesaria = sistema y proxy
              + n8n en reposo
              + pico por ejecución × concurrencia permitida
              + PostgreSQL o SQLite durante escritura
              + margen para backups, actualización y variación

Supón, como ejercicio y no como cifra universal, que el host y servicios base consumen 600 MB, n8n estable 700 MB y cada ejecución pesada añade 350 MB. Con tres ejecuciones simultáneas el conjunto ya se acerca a 2,35 GB antes de reservar margen para base, caché y una actualización. Un VPS de 2 GB no encaja; uno de 4 GB puede hacerlo si la prueba confirma esos valores. Cambia cada número por el máximo observado en tu instalación.

El límite de concurrencia es una herramienta de capacidad. Si diez webhooks llegan juntos, no todos deben transformar archivos al mismo tiempo. Una cola puede aceptar el trabajo y dejar que dos workers avancen de manera estable. Vigila entonces la antigüedad de la cola: proteger RAM a costa de procesar eventos horas tarde tampoco cumple el objetivo.

Cuándo separar PostgreSQL o los workers

Separar servicios tiene sentido cuando sus picos se interfieren o requieren recuperaciones distintas. PostgreSQL compite por RAM y disco con el historial de ejecuciones; un worker de archivos compite por CPU con el editor y los webhooks. Si no puedes identificar esa competencia en métricas, dividir prematuramente añade red, credenciales, backups y puntos de fallo sin resolver un problema probado.

Una base externa libera memoria del VPS de n8n y permite tratar sus backups por separado, pero añade latencia y costo. Mantén la conexión en una red privada o cifrada, limita el pool y prueba qué ocurre si la base deja de responder. n8n no debe abrir cientos de conexiones durante la recuperación.

En queue mode, el proceso principal recibe webhooks y coordina, mientras workers consumen trabajos. Define la concurrencia por worker y el número de workers según memoria por ejecución. Asegúrate de que todos comparten la misma clave de cifrado, versión y configuración, y de que los binarios sean accesibles con el método elegido. Escalar solo el contenedor sin compartir correctamente estado produce fallos intermitentes difíciles de rastrear.