Guía Completa para Instalar n8n en Tu Propio Servidor: Docker, VPS, SSL y Backups

Llevo más de dos años usando n8n a diario para automatizar procesos en startups que asesoro desde Chile. En ese tiempo, pasé de usar la versión cloud a montar mi propia instancia en un servidor dedicado, y la diferencia en costos y control ha sido brutal.

Si estás evaluando instalar n8n en servidor propio, esta guía te va a servir. No es teoría: es exactamente lo que hice yo, paso a paso, con los mismos proveedores que sigo usando hoy.

Por qué vale la pena el self-hosting de n8n

Antes de meternos en la parte técnica, hablemos de por qué querrías hacer esto. La versión cloud de n8n funciona bien, no lo voy a negar. Pero cuando empezás a escalar workflows y a manejar datos sensibles de clientes, las cosas cambian.

Costos: El plan Starter de n8n Cloud arranca en unos 24 dólares al mes con ejecuciones limitadas. Con self-hosting, podés tener una instancia completa desde 5 a 10 dólares al mes en un VPS, con ejecuciones ilimitadas. Para una startup en LATAM, esa diferencia importa.

Privacidad de datos: En Chile tenemos la Ley 19.628 de protección de datos, y en muchos países de la región la regulación se está endureciendo. Cuando los datos de tus clientes pasan por servidores en Estados Unidos o Europa, la cosa se complica. Con self-hosting, tus datos se quedan donde vos decidís.

Control total: Querés instalar un nodo comunitario que no está aprobado en la versión cloud? Con self-hosting, lo hacés y punto. Querés configurar la retención de ejecuciones a tu gusto? También. El control es absoluto.

Rendimiento: En mi experiencia, los workflows pesados corren notablemente más rápido en un VPS dedicado que en el plan starter de la nube, simplemente porque no estás compartiendo recursos.

Si todavía no tenés una cuenta de n8n para explorar la plataforma antes de decidir, podés probar n8n acá y familiarizarte con la interfaz antes de montar tu servidor.

Eligiendo el proveedor de VPS correcto

He probado varios proveedores a lo largo de los años. Estos son los que recomiendo para LATAM:

DigitalOcean

DigitalOcean es mi primera recomendación para quienes empiezan. Su droplet más básico de 1 GB de RAM y 1 vCPU cuesta 6 dólares al mes y es suficiente para empezar con n8n. La interfaz es súper amigable y tienen datacenter en Nueva York, que da latencias aceptables desde Sudamérica.

Lo que más me gusta es su marketplace: tienen imágenes preconfiguradas con Docker que te ahorran la configuración inicial. Además, su documentación es excelente y hay mucho material en español.

Para n8n recomiendo como mínimo el droplet de 2 GB de RAM (12 dólares/mes) si vas a correr workflows medianamente complejos. Con 1 GB te va a funcionar, pero vas a sentir la limitación cuando tengas más de 10 workflows activos.

Hetzner

Hetzner es el secreto mejor guardado del hosting en Europa. Sus precios son ridículamente bajos para lo que ofrecen. Un servidor con 2 vCPU, 4 GB de RAM y 40 GB de SSD cuesta apenas 4.49 euros al mes. Es casi la mitad de lo que pagarías en DigitalOcean por specs similares.

El único detalle es que sus datacenters están en Europa (Alemania y Finlandia), así que la latencia desde LATAM es un poco mayor. Pero para n8n, que generalmente corre procesos en background, esto rara vez es un problema.

Yo uso Hetzner para mis instancias de producción y no he tenido un solo problema en más de un año.

Otras opciones

Contabo: Precios muy competitivos, pero el soporte puede ser lento. Lo he usado como servidor de backup.

Vultr: Similar a DigitalOcean en precios, con datacenters en Miami y São Paulo. Buena opción si la latencia es crítica para tu caso de uso.

AWS Lightsail: Si ya estás en el ecosistema de Amazon, tienen planes desde 5 dólares al mes. La ventaja es que la integración con otros servicios de AWS es nativa.

Preparando el servidor

Voy a asumir que ya tenés tu VPS con Ubuntu 22.04 o superior. Si elegiste otro sistema operativo, los comandos pueden variar un poco, pero la lógica es la misma.

Configuración inicial de seguridad

Lo primero que hago siempre en un servidor nuevo es asegurar el acceso SSH. Esto significa crear un usuario nuevo que no sea root, deshabilitar el acceso por contraseña y usar solamente llaves SSH.

