La documentación oficial de n8n es directa sobre instalarlo en un servidor propio: «Autoalojar n8n requiere conocimientos técnicos […] n8n recomienda el autoalojamiento para usuarios expertos. Los errores pueden provocar pérdida de datos, problemas de seguridad y caídas. Si usted no tiene experiencia administrando servidores, n8n recomienda n8n Cloud» (docs.n8n.io, consultado el 21/10/2026).
Original: «Self-hosting n8n requires technical knowledge […] n8n recommends self-hosting for expert users. Mistakes can lead to data loss, security issues, and downtime. If you aren’t experienced at managing servers, n8n recommends n8n Cloud.»
Hoy muchos proveedores instalan n8n con un clic. La instalación ya no es la parte difícil. Lo que sigue (actualizar, hacer backups, cuidar los accesos) es trabajo de todos los meses. En este artículo repasamos en qué consiste ese trabajo, cuándo alcanza con un VPS económico y cuándo conviene que lo haga un proveedor.
Qué implica autoalojar n8n
n8n guarda las llaves de sus otros sistemas
Para automatizar, n8n necesita credenciales de lo que conecta: cuentas de correo, el CRM, planillas, claves de API. Según su documentación, por defecto guarda credenciales, ejecuciones y flujos en una base SQLite, y la carpeta .n8n contiene la clave de cifrado (docs.n8n.io). Proteger el servidor es, en la práctica, proteger el acceso a esos sistemas.
Hay versiones nuevas casi todas las semanas
La misma página indica: «n8n releases a new minor version most weeks» (n8n publica una versión menor casi todas las semanas). En una instalación con Docker, actualizar es un paso manual: descargar la imagen nueva y reiniciar el contenedor. No es complejo, pero alguien tiene que hacerlo, y con regularidad.
Las vulnerabilidades se corrigen, y los parches hay que aplicarlos
Dos ejemplos de 2026, ambos ya corregidos por n8n:
- El 08/01/2026, n8n publicó un aviso de seguridad sobre CVE-2026-21858, una vulnerabilidad explotable sin autenticación a través de formularios y webhooks, corregida en la versión 1.121.0.
- El 25/02/2026, n8n publicó un boletín de seguridad con cinco vulnerabilidades críticas (CVE-2026-27577, CVE-2026-27497, CVE-2026-27495, CVE-2026-27498 y CVE-2026-27494) y dos de severidad alta (CVE-2026-27493 y CVE-2026-27578).
- El 14/10/2026, n8n publicó en GitHub 15 avisos de seguridad nuevos (4 de severidad alta y 11 moderada), todos ya corregidos. Uno de los de severidad alta, GHSA-wvjj-qg37-pv73 (CVSS 7.2), permitía acceder a tablas de datos de otros proyectos y se corrigió en las versiones 2.44.1 y 2.43.5.
Que existan avisos así es una buena señal: el proyecto publica y corrige. La protección, sin embargo, llega recién cuando la versión corregida está instalada en su servidor., sin embargo, llega recién cuando la versión corregida está instalada en su servidor.
Checklist mensual para un n8n autoalojado
Cada punto se puede verificar. Si alguno no tiene responsable, ahí está el trabajo pendiente.
- Actualizar n8n. Revise los avisos de seguridad de n8n y la versión instalada. Si hay un aviso que afecta su versión, actualice sin esperar al mes siguiente.
- Actualizar el sistema operativo y el runtime. Aplique los parches del sistema y de Docker en una ventana de mantenimiento conocida, para que los reinicios no tomen a nadie por sorpresa.
- Hacer backups y probar la restauración. Incluya la base de datos y la carpeta
.n8n(sin la clave de cifrado, las credenciales guardadas no se pueden recuperar). Una vez por mes, restaure en un entorno de prueba y confirme que los flujos funcionan. - Revisar accesos. Usuarios con permisos mínimos, cuentas que ya no se usan dadas de baja, acceso SSH por clave y no por contraseña.
- Firewall. Que solo estén abiertos los puertos necesarios. El panel de n8n no debería quedar expuesto a cualquier dirección de internet si no hace falta.
- HTTPS. Acceso a través de un reverse proxy con certificado válido, y control de que el certificado se renueve antes de vencer.
- Monitoreo. Chequeos de disponibilidad, uso de CPU, memoria y disco, estado del contenedor y logs. El objetivo es enterarse de un problema antes de que lo note un usuario.
Cuándo alcanza con un VPS económico y cuándo no
Un VPS económico gestionado por usted mismo es una buena opción para probar n8n, aprender cómo funciona y armar flujos que no son críticos. Si algo falla, se reinstala y no pasa nada.
La situación cambia cuando:
- los flujos procesan pedidos, facturas, clientes o cualquier cosa de la que dependa la operación;
- n8n tiene credenciales de sistemas importantes (correo, CRM, banco, ERP);
- hay webhooks o formularios accesibles desde internet;
- nadie del equipo tiene tiempo asignado para seguir el checklist todos los meses.
En esos casos, la pregunta no es dónde instalarlo, sino quién se hace cargo del mantenimiento: usted, alguien de su equipo o un proveedor.
Por su cuenta o administrado: quién hace qué
| Tarea | VPS por su cuenta | VPS administrado |
|---|---|---|
| Instalación | Usted (o la plantilla del proveedor) | El proveedor lo deja configurado |
| Actualizar n8n | Usted | Proveedor |
| Parches del sistema y runtime | Usted | Proveedor, en una ventana definida |
| Backups y prueba de restauración | Usted | Proveedor |
| Accesos y firewall | Usted | Proveedor |
| HTTPS | Usted | Proveedor (reverse proxy con HTTPS) |
| Monitoreo y alertas | Usted | Proveedor |
| Qué automatizar y qué credenciales cargar | Usted | Usted |
La última fila no cambia: aun con un servidor administrado, usted decide qué conecta a n8n y con qué permisos.
Qué hacemos en AXR
En AXR partimos de entender qué necesita la aplicación: qué recursos consume, qué procesos corre y qué nivel de disponibilidad requiere. Con eso elegimos el VPS y lo dejamos configurado con Docker o el runtime que corresponda, un reverse proxy con HTTPS, firewall y usuarios con permisos mínimos.
Después, el servidor queda bajo mantenimiento continuo:
- aplicamos actualizaciones de sistema y runtime dentro de una ventana de mantenimiento definida;
- actualizamos n8n;
- revisamos los backups y probamos que se puedan restaurar;
- monitoreamos disponibilidad, CPU, memoria, disco, contenedores y logs, con alertas cuando algo se sale de rango;
- ajustamos la capacidad del servidor cuando el consumo lo justifica.
Puede leer más sobre cómo trabajamos en Qué es un VPS administrado y ver los planes en Precios.
Preguntas frecuentes
¿Puedo empezar en un VPS propio y pasar a uno administrado después? Sí. Si tiene backups de la base de datos y de la carpeta .n8n, los flujos y las credenciales se pueden migrar a otro servidor.
¿Con qué frecuencia hay que actualizar n8n? n8n publica versiones menores casi todas las semanas. No hace falta instalar cada una el día que sale, pero sí revisar los avisos de seguridad y aplicar sin demora los que afecten a su versión.
¿Alcanza con los snapshots del proveedor como backup? Un snapshot ayuda, pero un backup sirve recién cuando se probó que se puede restaurar. Lo recomendable es tener copias de la base y de .n8n y hacer una restauración de prueba periódica.
Si el servidor es administrado, ¿quién decide qué se automatiza? Usted. El proveedor se ocupa del servidor y de mantener n8n actualizado; los flujos y las credenciales que se cargan siguen siendo una decisión de su empresa.
¿Quiere revisar su instalación?
Si está por instalar n8n, o ya lo tiene en un VPS y quiere saber qué puntos del checklist faltan cubrir, escríbanos por WhatsApp al +54 11 5524.9506