Atualizado em 3 de agosto de 2026, depois da consulta à documentação oficial das breaking changes.

O n8n 3.0 remove três Nodes usados há anos, exige Docker para instalação self-hosted e desliga o helper $getPairedItem. A versão está prevista para outubro de 2026, e as mudanças alcançam a forma como você instala o n8n, constrói automações e administra segurança.

Esses anúncios apontam para uma direção comum. O n8n está reduzindo caminhos antigos para concentrar o suporte em formas mais definidas de instalar a ferramenta, escrever código e relacionar itens dentro de um workflow. Se os seus ambientes ainda carregam componentes legados, você precisará localizá-los na revisão da próxima atualização.

A diferença entre identificar e migrar define o cuidado necessário agora. Algumas dependências já podem ser encontradas, porém a página oficial ainda promete detalhes e guias. Este artigo preserva esse limite para não transformar um anúncio incompleto em procedimento de atualização.

Direto ao ponto

O n8n 3.0 concentra a implantação self-hosted em Docker, substitui Nodes genéricos por componentes com funções mais específicas e amplia padrões ligados a credenciais e chaves. Essas três mudanças reduzem compatibilidade antiga para manter caminhos técnicos mais definidos.

Comece pela lista de dependências conhecidas. Você já pode localizar instalações por npm ou npx n8n, workflows com Function, Function Item ou Item Lists, expressões com $getPairedItem e chamadas por Execute Workflow. Como a página ainda receberá detalhes e guias, separe as substituições indicadas dos procedimentos que continuam pendentes.

Docker define o caminho self-hosted mantido pelo n8n

A exigência de Docker é o sinal mais claro dessa concentração. Na versão 3.0, a execução por npm e pelo comando npx n8n deixará de receber suporte. Se o seu ambiente ainda é iniciado diretamente pelo Node.js, você precisará mudar a forma de implantação para atualizar.

Essa escolha coloca imagem, persistência e atualização sobre a mesma base suportada, reduzindo as variações que a documentação e a manutenção do n8n precisam considerar. Para você, a consequência aparece no registro de cada cliente: cada ambiente precisa mostrar como o processo é iniciado e onde ficam os arquivos e o banco usados pela instalação.

A documentação cita o Docker Compose como a opção provavelmente mais simples para uso local e informa que o procedimento detalhado ainda será publicado. Neste momento, identifique as instalações por npm ou npx n8n e aguarde o guia oficial para executar a troca. Quando a versão estiver disponível, a migração precisará de backup conferido e teste em ambiente separado.

Esse trabalho de infraestrutura merece estudo próprio porque o container não substitui persistência, backup nem recuperação. A Trilha DevOps aprofunda a relação entre servidor, Docker e manutenção que você assume ao hospedar aplicações para clientes.

Function e Item Lists dão lugar a Nodes específicos

Nos workflows, a redução de caminhos antigos aparece na retirada de três Nodes. A documentação técnica do n8n explica como a ferramenta coordena um evento até o resultado da automação. Na página oficial da versão 3.0, Function, Function Item e Item Lists aparecem entre os Nodes que serão removidos.

O destino de Function e Function Item será o Code node, mas o modo de execução preserva uma diferença importante. Run Once for All Items recebe o conjunto de itens em uma execução. Run Once for Each Item executa o código separadamente para cada item. Tratar essa troca como simples mudança de nome pode alterar a entrada disponível ao código e mudar a saída do workflow.

No Item Lists, o destino depende da configuração atual. Split Out separa valores que estavam dentro de um item. Aggregate e Summarize combinam ou resumem valores, enquanto Sort, Limit e Remove Duplicates alteram a composição da lista. Os nomes específicos permitem reconhecer a função daquela etapa diretamente no editor.

Na revisão, compare a entrada atual, a configuração do Item Lists e a saída esperada. Um workflow que termina sem erro ainda pode produzir uma lista diferente se a agregação, a ordenação ou o limite forem reconstruídos com outra configuração. A conferência precisa chegar aos itens resultantes, em vez de parar no sinal verde da execução.

Item linking exige conferir a relação entre entrada e saída

O helper depreciado $getPairedItem também será removido. A orientação oficial aponta para o item linking padrão por meio de pairedItem ou de uma expressão como $("<node-name>").item, conforme a forma usada para recuperar o item relacionado.

Esse ponto merece atenção porque a ligação entre itens pode falhar sem produzir um erro óbvio. O workflow executa, o Node devolve conteúdo e a expressão encontra um valor, mas esse valor pode pertencer a outro item da entrada. Em uma automação comercial, essa diferença pode associar um campo ao contato errado mesmo quando todas as etapas aparecem concluídas.

A verificação útil compara pares conhecidos. Você escolhe entradas com valores distintos, acompanha a saída e confirma se cada resultado preserva a relação esperada. Esse teste ainda dependerá da versão e do workflow real, porém a lista de usos de $getPairedItem já pode mostrar quais automações merecem essa conferência.