Conectate a tu servidor por SSH con el usuario root y creá un nuevo usuario con privilegios de administrador. Agregalo al grupo sudo para que pueda ejecutar comandos con permisos elevados.

Después, copiá tu llave pública SSH al nuevo usuario. Esto te permite conectarte sin contraseña. Una vez verificado que funciona, editá el archivo de configuración de SSH ubicado en y cambiá estas directivas: , , . Reiniciá el servicio SSH después de guardar los cambios.

Configurar el firewall

Ubuntu viene con UFW (Uncomplicated Firewall) preinstalado. Habilitá las reglas básicas: permitir SSH (puerto 22), HTTP (puerto 80) y HTTPS (puerto 443). Después activá el firewall con . Verificá que todo esté correcto con .

Instalar Docker y Docker Compose

Docker es la forma más limpia de correr n8n en un servidor. Para instalarlo, primero actualizá los paquetes del sistema con . Después instalá las dependencias necesarias: , , , .

Agregá el repositorio oficial de Docker usando para descargar la clave GPG e para agregar el repositorio. Instalá Docker Engine con . Finalmente instalá Docker Compose con .

Para verificar que todo funciona, ejecutá y . Deberías ver las versiones instaladas sin errores.

Agregá tu usuario al grupo docker con para no tener que usar sudo cada vez que ejecutás un comando de Docker.

Instalando n8n con Docker Compose

Acá es donde empieza lo bueno. Vamos a crear un archivo Docker Compose que levante n8n junto con una base de datos PostgreSQL, que es mucho más robusta que SQLite para producción.

Creá un directorio para n8n, por ejemplo , y dentro de él un archivo llamado . La estructura del archivo es la siguiente:

Definí dos servicios: uno llamado y otro llamado . Para PostgreSQL, usá la imagen , configurá las variables de entorno , y con los valores que prefieras, montá un volumen para persistir los datos y ponelo en una red interna.

Para el servicio n8n, usá la imagen , mapeá el puerto 5678 al host, y configurá estas variables de entorno esenciales: , , , , (los mismos valores que configuraste para PostgreSQL), con tu dominio, , con la URL completa de tu dominio incluyendo https, y con tu zona horaria (por ejemplo ).

Montá un volumen para los datos de n8n en y asegurate de que dependa del servicio postgres con . Poné ambos servicios en la misma red interna.

No olvides definir los volúmenes nombrados y al final del archivo, y la red con driver bridge.

Levantá todo con y verificá que los contenedores estén corriendo con .

Configurando SSL con Let’s Encrypt y Nginx

Correr n8n sin HTTPS es inaceptable en producción. Vamos a usar Nginx como reverse proxy y Let’s Encrypt para el certificado SSL gratuito.

Instalar Nginx

Instalá Nginx con . Después creá un archivo de configuración para tu sitio en . La configuración debe incluir un bloque que escuche en el puerto 80, con tu dominio como , y un bloque que haga proxy_pass a . Es importante agregar los headers para WebSocket: , , , y también y .

Activá el sitio creando un enlace simbólico desde a , verificá la configuración con y reiniciá Nginx.

Obtener el certificado SSL

Instalá Certbot con y ejecutá . Certbot va a modificar automáticamente tu configuración de Nginx para agregar SSL y configurar la redirección de HTTP a HTTPS.

El certificado se renueva automáticamente, pero podés verificarlo con .

Configurando backups automáticos

Este es el paso que muchos se saltean y después lloran. Yo aprendí por las malas: perdí una instancia completa de n8n por no tener backups y tuve que reconstruir todo desde cero. No le deseo eso a nadie.

Backup de la base de datos PostgreSQL

Creá un script de backup en . El script debe hacer un del contenedor de PostgreSQL usando , comprimir el dump con gzip, ponerle un nombre que incluya la fecha, y guardarlo en un directorio de backups. También conviene que el script borre los backups de más de 30 días para no llenar el disco.

Dale permisos de ejecución al script con .

Programar el backup con cron

Editá el crontab con y agregá una línea que ejecute el script todos los días a las 3 de la mañana: . Así tenés un backup diario automático sin tener que pensar en ello.

Backup off-site

Los backups locales no sirven si el servidor muere. Configurá una sincronización con algún servicio de almacenamiento externo. Yo uso rclone para sincronizar con un bucket de Backblaze B2, que es extremadamente barato (0.005 dólares por GB al mes).

