n8n en Proxmox: configurar correctamente LXC o VM

Quien quiera autoalojar n8n y ya opere un entorno Proxmox VE se enfrenta a la pregunta de si la automatización de flujos de trabajo debe ejecutarse en un contenedor LXC o en una máquina virtual completa. Para la mayoría de las pequeñas y medianas empresas, un contenedor LXC sin privilegios con las funciones nesting y keyctl activadas es la vía más pragmática, porque consume notablemente menos recursos que una VM y puede ejecutar n8n dentro de un contenedor Docker. Quien necesite un aislamiento máximo sin concesiones debería optar por la VM. Estado: julio de 2026.

LXC o VM: la decisión fundamental

n8n en sí no impone ningún requisito específico de Proxmox; la decisión se toma únicamente a nivel de la técnica de virtualización. Un contenedor LXC comparte el núcleo (kernel) con el host de Proxmox, arranca muy rápido y necesita notablemente menos memoria que una VM comparable. La desventaja: dos niveles de contenedores, LXC y Docker, comparten el mismo núcleo; una actualización del núcleo en el host puede, en caso de duda, afectar a ambos niveles simultáneamente. Una VM aísla completamente a n8n y al daemon de Docker que se ejecuta en él del host, pero a cambio consume más memoria y capacidad de procesamiento para su propio núcleo. Para un único servidor n8n en una pequeña empresa, la diferencia de recursos suele ser en la práctica más determinante que la cuestión teórica del aislamiento.

Docker en el contenedor LXC: configurar correctamente nesting y keyctl

Para que un daemon de Docker pueda funcionar dentro de un contenedor LXC, el contenedor debe estar equipado con interfaces de núcleo adicionales. En la documentación de Proxmox sobre las opciones de los contenedores la función nesting se describe así: "Allow nesting. Best used with unprivileged containers with additional id mapping. Note that this will expose procfs and sysfs contents of the host to the guest." Sin esta opción, el daemon de Docker en el contenedor falla con regularidad al iniciarse. Además, Docker en un contenedor sin privilegios necesita la opción keyctl, que Proxmox documenta así: "For unprivileged containers only: Allow the use of the keyctl() system call. This is required to use docker inside a container." Importante: según la documentación de Proxmox, quien active keyctl para Docker no puede usar simultáneamente systemd-networkd en la misma configuración, ya que ambas funciones reclaman el mismo manejo de llamadas al sistema. Ambas opciones se pueden establecer en la configuración del contenedor en "Features". No se recomienda un contenedor privilegiado para uso en producción, porque Proxmox no trata explícitamente los nuevos exploits de escape de contenedores privilegiados con la misma prioridad que los de contenedores sin privilegios.

Instalar n8n mediante Docker

Una vez preparado el contenedor LXC, la instalación propiamente dicha de n8n sigue los mismos pasos que en cualquier otro host Docker. Según la documentación oficial de Docker de n8n primero se crea un volumen de Docker y n8n se inicia con mapeo de puertos al 5678, las variables de zona horaria TZ y GENERIC_TIMEZONE, así como un directorio de datos montado. Según la documentación, este directorio ubicado en /home/node/.n8n contiene "encryption keys, instance logs, and source control feature assets" y, en la configuración predeterminada, además la base de datos SQLite con todos los flujos de trabajo y credenciales. Quien en su lugar quiera conectar una base de datos PostgreSQL externa añade las variables de entorno correspondientes para host, puerto, nombre de la base de datos y credenciales; según n8n, el directorio de datos sigue siendo relevante también en ese caso, porque allí continúan residiendo datos importantes. En el mismo lugar, n8n señala explícitamente que el autoalojamiento requiere conocimientos técnicos en operación de servidores, gestión de recursos y seguridad, y está pensado para usuarios experimentados. Quien no quiera gestionar esta configuración por sí mismo encontrará en NordFlux apoyo para la configuración y mantenimiento de n8n.

Copia de seguridad: instantáneas de Proxmox como complemento a la copia de seguridad propia de n8n

Un contenedor LXC se puede respaldar mediante la propia función de copia de seguridad de Proxmox, que para los contenedores, según la documentación de copias de seguridad de Proxmox funciona opcionalmente en modo Stop, Suspend o Snapshot. En modo Snapshot, el contenedor se pausa brevemente, se crea una instantánea temporal de almacenamiento y a continuación el contenido se guarda como archivo antes de que la instantánea se elimine de nuevo. Esto respalda de forma fiable el estado completo del contenedor, incluidos el daemon de Docker y el directorio de datos de n8n, pero no sustituye a una copia de seguridad a nivel de aplicación. Quien quiera respaldar específicamente solo los flujos de trabajo y las credenciales debería exportar además con regularidad el propio directorio de datos de n8n, porque una instantánea de Proxmox siempre respalda todo el contenedor y, en caso de emergencia, tarda más que restaurar de forma selectiva flujos de trabajo individuales. En la práctica, se recomienda una combinación: copias de seguridad de Proxmox programadas para la restauración completa del servidor y una exportación adicional, más frecuente, de los flujos de trabajo de n8n para el caso individual rápido.

Preguntas frecuentes sobre n8n en Proxmox

¿Necesito obligatoriamente nesting y keyctl si quiero usar Docker en un contenedor LXC?

Sí, según la documentación de Proxmox, ambas opciones son necesarias para Docker en un contenedor LXC sin privilegios; de lo contrario, el daemon de Docker no se inicia de forma fiable o algunas funciones fallan.

¿Es un contenedor privilegiado la solución más sencilla?

Técnicamente, a menudo sí; desde el punto de vista de la seguridad, no. Proxmox no trata los nuevos exploits de escape procedentes de contenedores privilegiados con la misma prioridad que los procedentes de contenedores sin privilegios. Para un servidor n8n en producción con credenciales almacenadas, ese es un riesgo que la mayoría de las empresas no deberían asumir.

¿Es suficiente una instantánea de Proxmox como única copia de seguridad para n8n?

Una instantánea respalda todo el contenedor de forma fiable, pero es de grano grueso y poco práctica para restaurar flujos de trabajo individuales. Es más sensato combinar una copia de seguridad de Proxmox regular con una exportación adicional y específica de los flujos de trabajo de n8n.

¿Funciona n8n de forma más estable en una VM que en el contenedor LXC?

No fundamentalmente más estable, pero sí más aislado. Una VM aísla completamente al daemon de Docker del núcleo del host, lo que cuesta recursos, pero reduce el riesgo de que una actualización del núcleo en el host de Proxmox afecte a ambos niveles de contenedores al mismo tiempo.