¡Hola!
Actualmente estoy usando Node-RED para automatizaciones y estoy considerando migrar a n8n. Tengo bloques de construcción personalizados creados, por ejemplo con la API de Node-RED - algunos de ellos están escritos en .js/.html y algunos son subflows. Todos están empaquetados en un paquete npm. Sé que podemos crear nodos personalizados en n8n en TypeScript, así que no creo que haya problema para los nodos que están en JS/HTML, pero ¿qué pasa con los nodos que son subflows? ¿Hay una forma específica de migrarlos a subworkflows de n8n? Algunos de ellos son complejos, algunos son básicamente solicitudes HTTP, etc. Me pregunto si hay una opción similar a la de Node-RED para tenerlos todos en un paquete npm o si debería tener un paquete npm para nodos migrados a TS y luego los nodos que son subflows se extraerían a instancias de n8n a través del control de versiones. Plan de n8n → Enterprise si decidimos migrar.
Y otro tema, ¿crees que hay una forma de migrar rápidamente los nodos/workflows de Node-RED a n8n sin hacerlo manualmente?
¡Realmente agradezco tu ayuda! ¡Gracias!
Hola @Michal_12312312, ¡bienvenido a la comunidad de n8n!
He realizado varias migraciones de Node‑RED a n8n y el mapeo que funciona mejor en la práctica es:
– nodos JS/HTML personalizados -
es decir, nodos personalizados de n8n (TypeScript, distribuidos como paquete npm)
– subflujos - es decir, sub‑flujos de trabajo de n8n, gestionados como flujos de trabajo normales y versionados a través de Git/control de versiones en lugar de npm.
Para los subflujos: en n8n crearía un flujo de trabajo por “bloque de construcción”, lo iniciaría con un trigger de Sub‑flujo de trabajo Ejecutar, y lo llamaría desde otros flujos con Ejecutar Sub‑flujo de trabajo. Eso te da casi la misma reutilización que tienes en Node‑RED, pero con contratos de entrada/salida más claros.
No tengo conocimiento de un convertidor automatizado de Node‑RED a n8n, así que el enfoque más rápido que he visto es:
-
portar la lógica de API de bajo nivel en 1 paquete de nodos personalizados,
-
reconstruir tus subflujos de alto valor como sub‑flujos de trabajo,
-
luego reimplementar flujos individuales sobre esos nuevos bloques de construcción.
Si estás abierto a compartir un pequeño ejemplo de subflujo/nodo personalizado, me encantaría mostrar cuál sería el equivalente 1:1 en n8n antes de que te comprometas con toda la migración.
¡Muchas gracias! @nguyenthieutoan Cuando se trata de sub-flujos de trabajo, también estaba considerando usar desencadenadores de webhook para algunos de ellos y ejecutarlos mediante desencadenadores de otros flujos de trabajo para otros, dependiendo de la funcionalidad. El bloque de construcción de login usaría un webhook, por ejemplo, la consulta SQL usaría el desencadenador cuando es ejecutada por otro flujo de trabajo. La verdadera pregunta es el versionado (los paquetes npm son fáciles por supuesto, estoy hablando de BBs que son subflujos) y los mecanismos de distribución entre instancias de n8n. En cuanto a los nodos personalizados, asumo que tendríamos un repositorio privado en GitHub (y paquete rpm) con todos los nodos personalizados en un paquete, supongo, y el pipeline de CI/CD los integraría en las imágenes docker de n8n y las subiría a AWS ECR, por ejemplo, y luego usaríamos ArgoCD para distribuirlas entre pods.
¿Tienes alguna sugerencia sobre cómo se vería esto cuando se trata de estos nodos node-red como subflujos?
¡Gracias! Ahora tiene mucho más sentido para mí, definitivamente consideraré estos
bienvenido a la comunidad n8n @Michal_12312312
este documento te ayudará Sub-workflow conversion | n8n Docs
Necesitarás ajustar manualmente los tipos de entrada/salida en los nodos Start y Return; tiene soporte limitado para IA y funciones como first() , last() y all() pueden necesitar revisión después de la conversión.
¿Y asumo que es posible conectar tu cuenta/instancia de n8n? ¿Al repositorio de GitHub con subflujos y los extraerá en n8n? ¿Solo está disponible en el plan Enterprise y el tipo de cuenta de administrador, verdad? @nguyenthieutoan @tamy.santos
¿Y hay alguna forma de no usar ArgoCD? ¿No se pueden empaquetar los subflujos como nodos como en nodered? ¿Cuál sería la mejor forma de distribuirlos entre instancias (subflujos que se ejecutan cuando otro flujo los activa)?
¡Gracias de antemano!
Michal, en su mayoría sí, pero no es exactamente “solo Enterprise”: el control de versiones de n8n es una función Business/Enterprise y la conexión se configura por propietario/administrador. Trátalo como sincronización de workflow/entorno, no como un gestor de paquetes para sub-workflows.
Para la distribución, divide los componentes: nodos personalizados para el código que quieres versionado e instalado en todas las instancias; sub-workflows para orquestación que los equipos pueden editar en n8n. El detalle clave es la forma de la instancia: ¿es una única instancia n8n compartida con proyectos, o instancias separadas de cliente/equipo que todas necesitan mantener sincronizadas las mismas versiones de bloques?
Aún no hemos tomado esa decisión. Lo más probable es que cada desarrollador tendría su propia instancia en la que desarrollaría flujos.
Si cada desarrollador tiene una instancia separada, el riesgo es la divergencia de versiones. No trates los sub-workflows como una librería compartida; se convertirán en copias locales una vez que la gente empiece a editarlos.
Mantén el código reutilizable en nodos personalizados, e haz explícita la promoción de workflows/sub-workflows: instancia de desarrollo → cambio de control de versiones/exportación revisada → staging/producción compartido. ¿Los flujos aprobados finalmente llegan a una instancia central única, o cada desarrollador mantiene su propia copia?
@oesterreicher-0417 para responder tu pregunta directamente: sí, n8n puede conectarse a un repositorio de GitHub, pero esa es la función de Control de Código Fuente (Business/Enterprise) y está diseñada para sincronizar flujos de trabajo entre entornos (dev → staging → prod), no como un gestor de paquetes.
Para distribuir sub-flujos de trabajo entre instancias sin ArgoCD, el enfoque más ligero que he usado es exportar el JSON del sub-flujo a través de la API de n8n (GET /api/v1/workflows/{id}) e importarlo en cada instancia de destino con un script pequeño o un flujo de trabajo n8n dedicado que llame a POST /api/v1/workflows en cada instancia. Aún versionas el JSON en Git, pero el “despliegue” es solo una llamada API en lugar de un pipeline de GitOps.
La restricción clave que @olmrqs_ops ya señaló es correcta: una vez que la gente edita un sub-flujo de trabajo localmente, se desvía. Yo bloquearía el sub-flujo de trabajo compartido con acceso de solo lectura en las instancias dev si es posible, o al menos aplicaría una convención de nombres como [SHARED] - WorkflowName para que el equipo sepa que no debe editarlo directamente.