A beta da versão 3.0 do n8n saiu em 27 de outubro. No mesmo dia, começaram a chegar mensagens no Discord da Promovaweb com a mesma dúvida sobre o momento de atualizar. A pergunta raramente tratava da lista de mudanças, porque o momento de virar a produção era o que estava em jogo.
Eu uso o n8n na minha máquina local Linux para desenvolvimento. Com a versão 3, essa instalação por npm deixa de existir, porque a ferramenta agora roda só em Docker. Perder esse companheiro de máquina local me incomoda. Só que o fim do npm é a parte visível de uma mudança maior.
A versão 3.0 não chega para colocar recurso novo na vitrine. Ela remove Node defasado, fecha caminho antigo e aperta padrão de segurança. É uma limpeza feita para abrir espaço para o que vem nas versões 3.x. Entender por que essa limpeza acontece muda a escolha de quando virar a produção. O calendário torna essa escolha urgente.
Direto ao ponto
A versão 3.0 do n8n concentra limpeza, segurança e estabilidade. A instalação self-hosted agora exige Docker, Nodes antigos saem de linha e vários padrões de segurança mudam. O ganho é uma base menor e mais previsível para as próximas versões.
A escolha de quando migrar depende menos da novidade e mais do calendário de novembro e dezembro. A passagem para a 3.x não tem volta, então campanha, atendimento e cliente grande rodando nesse período exigem laboratório primeiro e virada depois. O Migration Report mostra o que precisa mudar na sua instância.
Por que a limpeza é sinal de maturidade
A ferramenta carregava Nodes defasados há mais de um ano. Function e Function Item saíram de linha na versão 2 e continuaram funcionando por compatibilidade. Item Lists, Cron e Interval também saíram de linha. HTML Extract, Read PDF e Workflow Trigger vieram na mesma leva. Manter tudo isso custa: cada correção de segurança precisa considerar o caminho antigo, cada atualização precisa testar o que já devia ter saído e cada instalação carrega código que ninguém quer mais manter.
A versão 3.0 encerra esse acúmulo. O anúncio oficial diz que ela concentra confiabilidade e segurança, enquanto os recursos novos ficam para as versões 3.x. Eu leio isso como um sinal de maturidade, porque uma plataforma que quer evoluir precisa saber o que abandonar. O momento de fazer isso é antes de construir a próxima camada.
Para você que mantém workflows, a limpeza tem um efeito prático. O workflow que hoje roda sem erro pode parar de ativar se usar um Node removido. O relatório de migração existe justamente para mostrar onde isso acontece antes de você atualizar.
O que a remoção muda no dia a dia
Um workflow que usa um Node removido falha na execução. Se estiver publicado, não ativa quando a instância sobe na versão 3.0. O trigger não dispara mais. Para um fluxo de atendimento que classifica mensagem antes de encaminhar, como no exemplo com o Jev, isso significa cliente sem resposta, enquanto para uma rotina financeira significa cobrança que não sai. O artigo sobre as breaking changes detalha os casos mais comuns. O relatório da sua instância mostra quais desses casos existem no seu ambiente.
A lista de Nodes removidos não cobre todas as mudanças: expressões com $getPairedItem falham. O Node Execute Sub-workflow perde as fontes Local File e URL. O Edit Image nas versões 1 e 1.1 sai de linha. Uma instalação que usa Edit Image para montar certificado ou tratar imagem de perfil precisa revisar a saída, porque a versão 2 trabalha com outra biblioteca e o resultado pode mudar.
Também existem mudanças 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, mas com outro resultado. Esse é o tipo de mudança que exige teste, além da leitura do relatório.
Os Community Nodes não verificados saem do carregamento por padrão. Nodes conhecidos da comunidade, como Asaas e Evolution, podem parar de carregar se não estiverem na lista de verificados. A variável N8N_UNVERIFIED_PACKAGES_ENABLED=true reabre esse caminho, mas cada pacote instalado precisa ser conferido depois da atualização.
A linha do tempo do n8n 3.0 e a ausência de volta
A beta saiu em 27 de outubro de 2026, com a versão estável prevista para o começo de dezembro. Entre um ponto e outro, o n8n publica versões beta em ritmo semanal: o repositório oficial registra as tags 3.0.0, 3.0.1 e 3.1.0 no intervalo de uma semana. Uma instalação que acompanha a ferramenta tem um mês para testar. Uma instalação que só quer a versão pronta espera o começo de dezembro.
A passagem para a 3.x não tem volta. Não existe downgrade para a 2.x, então a recuperação de um fluxo quebrado depende de um backup completo. Essa é a diferença entre testar a beta e virar a produção. O laboratório aceita erro e restauração, enquanto a produção exige um caminho de volta que a versão 3.0 não oferece.
Uma instalação na versão 1 precisa passar pela 2 antes de chegar à 3. Não existe caminho direto da 1 para a 3. O suporte da versão 1 termina em 31 de dezembro de 2026. Depois disso, uma vulnerabilidade nova fica sem correção. A versão 2 continua recebendo correções de segurança e de bugs críticos por 12 meses após a versão estável.
Esse cálculo muda o planejamento: uma instalação na versão 1 tem duas migrações pela frente, enquanto uma instalação na 2 tem uma, com suporte ainda disponível durante o processo. O prazo de 31 de dezembro é o limite para sair da versão sem correção. Estudar o assunto depois dessa data não resolve.
Como se preparar antes de virar
O primeiro passo é atualizar a instância para a última 2.x e abrir Settings > Migration Report. O relatório lista os workflows e as configurações da instância afetados pela 3.0. Ele mostra o impacto de cada item, permite corrigir parte dos casos automaticamente e exporta um CSV. A recomendação oficial é resolver primeiro o que trava a atualização e o que faz execuções falharem.
O relatório também separa o que precisa de correção do que pode ser aposentado. Um workflow que não roda há mais de um ano pode ser marcado como won’t fix. Um fluxo de atendimento em produção exige correção. A prioridade acompanha o uso: o n8n que atende cliente e gera receita vem antes do experimento esquecido.
Depois da lista, vem o backup. A orientação oficial é fazer uma cópia completa do banco antes de qualquer atualização. Em seguida, subir uma instância de teste com a versão 3.0, importar os workflows corrigidos e comparar as saídas. O teste precisa olhar o resultado e a ausência de erro. Um workflow pode terminar sem falha e ainda assim buscar o item errado.
Os pontos de atenção mais comuns aparecem na configuração. O volume montado em .n8n/binaryData precisa apontar para .n8n/storage. A instância não sobe se as duas pastas existirem. O modo de binário em memória sai de cena, com o padrão migrando para filesystem. No modo queue, escolha um armazenamento compatível, porque filesystem não é suportado. Uma integração interna com o n8n por Docker ou cluster exige conferir a lista de SSRF e liberar hostname ou faixa de IP.
Quando escolher a data
O calendário de novembro e dezembro decide o momento, enquanto a novidade fica em segundo plano. Black Friday, campanha de fim de ano, atendimento de cliente grande e férias coletivas se acumulam no mesmo período. Uma migração sem volta no meio desse movimento deixa pouca margem para restaurar backup e refazer configuração.
Eu prefiro separar as duas coisas. A beta serve para laboratório, leitura do relatório e correção de workflow. A virada em produção espera o fim do período de maior movimento. Se o seu atendimento fica parado entre o Natal e o Ano Novo, essa janela pode ser melhor do que dezembro inteiro. O importante é ter tempo para testar e restaurar, além de clicar em atualizar.
Existe também a opção de esperar a versão 3.1 ou 3.2. A linha 3.x vai receber os recursos novos. A 2.x continua com correções de segurança por 12 meses. Uma instalação sem necessidade de recurso novo pode esperar a poeira baixar. Uma instalação presa na versão 1 precisa acompanhar o prazo e planejar a passagem pela 2.
Gravei um vídeo com a leitura da beta e vou acompanhar a série de migração até a versão estável. O Plano Martech reúne a trilha de automação com n8n. A comunidade da Promovaweb no Discord tem um canal aberto para acompanhar as mudanças. A versão 3.0 é uma limpeza que prepara o próximo ciclo. A sua parte é escolher a data olhando o calendário, sem a pressa da novidade.
