💬 Tu opinión sobre un cambio propuesto: requerir Docker para ejecutar n8n

Anuncios
1

Hasta ahora, siempre ha habido dos formas principales de implementar n8n: a través de npm y a través de Docker. Estamos considerando discontinuar el soporte nativo de npm y nos gustaría obtener tu opinión al respecto.

Nos encantaría que completes esta encuesta después de leer.

Por qué estamos considerando esto

Estamos trabajando duro en un asistente de IA mucho más potente — piensa en Claude Code, pero integrado en n8n. Esto ha estado en la lista de deseos de la comunidad durante mucho tiempo, y es importante que lo llevemos a instalaciones autohospedadas. Estamos apuntando a un lanzamiento autohospedado este verano.

Por seguridad, este asistente necesita un sandbox. Ese sandbox debe implementarse en un contenedor Docker separado. Esto significa que n8n tendrá una dependencia de Docker. Por esto, tiene sentido estandarizar en una implementación basada en Docker — particularmente porque es un método de implementación más confiable de todas formas.

Qué significaría esto para las instalaciones basadas en npm

Si quisieras actualizar, necesitarías asegurarte de que Docker está instalado e implementar usando eso en su lugar. Podrías mantener tu instalación en el mismo directorio y montar ese directorio en Docker. Proporcionaríamos orientación sobre cómo hacer esto.

Si no quiero el asistente, ¿por qué no podría seguir ejecutando el resto de n8n a través de npm?

Aunque esto es técnicamente posible, cuantos más sabores y configuraciones diferentes tenga un producto, más complejidad y errores se introducen.

Hay otros beneficios para pasar a Docker exclusivamente; el asistente es solo el más inmediato. Hacerlo:

  • Aceleraría el desarrollo de n8n
  • Haría que n8n sea más fácil de soportar
  • Abriría la puerta a agrupar otros productos con n8n en el futuro si lo necesitáramos, p. ej. una base de datos vectorial o Redis.

Lo que nos gustaría saber

Somos conscientes de que puede haber algunas situaciones donde usar Docker es difícil. n8n se usa de todas las formas posibles y es probable que ni siquiera seamos conscientes de algunas de ellas. Así que nos gustaría escuchar a todos sobre este tema, ya sea que actualmente uses npm o Docker — ¡por favor completa la encuesta a continuación! :folded_hands:

:backhand_index_pointing_right: Enlace a la encuesta

11 Me gusta
3

Apoyo esto. Hace mucho tiempo que no uso una instalación de npm de n8n, excepto cuando estoy desarrollando nodos.
Usar npm para instalar n8n siempre acabará causando problemas en algún momento. Docker también es más seguro.
Cuando los clientes nos piden que gestionemos su instancia, siempre los animamos a usar Docker si están usando npm. Hace que todo sea más fácil de gestionar. :slight_smile:

12 Me gusta
4

Estoy de acuerdo con Bram, Docker es mucho más fácil de configurar y es más rápido, además tiene contenedores que ayudan a mantener las cosas más seguras.

5 Me gusta
5

Apoyo esta dirección. Yo mismo ejecuto n8n en Docker y antes experimenté brevemente con npm. La diferencia en estabilidad y mantenibilidad es evidente.
Lo que me convence de esta decisión: El asistente de IA integrado necesita una sandbox, y una sandbox necesita Docker. Esta no es una dependencia arbitraria sino fundamentada técnicamente. Quien use n8n en serio, generalmente ya tiene Docker en funcionamiento de todas formas.
El único punto que me hace reflexionar: Hay usuarios que ejecutan n8n en entornos muy ajustados, por ejemplo en pequeños VPS sin mucha RAM, donde Docker cuesta notablemente más recursos que una instalación npm pura. Para ellos sería importante una guía de migración clara e idealmente una imagen Docker optimizada.
En general: Menos variantes significa menos bugs y desarrollo más rápido. Eso beneficia a toda la comunidad.

