n8n 3.0 troca o contrato da automação — a migração começa antes do upgrade

Beta não é janela de produção

O n8n lançou em 27 de outubro a beta 3.0.0 e manteve a versão estável prevista para o início de dezembro. A mudança de número não empacota uma coleção de recursos novos: ela concentra remoções, defaults mais restritivos e alterações de execução que não caberiam numa atualização compatível. Para equipes que operam fluxos críticos, isso muda a pergunta de quando atualizar para como provar que a atualização não altera o comportamento esperado.

A orientação oficial é abrir o Migration Report, disponível a partir da linha 2.39, tratar cada workflow e configuração sinalizados, gerar backup completo e testar a migração numa instância separada. O relatório pode aplicar correções automáticas, mas salva cada ajuste como nova versão para revisão e publicação. Automação da migração, portanto, não elimina aprovação operacional.

A própria n8n descreve a passagem para 3.x como unidirecional: retornar à linha 2.x exige restaurar um backup. Um teste independente publicado após a chegada da 3.0.1 conseguiu iniciar uma cópia pequena de dados novamente na 2.45.5, mas tratou o resultado como acaso de laboratório, não como plano de rollback. A evidência externa reforça a regra conservadora do fornecedor: rollback precisa ser restauração validada, não esperança de compatibilidade reversa.

Uma major version não é só software novo. É um novo contrato entre workflows, runtime, armazenamento e operação.

O runtime muda em pontos que parecem detalhes

Na nova linha, execuções manuais em queue mode passam a rodar sempre nos workers; o armazenamento binário em memória é removido em favor de filesystem ou S3; Cron e Interval cedem lugar ao Schedule Trigger; e o timeout padrão do Code node em task runners cai de cinco minutos para um. Instalações self-hosted deixam de ter suporte via npm ou npx e passam a depender de Docker, enquanto Kubernetes e Helm continuam contemplados.

Cada mudança é defensável isoladamente, mas o risco aparece nas dependências invisíveis. Um fluxo pode usar um node removido, assumir cinco minutos de execução, depender de binários em RAM ou disparar alertas a partir de um comportamento que deixou de existir. Mesmo quando o canvas abre sem erro, a semântica operacional pode ter mudado.

O teste independente da versão 3.0.1 encontrou exatamente esse tipo de diferença: JavaScript e Python continuaram funcionando em runner externo, mas um workflow com Cron removido parou e uma tarefa de 75 segundos falhou até que o timeout fosse elevado nos contêineres do n8n e do task runner. É uma amostra limitada, não benchmark universal, porém demonstra por que o inventário precisa cobrir configuração e infraestrutura, não apenas nodes visíveis.

Patch imediato e migração estrutural são duas filas

Em 28 de outubro, a equipe do n8n publicou 12 advisories: três classificados como altos e nove como médios. Entre os temas estão execução de código no processo principal por nodes depreciados, isolamento insuficiente de expressões, configuração insegura do GraphicsMagick, leitura de arquivos pelo Browser Use, autenticação em chat incorporado, redirecionamentos com headers de credencial e riscos em integrações específicas.

O comunicado informa correções na 1.123.89 para a linha 1, 2.45.5 para a estável, 2.46.1 para a beta 2.x e 3.0.1 para a linha 3. Instâncias Cloud foram corrigidas automaticamente; ambientes self-hosted abaixo dessas versões precisam atualizar. Isso não significa que toda instalação esteja explorada nem que todos os advisories se apliquem a todos os fluxos. Significa que a versão vulnerável permanece uma condição verificável e removível.

A coincidência temporal cria um erro de gestão provável: adiar o patch até concluir a migração 3.0 ou, no sentido oposto, tratar a 3.0.1 beta como atalho para segurança em produção. As filas são diferentes. Correções suportadas na linha atual reduzem exposição agora; o salto de major version exige avaliação, staging e janela de mudança. Segurança urgente não deve transformar uma beta em implantação automática.

O ativo real é o mapa de dependências

Um plano de migração útil começa por quatro inventários: workflows ativos e seus donos; nodes depreciados e integrações comunitárias; variáveis, secrets e políticas de rede; e requisitos de execução como timeout, storage, concorrência e filas. Depois vêm os testes de contrato: qual evento inicia o fluxo, quais dados entram, quais efeitos externos são permitidos e qual evidência confirma o resultado.

Também é preciso separar compatibilidade funcional de prontidão operacional. Um workflow pode produzir a saída correta e ainda falhar sob carga, perder binários, duplicar uma ação após retry ou não gerar alerta quando o worker cai. Métricas de duração, exceção, fila, uso de armazenamento, idempotência e recuperação devem acompanhar o ensaio da nova versão.

Fato: a beta 3.0 existe, contém breaking changes e ainda não é a linha estável. Fato: patches para 12 advisories foram publicados nas linhas suportadas. Análise: atualizar a versão corrente e preparar a major release são projetos simultâneos, mas não equivalentes. Inferência: equipes que transformarem o Migration Report em backlog com responsável, evidência e teste de restauração chegarão a dezembro com menos risco do que aquelas que tratarem a migração como uma noite de manutenção.