n8n 3.0 beta: mudanças e preparação

O n8n 3.0 entrou em beta em 27 de outubro de 2026. Para quem mantém automações de formulários, CRM, conteúdo ou atendimento, a mudança pede uma revisão antes da atualização: alguns nós antigos serão removidos, a instalação self-hosted passa a exigir Docker e o caminho de volta à versão 2.x é restaurar um backup. A versão estável está planejada para o início de dezembro; o beta é opcional.

O beta chegou; a versão estável ainda está planejada para dezembro

O anúncio oficial descreve o n8n 3.0 como uma versão voltada a confiabilidade, estabilidade e segurança, e não como uma grande rodada de funções novas. O beta 3.0.0 pode ser testado agora; a equipe prevê a versão estável no início de dezembro de 2026. Como essa data ainda é um plano, confira as notas oficiais antes de marcar uma janela de atualização.

A mudança é relevante mesmo para quem pretende esperar. Depois da versão estável, o n8n informa que a linha 2.x receberá correções críticas e de segurança por 12 meses, enquanto recursos novos ficarão na linha 3.x. Quem ainda está na versão 1.x precisa primeiro migrar para a 2.x: não há caminho direto de 1.x para 3.x, e o suporte à 1.x termina em 31 de dezembro de 2026. Veja o anúncio e o cronograma do n8n 3.0.

Quais mudanças podem afetar uma automação existente?

Não é necessário presumir que todos os workflows vão quebrar. O impacto depende dos nós, das configurações e da forma de hospedar cada instância. O documento de breaking changes do n8n 3.0 descreve os itens que exigem atenção; estes são alguns exemplos práticos:

Área	O que muda	O que revisar
Instalação própria	Instalações via npm ou npx deixam de ser suportadas; self-hosted passa a usar Docker.	Planeje a migração da instalação e dos volumes. Docker Compose continua válido; Kubernetes e Helm não são afetados.
Nós antigos	Function, Function Item, Item Lists, Cron e Interval estão entre os nós removidos.	Troque Function por Code, Item Lists pelo nó da operação necessária e Cron/Interval por Schedule Trigger; confirme no relatório se há outros nós afetados.
Execução e segurança	O timeout padrão do Code cai de cinco minutos para um; pacotes comunitários não verificados ficam desativados por padrão.	Revise tarefas longas, dependências e a política de community nodes. Não amplie limites sem entender o risco.
Dados binários	O modo de dados binários em memória é removido; a instância usa filesystem ou armazenamento externo compatível.	Confira o modo, o espaço do volume e o backup dos arquivos antes de atualizar.

Há outras mudanças: execuções manuais no queue mode passam sempre pelos workers; a rotação de chaves de criptografia fica ligada por padrão; e a credencial Slack passa a exigir signing secret para o Slack Trigger. O novo padrão de SSRF também bloqueia mais faixas de IP quando a proteção está habilitada. A lista completa inclui orientações por tipo de nó e configuração, então use o documento oficial como referência da sua instância, não apenas esta seleção resumida.

Como usar o Migration Report antes de atualizar

O relatório é a forma mais direta de descobrir se a sua própria instalação tem workflows ou configurações atingidos. Ele aparece em Settings > Migration Report a partir do n8n 2.39. A equipe recomenda atualizar para a versão 2.x mais recente antes de consultá-lo, para receber a lista mais atualizada.

Identifique sua versão. No n8n, abra Settings e depois Personal; a versão aparece no rodapé da navegação.
Atualize para o 2.x mais recente. Se ainda estiver em 1.x, planeje primeiro a migração para 2.x. Não tente pular diretamente para 3.0.
Abra o Migration Report. Revise tanto os problemas de workflows quanto os problemas da instância. Um relatório sem alertas de workflow não garante que a configuração do servidor esteja pronta.
Atribua responsáveis e revise as correções. O relatório pode corrigir alguns pontos automaticamente, salvando uma nova versão do workflow para você revisar e publicar. Workflows já publicados continuam rodando no 2.x enquanto as mudanças são examinadas.
Faça backup e teste em staging. Rode casos representativos: sucesso, falha de API, repetição, anexos e caminhos condicionais usados no seu processo. Compare saídas com a versão atual antes de mudar produção.

