Abri a beta da versão 3.0 do n8n no fim de semana do lançamento. Consultei a documentação de breaking changes, abri o Migration Report e separei duas listas: o que a versão acerta e o que ela erra. A primeira lista ficou maior. A segunda tem dois itens que vão incomodar bastante em workflow de produção.
Eu uso o n8n na minha máquina local Linux para desenvolvimento. A versão 3 acaba com a instalação por npm e me obriga a rodar tudo em Docker. Perder esse companheiro de máquina local me incomoda, então ele abre a segunda lista. A limpeza, por outro lado, era necessária há mais de um ano.
Direto ao ponto
A versão 3.0 acerta ao remover Nodes defasados, apertar padrões de segurança e concentrar o release em breaking changes. O Migration Report e a rotação da encryption key são os melhores exemplos dessa direção.
O que incomoda é o fim da instalação por npm e as mudanças de comportamento que não geram erro. Em If e Switch, o item vazio só aparece quando todas as saídas estão vazias. O workflow continua rodando com outro resultado, o que exige teste.
O que o n8n 3.0 acerta
A limpeza é o primeiro acerto: Function, Function Item e Item Lists saem de linha. Cron e Interval também saem, junto de HTML Extract e Read PDF. O Workflow Trigger segue o mesmo caminho. Manter esses Nodes custava compatibilidade em cada correção de segurança e em cada atualização. A versão 3.0 encerra esse acúmulo.
A rotação da encryption key é o segundo acerto. Eu falo para guardar essa chave desde 2020, quando comecei a orientar alunos na Promovaweb. Agora a instância mantém uma data encryption key e permite rotacionar sem recriar as credenciais usadas pelos workflows. A rotação altera o modelo de administração de credenciais.
O terceiro acerto é o conjunto de padrões de segurança. O Slack Trigger exige o signing secret da Slack API, a proteção contra SSRF recusa quatro faixas novas e os pacotes de comunidade não verificados deixam de carregar por padrão. Cada item tem um custo de configuração, mas o padrão seguro vira o ponto de partida. Para uma ferramenta que roda credencial de cliente, isso importa.
O quarto acerto é o Migration Report. Ele lista os workflows e as configurações da instância afetados pela 3.0, mostra o impacto de cada item e permite corrigir parte dos casos automaticamente. A aba de problemas da instância fica visível para owners e admins. Para uma migração sem volta, ter um relatório que aponta o que precisa mudar antes de você apertar o botão faz diferença.
O que o n8n 3.0 erra
O fim da instalação por npm é o primeiro erro. O n8n rodava na minha máquina local com npx n8n e me dava um ambiente de teste sem container. A versão 3 exige Docker. Uma instalação que usava o npm para desenvolvimento precisa montar o container. A mudança faz sentido para segurança, mas custa agilidade em testes de ideia antes de subir a infraestrutura.
O segundo erro são as mudanças de comportamento que não geram erro. Em If e Switch, o item vazio só aparece quando todas as saídas estão vazias. No Gmail Trigger anterior à versão 1.4, o limite de e-mails por consulta muda e os rascunhos ficam de fora sem o filtro Include Drafts. O workflow continua rodando com outro resultado. O relatório de migração pode não cobrir todos os casos, então eu prefiro que a ferramenta avise.
O timeout do Code node cai de 5 minutos para 1 minuto. Eu acho um minuto suficiente para a maior parte dos scripts. Já disse que um script que não roda nesse tempo tem algo errado. Ainda assim, a mudança quebra fluxos que dependiam do limite antigo. O ajuste exige variável de ambiente. É uma escolha defensável, mas que chega sem erro na tela.
A importação de workflow por URL também sai do editor. Uma instalação que mantém um marketplace ou uma biblioteca de workflows precisa baixar o arquivo e importar pelo menu, pela CLI ou pela API. A alternativa existe, mas a automação de importação por URL precisa ser refeita com o Node HTTP Request e a API do n8n.
A lista de Nodes removidos está no artigo sobre as breaking changes. Ela não é o problema em si. O problema é descobrir o impacto depois da atualização, quando o workflow já parou.
O que eu ainda quero ver na versão estável
Estamos em beta, com a versão estável prevista para o começo de dezembro. Até lá, o n8n publica versões em ritmo semanal. Eu quero ver se o relatório de migração cobre os casos de comportamento que hoje exigem teste manual.
Também quero ver o comportamento do relatório na versão estável. A beta já mostra os problemas da instância, mas a lista de Nodes e configurações ainda vai mudar até dezembro. Uma migração que começa hoje pode encontrar um relatório diferente na semana seguinte. Também quero ver como a comunidade vai responder à lista de pacotes não verificados, porque muitos Nodes conhecidos ficam fora do carregamento padrão.
O vídeo anuncia uma mudança grande depois da linha 3.x, sem detalhe público. Não vou especular. O que dá para dizer é que a limpeza desta versão prepara o terreno. A estabilidade da 3.0 é a condição para o que vem.
O balanço
O saldo é positivo. A versão 3.0 arruma uma casa que precisava de arrumação. O que me incomoda são duas arestas que vão aparecer em produção: o fim do npm local e as mudanças que não geram erro. Com workflow rodando em dezembro, teste a beta em laboratório e leve o relatório de migração a sério.
Eu vou acompanhar a série até a versão estável e registrar o que mudou. Para entender o calendário da migração, o artigo sobre quando migrar para o n8n 3.0 detalha as datas e a escolha de virar a produção. Para estudar a ferramenta com acompanhamento, o Plano Martech reúne a trilha de automação com n8n. A página do n8n tem o material de apoio.