3 Me gusta
6

Bueno, es hora de adentrarse en el agujero de conejo de Docker, tutoriales de CLI y Desktop.
Si algún mago puede compartir un dockerfile completo con queue, workers, task runners, postgresql, redis… ¡definitivamente podemos evitar que los amantes de npm vuelvan a hacerlo en el futuro! :slight_smile:

P.D algunos aman npm… algunos aman docker… ¡pero lo más importante es que TODOS aman N8N!!!

1 me gusta
7

Estoy de acuerdo: Docker parece ser el camino más limpio y mantenible aquí, especialmente para el sandbox del asistente de IA y la estabilidad a largo plazo.

1 me gusta
8

Actualizar desde npm fue una pesadilla. Había muchos problemas de dependencias.
Docker es más fácil aunque tiene algunos gastos generales. La gestión es la clave.

+1 por Docker

1 me gusta
9

Apoyo esta dirección. Tras ejecutar n8n en instancias VPS para múltiples entornos de clientes, Docker ha sido significativamente más predecible que npm en diferentes versiones de n8n, especialmente cuando el sandbox de IA comenzó a requerir aislamiento de procesos separado.

La única solicitud concreta que añadiría: un archivo Compose de contenedor único y minimalista optimizado para VPS pequeños (1-2 vCPU, 1-2 GB de RAM) con documentación clara sobre qué servicios se pueden desactivar para reducir la sobrecarga. Muchos usuarios autohospedados ejecutan n8n en VPS económicos donde el daemon de Docker en sí mismo agrega presión de memoria, así que una guía sobre la configuración mínima viable de Docker reduciría fricciones en esas migraciones.

4 Me gusta
10

Estoy ejecutando Docker en un VPS de Ubuntu a través de MobaXterm. Este método es un poco técnico, pero cualquiera que lo haya usado antes probablemente lo preferirá a largo plazo.
Docker Compose + Cloudflare Tunnel es una configuración esencial para los usuarios - bastante fácil de respaldar, mantener e incluso migrar datos.
El requisito de un entorno de sandbox para el asistente de IA es simplemente un beneficio adicional.

Sin embargo, ¿necesita la configuración actual de Docker Compose algún cambio cuando se inicia el asistente? ¿O es simplemente un contenedor adicional que se conecta y se ejecuta en el mismo sistema?

11

Debería ser simplemente un contenedor adicional, sí :+1:

2 Me gusta
12

Gracias por la transparencia en esto. Estoy de acuerdo en que hay beneficios al migrar a Docker, pero también hay algunos desafíos técnicos, incluyendo el acceso a archivos locales y permitir operaciones tipo comandos como crear carpetas y archivos. Esto funciona con múltiples ajustes hoy en día y se volverá aún más complejo con la adición de Docker en la mezcla.

Otra parte que podría complicar las cosas es la licencia de Docker en sí y lo que eso significa para algunos usuarios.

13

Muy buena idea, ademas de esto, el nombre de pirateo por npm ha crecido, por lo que puede perjudicar los datos de uno al trabajar en n8n. Y para instalar n8n en docker supone tener conocimientos tecnicos pero uno puede aprender, yo mismo he tenido problemas al instalar n8n en docker desktop pero lo solucioné paso a paso buscando en youtube y preguntando al AI Chino Deepseek.

14

apoyado, cuestionario respondido

2 Me gusta
15

Afortunadamente, Coolify hace Docker más amigable. El acceso a archivos sigue siendo algo no fácil de manejar.

1 me gusta
16

Ejecutar n8n autohospedado para una plataforma SaaS con múltiples tenientes: soporte totalmente basado en Docker. Todo el setup de múltiples trabajadores y modo de cola funciona de manera más confiable cuando la versión de n8n y el entorno de ejecución son consistentes en los contenedores main, workers y webhooks. Las instalaciones basadas en npm generan desviaciones a nivel del sistema operativo del host y causan diferencias sutiles entre entornos que son difíciles de depurar. El requisito de aislamiento del asistente de IA es simplemente el punto final natural de una dirección que ya era la opción correcta para los despliegues en producción.

