Então somos um pequeno time de dev, community edition auto-hospedada, construindo workflows de automação para clientes. Esbarramos em algo bem básico e estou curioso se outros conseguiram resolver ou se todo mundo tá improviso.
Nosso processo atual é constrangedor, honestamente. Para mover algo de staging para prod a gente exporta o JSON, importa no outro servidor, e depois passa manualmente corrigindo credenciais, URLs, variáveis de ambiente, tudo que quebrou na transferência. Com 10-12 workflows no nosso projeto principal isso já é chato. O problema maior é que não tem nenhuma forma limpa de dar a cada dev seu próprio setup isolado para testar mudanças sem copy-pasting tudo manualmente, e nosso servidor de staging vira essa bagunça compartilhada onde todo mundo tá pisando um no outro.
Já olhei pro recurso de source control mas isso é só em business e enterprise e a gente não tá pagando €667/mês por isso.
Tem algum workflow que as pessoas realmente conseguiram fazer funcionar? Ou será que todo mundo tá vivendo com esse caos de copy-paste?
Oi @PurveshGandhi
Para uma mudança rápida entre ambientes, exportar e importar o JSON do workflow é a opção mais simples.
Para algo mais mantível entre staging-prod, acho que os ambientes de controle de fonte do n8n são o melhor caminho a longo prazo, porque os workflows são versionados em branches do Git.
Apenas tenha em mente que credenciais e valores de variáveis não são sincronizados automaticamente, então ainda precisam ser configurados por instância.
Então, export-import para uma cópia rápida, controle de fonte para o workflow de ambiente adequado.
Eu dividiria isso em duas camadas: forma do workflow e vinculação de ambiente.
Para Community Edition, eu não trataria o JSON exportado como o sistema de deployment inteiro. Mantenha o JSON como a forma do workflow, depois mantenha um pequeno mapa de promoção ao lado dele:
- nome do workflow, proprietário, gatilho, sistemas upstream, sistemas downstream
-
- variáveis que mudam por local, staging e prod
-
- stubs de credenciais por nome e serviço, sem secrets no JSON compartilhado
-
- uma entrada de teste de fumaça fake ou redatada por workflow, mais saídas esperadas
-
- checklist de promoção: exportar, importar, vincular variáveis e credenciais, executar fixture, ativar, registrar notas de rollback
-
- regra de sandbox do desenvolvedor: clone local ou temporário apenas com credenciais fake; staging compartilhado deve ser o portão de pré-prod, não a caixa de experimentos
- Para 10-12 workflows, uma única tabela de workflow / credenciais / variáveis / teste de fumaça / rollback geralmente mostrará quais workflows são realmente difíceis de promover e quais apenas precisam de nomenclatura consistente.
- Eu evitaria postar exportações de credenciais reais. Um próximo snippet seguro seria uma lista sanitizada dos workflows, nomes de credenciais anonimizados, variáveis específicas de env e uma transferência que quebrou.
Bem-vindo @PurveshGandhi à nossa comunidade! Sou Jay e sou um criador verificado da n8n.
Uma abordagem que pode te poupar do ciclo manual de exportação/importação na Community Edition é automatizá-la com a própria REST API da n8n. Você pode executar um workflow que chama GET /api/v1/workflows no seu servidor de staging, extrai o JSON de cada workflow e depois POST /api/v1/workflows ou PUT /api/v1/workflows/{id} no seu servidor de prod para transferi-lo.
Para credentials, você ainda precisa fazer o rebind manualmente já que valores secretos não são exportados - mas você pode automatizar a sincronização do workflow em si. Combine isso com um mapa de variáveis de ambiente armazenado em uma Planilha Google ou um simples arquivo JSON (nome da credential de staging → nome da credential de prod) e o passo de rebind se torna uma substituição de nó Code antes do push, em vez de uma busca manual.
Isso não vai te dar o branching/rollback do controle de versão, mas substitui o loop de copiar e colar por um workflow de um clique que roda em menos de 30 segundos para 10-12 workflows.
Obrigado @nguyenthieutoan! Isso é super útil.
O sync baseado em API faz muito sentido para a parte de promoção staging → prod. Dois acompanhamentos se você não se importar:
Primeiro, também estamos desenvolvendo para alguns projetos de clientes junto com o nosso, cada um em instâncias n8n separadas. Gerenciar múltiplos workflows de sync e mapas de credenciais por cliente fica complicado, ou continua limpo?
Segundo, e esse tem nos incomodado mais do que o problema de promoção honestamente. Mencionamos no post original que nosso servidor de staging é uma bagunça compartilhada onde desenvolvedores pisam uns nos outros. Sua abordagem de sync resolve o push para prod, mas o que você faz sobre dar a cada desenvolvedor um ambiente isolado para testar mudanças sem contaminar staging? Essa é a parte que não conseguimos resolver.