Instalá rclone con , configuralo con para conectarlo a tu proveedor de almacenamiento, y agregá una segunda línea al cron que ejecute del directorio de backups a tu bucket remoto, justo después del backup local.

Mantenimiento y actualizaciones

Mantener n8n actualizado es importante por seguridad y para acceder a nuevas funcionalidades. El proceso es simple:

Andá al directorio de n8n, bajá la última imagen con , reiniciá los servicios con , y verificá que todo funcione correctamente. Docker va a descargar la nueva versión y recrear el contenedor automáticamente.

Mi recomendación: no actualices el mismo día que sale una versión nueva. Esperá al menos una semana para que la comunidad detecte posibles bugs. Y siempre, siempre, hacé un backup manual antes de actualizar.

Para monitorear tu instancia, revisá los logs con . Si ves errores, ahí vas a encontrar las pistas para resolverlos.

Optimizaciones de rendimiento

Después de unos meses de uso, vas a querer optimizar tu instancia. Estas son las variables de entorno que más impacto tienen:

y para que n8n borre automáticamente los datos de ejecuciones después de 7 días (168 horas). Esto evita que la base de datos crezca sin control.

si querés monitorear el rendimiento con Prometheus y Grafana.

si tenés muchos workflows concurrentes. Esto requiere agregar un contenedor de Redis a tu Docker Compose, pero mejora dramáticamente el manejo de múltiples ejecuciones simultáneas.

Comparativa de costos: self-hosting vs cloud

Para que quede claro por qué vale la pena el esfuerzo, acá va una comparativa real:

n8n Cloud (Plan Pro): 60 dólares al mes, con límite de ejecuciones activas y usuarios.

Self-hosting en Hetzner: VPS de 4.49 euros al mes más dominio (1 dólar al mes amortizado) más backups en B2 (menos de 1 dólar al mes). Total: aproximadamente 7 dólares al mes. Sin límite de ejecuciones ni usuarios.

Eso es un ahorro de más del 88% mensual. En un año, estamos hablando de más de 600 dólares ahorrados. Para una startup en LATAM, eso puede ser la diferencia entre poder automatizar o no.

Cuándo NO hacer self-hosting

Siendo honesto, el self-hosting no es para todos. No lo recomiendo si:

– No tenés experiencia básica con la terminal de Linux
– No querés hacerte cargo del mantenimiento del servidor
– Tu equipo no tiene a nadie técnico que pueda resolver problemas
– Necesitás soporte oficial con SLA garantizado

En esos casos, la versión cloud de n8n es una excelente opción. Podés empezar con n8n Cloud y migrar a self-hosting cuando tu equipo esté listo.

Preguntas frecuentes

Puedo migrar mis workflows de n8n Cloud a self-hosting sin perder nada?

Sí, al 100%. n8n permite exportar workflows como archivos JSON desde la interfaz de la versión cloud e importarlos en tu instancia self-hosted. Lo que no se exporta automáticamente son las credenciales (por seguridad), así que vas a tener que reconfigurar las conexiones a servicios externos. Yo migré más de 40 workflows sin perder un solo nodo.

Cuánta RAM necesito realmente para correr n8n en producción?

Depende de la complejidad de tus workflows. Para empezar, 2 GB de RAM son suficientes para manejar hasta 20-30 workflows activos con ejecuciones moderadas. Si tenés workflows que procesan grandes volúmenes de datos (por ejemplo, importar miles de filas de una base de datos), vas a necesitar al menos 4 GB. Mi instancia de producción corre con 4 GB y maneja más de 50 workflows sin problemas.

Qué pasa si mi servidor se cae? Pierdo los workflows que estaban ejecutándose?

n8n tiene un mecanismo de recuperación que retoma las ejecuciones pendientes cuando el servidor vuelve a estar online, siempre que estés usando PostgreSQL como base de datos (y no SQLite). Los workflows con triggers de webhook van a perder las llamadas que llegaron mientras el servidor estaba caído, pero los triggers de cron se van a ejecutar en la siguiente ventana programada. Por eso es importante configurar monitoreo con herramientas como UptimeRobot (gratuito) para recibir alertas inmediatas si tu servidor tiene problemas.

—

*Soy Javier, consultor de startups en Chile y fundador de Trinico Ventures. Uso n8n todos los días para automatizar procesos y ayudo a equipos de LATAM a sacar el máximo provecho de la automatización. Si tenés preguntas sobre self-hosting, escribime.*