17

Esa es una noticia decepcionante - no soy (todavía :wink: un experto pero sí intenté usar Docker y paralizó mi máquina (Windows con 16GB de RAM e n8n instalado localmente). Cuando desinstalé Docker y volví a usar NPM pude dedicarme a trabajar de verdad en n8n en lugar de pasar tiempo investigando problemas de recursos. Claro que podría actualizar mi máquina, pero algunos de mis clientes tienen configuraciones más básicas y a veces necesito trabajar con lo que tienen disponible.
Desde mi (aunque limitada) perspectiva, usar Docker parece añadir una capa innecesaria de complejidad y sobrecarga para situaciones simples. Si Docker debe perseguirse por razones técnicas, ¿tiene que ser tan voraz?

2 Me gusta
18

En mi opinión, incluso los no administradores pueden instalar Docker, y gracias a herramientas como Portainer, también es fácil de gestionar. Esto facilita que los principiantes (como yo) que no quieren una solución en la nube comiencen.

Tener múltiples opciones a menudo deja a muchas personas enfrentándose a un dilema a la hora de tomar una decisión. A veces es bueno que alguien tome la decisión por ti (me refiero aquí a los usuarios que simplemente quieren probar una instalación).

Estoy entusiasmado con la idea de un asistente de IA, y estoy seguro de que ayudará a n8n a dar grandes pasos.

¿Encuesta terminada? Listo :wink:

2 Me gusta
19

Estoy de acuerdo con la dirección exclusiva de Docker para la mayoría de los usuarios, y una imagen predeterminada magra, endurecida y sin permisos de root tiene sentido. Pero tiene dos propiedades que dificultan ejecutarla correctamente en hosts NAS/autohospedados (Unraid, Synology, …), y pasar a Docker exclusivamente convierte estos de “simplemente usa npm” en bloqueadores insalvables:

  1. Sin mapeo de UID/GID del host. La imagen se ejecuta como un usuario node fijo (uid 1000), por lo que los recursos montados con bind terminan siendo propiedad del UID/GID incorrecto en el host. La solución establecida (imágenes LinuxServer.io y similares) es iniciar como root, realizar la configuración de primera ejecución y luego cambiar a un usuario remapeado desde PUID/PGID proporcionados por el host, de modo que el contenedor nunca dañe los permisos de los recursos compartidos.

  2. Sin gestor de paquetes (apk se elimina). Algunas integraciones NAS necesitan root + un gestor de paquetes en la primera ejecución, por ejemplo, la integración Tailscale de Unraid utiliza un gancho que instala y configura Tailscale al iniciar el contenedor, imposible una vez que apk/apt se eliminan.

Importantemente, (1) no puede ser simplemente una bandera env en la imagen actual: el remapeo de UID (chown de datos montados, usermod, cambio mediante su-exec/gosu) requiere fundamentalmente que el contenedor inicie como root. Ese es un cambio de postura deliberado del predeterminado endurecido sin root, que es exactamente por lo que creo que esto debería estar en una imagen separada en lugar de debilitar el predeterminado.

Entonces: ¿consideraría el equipo un variante autohospedado/NAS oficialmente mantenido — por ejemplo, n8nio/n8n:<version>-nas — que inicie como root, remapee al PUID/PGID del host, elimine privilegios y mantenga un gestor de paquetes disponible para ganchos de primera ejecución? El predeterminado endurecido se mantiene exactamente igual para todos los demás.

1 me gusta
20

No, gracias. Migré de docker a bare metal. Demasiados comandos extra de «docker dice» solo para implementar lo que necesito hacer. «¡Pero docker es mucho más seguro!» como si los hackers no conocieran los comandos de docker y cómo evitar las cosas… paso…