A própria documentação recomenda corrigir ou classificar os alertas, fazer backup completo e testar em uma instância de staging antes da produção. O relatório reduz o trabalho de procurar cada alteração manualmente; ele não substitui a revisão das consequências para o seu negócio. A preparação oficial para o 3.0 detalha as etapas e as versões afetadas.

Exemplo para quem recebe leads por formulário

Imagine um fluxo que recebe um formulário do site, normaliza telefone e e-mail, cria o contato no CRM e avisa a equipe. O primeiro trabalho não é atualizar a instância: é identificar quais nós sustentam o fluxo, se há código que ultrapassa o novo limite padrão de um minuto e se a rotina usa uma configuração de binários ou node comunitário que muda no 3.0.

Depois do relatório, teste submissões duplicadas, campos vazios, timeout do CRM e anexos reais em staging. Compare o registro criado e as notificações com uma execução conhecida no 2.x. Se o fluxo não usa recursos afetados, não invente uma migração só porque saiu uma versão maior; registre o resultado, faça backup e escolha uma janela compatível com a rotina de atendimento. Esse exemplo é um roteiro de avaliação, não um teste realizado pela Josué Sites.

Cloud, self-hosted e custos: o que muda para cada cenário

No n8n Cloud, o beta é opt-in: o usuário pode selecionar 3.0.0 Beta (early access) ao alterar a versão na console. Em self-hosted, a atualização segue o fluxo normal de uma versão beta, mas a instalação 3.0 exige Docker; instalações que usam npm ou npx precisam mudar a forma de implantação. Quem já usa Docker Compose não precisa trocar por outra ferramenta. Kubernetes e Helm permanecem fora dessa exigência específica.

O anúncio não apresenta uma taxa separada para o beta. A cobrança continua ligada ao plano escolhido no Cloud, enquanto self-hosted envolve servidor e operação da infraestrutura. A Community Edition self-hosted também recebe as mudanças do 3.0; o n8n publica as condições atuais na página oficial de planos e preços. O anúncio não detalha uma disponibilidade por país, então não dá para afirmar um cronograma específico para o Brasil; para Cloud, confira se a opção aparece na console da sua instância.

Checklist para decidir se vale testar agora

Você sabe a versão do n8n e o tipo de instalação de cada ambiente?
Executou o Migration Report numa versão 2.x atualizada?
Identificou nós removidos, códigos longos, community nodes e uso de arquivos?
Tem backup restaurável e um ambiente de staging com credenciais e integrações seguras?
Consegue validar as saídas e os casos de erro antes de publicar os workflows migrados?

Se alguma resposta for “não”, o próximo passo é organizar o inventário e preparar o teste, não atualizar produção às pressas.

Perguntas frequentes

O n8n 3.0 já é a versão estável?

Não. Em 27 de outubro de 2026, o que foi disponibilizado é o beta 3.0.0; o n8n planeja a versão estável para o início de dezembro, sujeito a mudanças no cronograma.

Posso voltar do beta para o n8n 2.x?

Não há downgrade direto. A orientação oficial é testar em staging e fazer backup completo. Para voltar, será necessário restaurar o backup da instância anterior.

O relatório corrige tudo sozinho?

Não. Ele pode aplicar algumas correções e salvar novas versões para revisão; outros itens exigem uma decisão ou ajuste manual. Revise ambos os tipos de alerta.

Preciso migrar imediatamente?

Não. O beta é opcional e não é indicado como atualização imediata de produção. Quem usa 2.x pode primeiro avaliar o relatório e aguardar a estabilidade. A linha 1.x tem um prazo de suporte próprio: 31 de dezembro de 2026.

O que fazer agora

O n8n 3.0 beta torna explícitas mudanças que podem afetar nós, arquivos, credenciais e a forma de hospedar a automação. Para profissionais e pequenos negócios, a decisão mais segura começa pelo inventário de workflows e pelo Migration Report na versão 2.x atual. Teste a migração em staging, mantenha um backup completo e só escolha o beta se houver motivo e capacidade de validar o fluxo. Se a produção depende das automações para receber clientes ou cumprir prazos, aguardar a versão estável e confirmar a compatibilidade pode ser a escolha mais adequada.