Execute Workflow ainda tem uma lacuna importante

A documentação informa que o comportamento antigo do Execute Workflow será removido, mas não explica qual comportamento está sendo tratado nem como a conversão funcionará. Essa lacuna precisa ficar separada das substituições já conhecidas para que uma linha do anúncio não vire orientação inventada.

Hoje, você já pode localizar workflows que chamam outros workflows e registrar o payload recebido, o comportamento de espera e a saída que alimenta a etapa seguinte. Esse material oferece uma base de comparação quando os detalhes forem publicados, sem alterar produção agora.

A mudança só deve ser definida depois da documentação completa e de um teste da versão 3.0 em ambiente separado. Até lá, trate qualquer instrução sobre opção, modo de espera ou formato de entrada como hipótese, não como procedimento.

Segurança aparece no anúncio antes dos detalhes

A versão 3.0 também anuncia tratamento mais restrito para nomes considerados arriscados em recursos. Credenciais terão um comportamento revisto, e a rotação de chaves virá habilitada por padrão. A página ainda não explica quais configurações serão alteradas nem o que você precisará revisar durante a atualização.

Esse grupo aponta para outra redução de comportamentos permissivos acumulados ao longo do tempo. O anúncio mostra a direção, mas ainda não oferece a especificação necessária para orientar uma mudança em produção. Por isso, evite transformar frases gerais sobre segurança em comandos, variáveis ou promessas de proteção automática.

Essa lacuna merece registro em cada ambiente que você mantém. Você precisará comparar a chave de criptografia, as credenciais salvas e os nomes usados nos recursos com o guia futuro. No Plano Martech, essa responsabilidade técnica aparece ligada à automação entregue ao cliente, porque o workflow continua dependendo da forma como o ambiente guarda acesso e recebe manutenção.

Recursos descontinuados reduzem outras superfícies mantidas

O Chat Hub será retirado, e a importação de workflows por URL deixará de existir dentro do editor. Para importar um workflow, a documentação preserva a cópia e colagem, o arquivo local, a interface de linha de comando e a Public API como alternativas.

Cada forma de importação exige suporte, precisa acompanhar mudanças do editor e ainda carrega falhas próprias. Quando o n8n remove uma entrada antiga e mantém caminhos que já fazem parte do produto, a manutenção fica concentrada nas opções que continuarão documentadas.

A página também informa que Nodes sem funcionamento serão removidos, mas não apresenta seus nomes. Completar essa lista com memória de versões anteriores ou relatos de terceiros criaria uma certeza que a fonte ainda não oferece. Essa lista só pode avançar nesse ponto quando a relação oficial estiver disponível.

O que você já pode identificar nos ambientes atuais

Comece pela forma de implantação. Cada ambiente precisa mostrar se o n8n está em Docker ou se ainda depende de uma instalação iniciada por Node.js. Essa informação separa os clientes que já usam a base exigida daqueles que precisarão de uma mudança estrutural.

Nos workflows, procure Function e Function Item porque os dois serão substituídos pelo Code node, com modos de execução diferentes. Em outra busca, localize Item Lists e $getPairedItem, cujas substituições dependem do uso atual. Nas chamadas por Execute Workflow, registre a entrada, a espera e a saída. Esse material não executa a migração, mas mostra onde um teste da versão 3.0 deverá comparar comportamento e resultado.

Por fim, separe as partes que a página ainda descreve de forma geral. Credenciais e chaves ficam no grupo de segurança. Nomes considerados arriscados, Nodes sem funcionamento e o comportamento antigo de Execute Workflow permanecem como pendências sem procedimento publicado. Se esses itens forem escondidos dentro de uma tarefa chamada apenas “atualizar n8n”, você perde a diferença entre trabalho conhecido e investigação futura.

A migração ainda depende da próxima versão da documentação

O anúncio atual oferece substituições claras para alguns Nodes e alternativas para a importação por URL. Em outros pontos, ele informa somente que o comportamento mudará. Essa diferença define duas colunas na lista de acompanhamento: dependência conhecida e procedimento ainda não publicado.

A própria página informa que receberá detalhes, guias de migração e links conforme a versão 3.0 se aproximar. Como o lançamento está previsto para outubro de 2026, uma nova conferência da fonte será necessária na atualização deste artigo e na preparação de qualquer janela de manutenção com cliente.

Quando a versão estiver disponível, o próximo trabalho será testar em ambiente separado, preservar backup e comparar as saídas dos workflows selecionados. Até lá, a contribuição mais útil deste anúncio está em mostrar a direção do n8n e revelar onde cada instalação ainda depende de caminhos antigos.

Eu vou acompanhar essas mudanças porque elas afetam tanto a ferramenta quanto a responsabilidade de mantê-la para clientes. Você que administra n8n para clientes tem o mesmo motivo para acompanhar: entre no Discord da Promovaweb para discutir os detalhes conforme forem publicados.