Todos los productos 
Cómo elegir un VPS para n8n y desplegarlo sin sorpresas
n8n es un constructor de automatizaciones que puedes instalar en tu propio servidor en lugar de pagar una suscripción cloud. Una instalación propia elimina los límites de ejecuciones y de flujos, y los datos y accesos a los servicios se quedan contigo. El precio: un servidor virtual y media hora de configuración.
Cuántos recursos necesita n8n
n8n en sí es una aplicación de Node.js que en reposo ocupa unos cientos de megabytes de memoria. La carga la generan los flujos: respuestas grandes de API, archivos, bucles sobre miles de registros, nodos Code. Referencias aproximadas:
- 1–2 GB de RAM, 1 núcleo: automatizaciones personales, decenas de ejecuciones por hora, base de datos SQLite.
- 2–4 GB de RAM, 2 núcleos: instancia de trabajo de un equipo con PostgreSQL en un contenedor contiguo. Ese es el mínimo fijado en el filtro de esta página.
- 4–8 GB de RAM o más: modo de colas con workers, procesamiento de PDF e imágenes, cadenas de IA largas.
Las llamadas a IA externas mediante los nodos de IA las aguanta un plan normal. Pero si el modelo tiene que funcionar en el propio servidor, los requisitos de memoria son otros muy distintos: consulta VPS para IA en CPU.
Docker, Postgres y clave de cifrado
Lo más cómodo es instalar n8n con Docker Compose: un contenedor de n8n, un contenedor de PostgreSQL y un proxy inverso. Docker necesita virtualización completa, así que elige KVM; más detalles sobre cómo preparar el servidor en la página VPS para Docker.
Por defecto n8n lo guarda todo en SQLite. Para probar basta, pero a medida que crece el historial de ejecuciones el archivo de la base se hincha, y el modo de colas no funciona con SQLite. PostgreSQL es más fiable y más fácil de respaldar con pg_dump.
Define la variable N8N_ENCRYPTION_KEY de forma explícita y guarda una copia fuera del servidor. Con esa clave se cifran todas las credenciales guardadas: sin ella, una copia de seguridad de la base no te devolverá el acceso a los servicios.
Webhooks y HTTPS
Muchos disparadores (bots, pasarelas de pago, formularios web) envían eventos a un webhook, y casi todos exigen HTTPS con un certificado válido. Necesitas un dominio o subdominio que apunte a la IP del servidor y un proxy como Caddy o nginx con certificado de Let's Encrypt. Indica la dirección pública en WEBHOOK_URL; si no, los nodos mostrarán enlaces internos a localhost:5678.
No abras el puerto 5678 al exterior. Docker publica los puertos saltándose ufw, así que vincula el contenedor a 127.0.0.1 y da acceso al editor solo a través del proxy.
Modo de colas
Cuando un solo proceso ya no da abasto, n8n se pasa a queue mode: la instancia principal recibe los webhooks y deja los trabajos en Redis, y unos workers aparte los ejecutan. Hacen falta PostgreSQL, Redis y la misma clave de cifrado en todos los procesos. En un solo VDS con 4–8 GB de memoria este esquema funciona sin problema; sacar los workers a máquinas separadas tiene sentido cuando les faltan núcleos.
Dónde ubicar el servidor
Fíjate en con qué trabajan tus flujos. Para API internacionales es cómodo un servidor en Europa o EE. UU. Si tus flujos trabajan sobre todo con CRM, bancos y marketplaces locales de un país concreto, lo lógico es un servidor en ese país o cerca. Elige el país en los filtros; las formas de pago de cada plan se ven en la columna «Pago».