Opa!
Estou usando Node-RED para automações e estou considerando migrar para n8n. Tenho Building Blocks personalizados criados, por exemplo, com node red api - alguns deles estão escritos em .js/.html e alguns deles são sub flows. Todos eles estão empacotados em um pacote npm. Sei que podemos criar nós personalizados em n8n em TypeScript, então não acho que será um problema para os nós que estão em JS/HTML, mas e quanto aos nós que são sub flows, existe uma forma específica de migrá-los para n8n subworkflows? Alguns deles são complexos, alguns deles são basicamente requisições http, etc. Estou me perguntando se há uma opção semelhante à do Node-RED para tê-los todos em um pacote npm ou se devo ter um pacote npm para nós migrados para TS e então os nós que são sub flows seriam puxados para as instâncias n8n via source control? Plano n8n → Enterprise se decidirmos migrar.
E outro tópico, você acha que há uma forma de migrar rapidamente os nós/workflows do node-red para n8n sem fazer manualmente?
Realmente aprecio sua ajuda! Obrigado!
Oi @Michal_12312312, bem-vindo à comunidade n8n!
Já fiz algumas migrações de Node‑RED para n8n e o mapeamento que funciona melhor na prática é:
– nós customizados em JS/HTML -
n8n custom nodes (TypeScript, distribuído como um pacote npm)
– subflows -
sub‑workflows do n8n, gerenciados como workflows normais e versionados via Git/controle de versão em vez de npm.
Para os subflows: no n8n eu criaria um workflow por “building block”, começaria com um Execute Sub‑workflow Trigger, e o chamaria de outros flows com Execute Sub‑workflow. Isso te dá quase a mesma reusabilidade que você tem no Node‑RED, mas com contratos de entrada/saída mais claros.
Não há um conversor automatizado de Node‑RED -
n8n que eu conheça, então a abordagem mais rápida que vi é:
-
portar a lógica de API de baixo nível para 1 pacote de custom node,
-
reconstruir seus subflows de alto valor como sub‑workflows,
-
então reimplementar flows individuais em cima desses novos building blocks.
Se você estiver aberto a compartilhar um pequeno exemplo de subflow/custom node, fico feliz em mostrar qual seria o equivalente 1:1 em n8n antes de você se comprometer com a migração inteira.
Muito obrigado! @nguyenthieutoan Quando se trata de sub-workflows, também estava considerando usar web hook triggers para alguns deles e executar por meio de triggers de outro workflow para outros, dependendo da funcionalidade. O bloco de construção de login usaria um web hook, por exemplo, a consulta SQL usaria quando executado por outro trigger de workflow. A verdadeira questão é o versionamento (pacotes npm são fáceis, é claro - estou falando sobre BBs que são subflows) e os mecanismos de distribuição entre instâncias n8n. Quanto aos nós personalizados, suponho que usaríamos um repositório privado no GitHub (e pacote rpm) com todos os nós personalizados em um pacote, imagino, e o pipeline de CI/CD os incorporaria às imagens docker do n8n e as enviaria para AWS ECR, por exemplo, e então usaríamos o ArgoCD para distribuí-las entre pods.
Você tem alguma sugestão de como ficaria em relação a esses nós node-red como subworkflows?
Obrigado! Agora faz muito mais sentido para mim, com certeza vou considerar isso
bem vindo à comunidade n8n @oesterreicher-0417
este documento vai te ajudar Sub-workflow conversion | n8n Docs
Você precisará ajustar manualmente os tipos de entrada/saída nos nós Start e Return; possui suporte limitado para IA e funções como first( ) , last( ) e all( ) podem precisar de revisão após a conversão.
E eu assumo que é possível conectar sua conta/instância n8n? Para repositório GitHub com subfluxos e ele os puxará para o n8n? Isso está disponível apenas no plano Enterprise e tipo de conta admin, certo? @nguyenthieutoan @tamy.santos
E existe uma forma de não usar ArgoCD, por exemplo? Os subfluxos não poderiam ser empacotados como nós como no nodered? Qual seria a melhor forma de distribuí-los entre instâncias (subfluxos que quando executados por outro fluxo disparam)?
Obrigado antecipadamente!
Michal, em grande parte sim, mas não é exatamente “Apenas para Enterprise”: o controle de versão do n8n é um recurso Business/Enterprise e a conexão é configurada pelo proprietário/administrador. Trate isso como sincronização de fluxo de trabalho/ambiente, não como um gerenciador de pacotes para sub-fluxos de trabalho.
Para distribuição, divida os componentes: nós personalizados para código que você deseja versionado e instalado em várias instâncias; sub-fluxos de trabalho para orquestração que as equipes podem editar no n8n. O detalhe importante é a forma da instância: é uma única instância n8n compartilhada com projetos, ou instâncias separadas de cliente/equipe que todas precisam manter as mesmas versões de bloco sincronizadas?
Ainda não tomamos essa decisão. Muito provavelmente, cada desenvolvedor teria sua própria instância na qual desenvolveria fluxos.
Se cada desenvolvedor tem uma instância separada, o risco é a divergência de versões. Não trate sub-workflows como a biblioteca compartilhada; eles se tornarão cópias locais assim que as pessoas começarem a editá-los.
Mantenha código reutilizável em nós personalizados e torne a promoção de workflow/sub-workflow explícita: instância dev → mudança de export/source-control revisada → staging/prod compartilhado. Os fluxos aprovados eventualmente chegam em uma única instância central, ou cada desenvolvedor mantém sua própria cópia?
@oesterreicher-0417 para responder sua pergunta diretamente: sim, n8n pode se conectar a um repositório GitHub, mas essa é a funcionalidade de Source Control (Business/Enterprise) e foi projetada para sincronizar workflows entre ambientes (dev → staging → prod), não como um gerenciador de pacotes.
Para distribuir sub-workflows entre instâncias sem ArgoCD, a abordagem mais leve que já usei é exportar o JSON do sub-workflow pela API do n8n (GET /api/v1/workflows/{id}) e importá-lo em cada instância de destino com um pequeno script ou um workflow n8n dedicado que chama POST /api/v1/workflows em cada instância. Você ainda versionarial o JSON no Git, mas o “deployment” é apenas uma chamada de API em vez de um pipeline GitOps.
A restrição fundamental que @olmrqs_ops já sinalizou está certa: assim que as pessoas editam um sub-workflow localmente, ele diverge. Eu bloquearia o sub-workflow compartilhado para acesso somente leitura em instâncias de dev se possível, ou pelo menos aplicaria uma convenção de nomenclatura como [SHARED] - NomeDoWorkflow para que o time saiba não editá-lo no lugar.