Do que 395 workflows reais do Pipedream precisam para rodar no n8n

Analisamos 395 workflows públicos do Pipedream e 746 etapas de código para ver o que a mudança para o n8n envolve. A resposta curta: workflows do Pipedream são, em grande parte, código. Dos workflows de repositórios do GitHub Sync, 88% têm pelo menos uma etapa de código, e 61% das etapas de código em JavaScript importam um pacote ou chamam uma API. No n8n Cloud, onde o nó Code só consegue carregar crypto e moment (documentação do n8n), é essa a parte que dá trabalho.

Os dados também mostram que a mudança é viável. Todos os 395 workflows foram convertidos em JSON de workflow do n8n, e o n8n 2.43.4 importou cada um deles. Dos 172 workflows completos do GitHub Sync, 9% não precisaram de nada, 66% precisaram de uma reescrita com IA de uma etapa de código ou de uma revisão rápida, e 24% tinham pelo menos uma parte que precisa ser resolvida por uma pessoa.

O Pipedream Workflows para de funcionar em 31 de março de 2027, e todos os dados do Workflows, incluindo as contas conectadas, serão apagados até 30 de abril de 2027. Esses números podem ajudar você a dimensionar a sua própria migração.

Principais conclusões

• Código é a regra. 88% dos workflows do GitHub Sync têm uma etapa de código, e as etapas de código são 69% de todas as etapas deles.
• A maior parte do código depende de algo externo. 61% das etapas em JavaScript importam um pacote npm ou fazem uma chamada HTTP. Isso fica perto de uma estimativa feita na comunidade do n8n: "about 7 in 10", ou seja, cerca de 7 em cada 10.
• O n8n Cloud é o gargalo. 30% das etapas em JavaScript importam módulos que o nó Code do n8n Cloud não consegue carregar, e 45% dos workflows têm pelo menos uma etapa assim.
• Etapas em Python quase sempre importam algo. 89% das etapas em Python importam módulos. O Python do n8n Cloud não consegue importar nada, nem mesmo a biblioteca padrão.
• Clientes HTTP lideram a lista. 26% das etapas em JavaScript usam o axios do @pipedream/platform, 13% chamam fetch e 8% importam axios. Todos eles têm equivalentes nativos no n8n.
• Webhooks iniciam a maioria dos workflows. 53% dos workflows do GitHub Sync têm um trigger HTTP, então as URLs deles mudam na migração.
• Há credenciais por toda parte. 65% dos workflows usam contas conectadas, e 34% leem o token de uma conta diretamente no código, algo que os nós Code do n8n não conseguem fazer.
• O estado precisa ser salvo. 17% dos workflows usam data stores do Pipedream, cujos registros não estão na exportação.

Os dados

Fonte	Tamanho	O que mostra
Repositórios públicos do GitHub que usam o GitHub Sync do Pipedream	172 workflows e 703 etapas, de 48 repositórios de 37 proprietários	Workflows completos: triggers, ações de apps, ramificações e código
Templates públicos compartilhados por links do Pipedream	223 workflows, 721 etapas	Triggers e ações de apps. Código personalizado não faz parte de um template compartilhado
Etapas de código publicadas em repositórios públicos e gists	279 arquivos (230 em Node.js e 49 em Python), de 93 repositórios e 34 gists	Só código

No total, são 395 workflows e 746 etapas de código que conseguimos ler: 638 em JavaScript e 108 em Python. Coletamos tudo em 13 de outubro de 2026, sem conta no Pipedream e só de fontes públicas. A análise usou o mesmo analisador que roda no nosso relatório de migração gratuito e na CLI de código aberto.

1. Etapas de código são a regra

Workflows do GitHub Sync (172)	Percentual
Têm pelo menos uma etapa de código	88% (151)
Etapas que são etapas de código	69% (482 de 703)
Etapas que são ações de apps	29% (201)
Etapas que são blocos de controle de fluxo (if/else, switch, filter, delay)	3% (20)
Têm uma etapa em Python	17% (29)

Um workflow típico é curto: a mediana é de 3 etapas, e o mais longo tem 18. No n8n, cada etapa de código vira um nó Code. Mesmo o código sem pacotes precisa ser traduzido, porque o nó Code não tem steps, $.export nem $.respond e não aceita instruções import ou export. O guia de etapas de código cobre cada diferença.

2. A maior parte do código importa um pacote ou chama uma API

Das 638 etapas de código em JavaScript:

O que o código faz	Percentual das etapas
Importa um pacote npm ou faz uma chamada HTTP	61% (390)
Faz uma chamada HTTP	47% (302)
Importa um pacote npm	29% (187)
Importa algo que o nó Code do n8n Cloud não consegue carregar	30% (189)

Os imports mais comuns e o que os substitui no n8n Cloud:

Pacote	Etapas	No n8n Cloud
axios (do @pipedream/platform)	167	this.helpers.httpRequest
fetch (nativo do Node.js)	86	this.helpers.httpRequest
axios	48	this.helpers.httpRequest, ou um nó HTTP Request
snowflake-sdk	24	Nó Snowflake
googleapis	15	Os nós dos apps do Google, ou HTTP Request com uma credencial do Google
openai	9	Nó OpenAI, ou HTTP Request
@google/generative-ai	6	Nó Google Gemini
@supabase/supabase-js	6	Nó Supabase, ou HTTP Request para a API REST
@pipedream/google_drive, @pipedream/dropbox, @pipedream/github e outros pacotes de apps do Pipedream	26	O nó do app no n8n, ou HTTP Request
node-fetch, form-data	5 cada	Nó HTTP Request (ele também monta corpos multipart)
date-fns	4	DateTime do Luxon, nativo no nó Code
uuid	4	crypto.randomUUID()

Agrupados pelo que você faria com eles, os pacotes se dividem em três grupos de tamanho parecido. Há 76 imports com um substituto nativo no n8n (clientes HTTP, bibliotecas de datas, utilitários), 77 são SDKs de APIs que viram chamadas HTTP ou nós de apps, e 93 precisam de reescrita ou do n8n self-hosted, onde você pode liberar os pacotes instalados com NODE_FUNCTION_ALLOW_EXTERNAL. Exemplos: parsers de HTML como o cheerio, o @ffmpeg-installer/ffmpeg, bibliotecas de blockchain como o ethers e navegadores headless (@pipedream/browsers).

3. Helpers do Pipedream que precisam de um equivalente no n8n

Helper nas etapas em JavaScript	Percentual das etapas	Equivalente no n8n
$.export(...)	41%	Campos no item de saída do nó Code
steps.<name> (lê outra etapa)	29%	$('<node name>').first().json
this.<app>.$auth (token de conta conectada)	24%	Uma credencial em um nó HTTP Request ou no nó do app. Nós Code não conseguem ler credenciais
process.env	16%	$vars (Variables do n8n) ou $env no n8n self-hosted
$.flow.exit()	11%	return [], ou um nó If
$.respond()	11%	Nó Respond to Webhook
Data stores	7%	Dados estáticos do workflow ou Data Tables do n8n
$.flow.delay, $.flow.suspend, $.flow.rerun	2%	Nó Wait; $.flow.rerun não tem equivalente
/tmp ou File Store	2%	Dados binários ou armazenamento externo

O guia de migração mapeia cada um deles, com exemplos de expressões.

4. Etapas em Python

Das 108 etapas em Python, 89% importam pelo menos um módulo e 70% importam um pacote de terceiros. O requests, sozinho, aparece em 52%. As etapas em Python só rodam no n8n Cloud se não importarem nada, então, na prática, elas são reescritas em JavaScript ou levadas para o n8n self-hosted com o task runner de Python. Veja Etapas em Python do Pipedream no n8n (em inglês).

5. Triggers

Trigger	Workflows do GitHub Sync (172)	Templates (223)
HTTP / webhook	53%	31%
Fonte de eventos de um app (nova linha, novo e-mail…)	27%	38%
Agendamento (schedule)	23%	15%
E-mail (endereço @pipedream.net)	2%	3%

Os percentuais somam mais de 100% porque alguns workflows têm vários triggers. Os triggers HTTP viram o nó Webhook do n8n, mas a URL muda, então cada serviço que envia webhooks precisa receber a nova; os detalhes estão no guia de webhooks (em inglês). Os agendamentos são convertidos diretamente, como mostra o guia de agendamentos (em inglês). As fontes de eventos de apps viram o nó trigger do app no n8n, quando ele existe, ou um agendamento que consulta a API periodicamente.

6. Contas conectadas e apps

65% dos workflows do GitHub Sync usam pelo menos uma conta conectada; no total, aparecem 41 apps diferentes. Desses apps, 29 (71%) têm um nó nativo no n8n; os demais funcionam pelo nó HTTP Request do n8n com uma credencial. As contas conectadas não são transferidas: os tokens OAuth delas são apagados junto com o restante dos dados até 30 de abril de 2027, então cada uma precisa ser autorizada de novo no n8n.

Nos templates, 43% das ações de apps (108 de 251) são mapeadas automaticamente para um nó nativo do n8n com a mesma operação. O restante é convertido em nós HTTP Request ou sinalizado para revisão.

7. Como os workflows foram convertidos

Convertemos cada workflow com o Workflow Exit e importamos o resultado no n8n 2.43.4 com o próprio comando import:workflow do n8n. Todos os 395 foram importados: os 223 templates e os 172 workflows do GitHub Sync, tanto na versão para o n8n Cloud quanto na versão self-hosted.

De quanta revisão os workflows do GitHub Sync precisaram, segundo as três classificações do relatório:

Classificação	Workflows
🟢 Convertido automaticamente, nada para revisar	9% (16)
🟡 Uma reescrita com IA de uma etapa de código, ou uma revisão rápida	66% (114)
🔴 Pelo menos uma parte exige trabalho manual	24% (42)

As classificações vermelhas vieram quase todas de pacotes npm que o n8n Cloud não consegue carregar (36 dos 42 workflows). O restante veio de código ausente nos arquivos (3), componentes privados (2), uma etapa que não pôde ser analisada e uma chamada a $.flow.rerun. Os motivos mais comuns para uma classificação amarela foram código que lê tokens de contas conectadas (59 workflows), ações de apps a mapear manualmente para um nó do n8n (49), etapas em Python com imports (29) e data stores (29).

Estimativa de esforço. Para os mesmos 172 workflows, o nosso relatório estima cerca de 680 horas para recriá-los à mão e cerca de 150 horas com o conversor, principalmente para revisão, credenciais e testes. É um modelo aproximado, não uma medição: ele conta meia hora para recriar e testar cada workflow, e mais tempo para cada etapa de código, pacote, etapa em Python e trigger incomum.

O que isso significa para a sua migração

1. Olhe o código primeiro. Nove em cada dez workflows têm código, e é esse código que define a maior parte do esforço e a escolha entre n8n Cloud e self-hosted.
2. Escolha entre n8n Cloud e self-hosted por projeto. Etapas que só fazem chamadas HTTP ou lidam com datas rodam no n8n Cloud depois de reescritas. SDKs, parsers e bibliotecas Python são mais fáceis no n8n self-hosted.
3. Liste agora as suas contas conectadas e variáveis de ambiente. Valores e tokens não são exportados. Copie os segredos do Pipedream antes do encerramento.
4. Salve os registros dos data stores antes de 30 de abril de 2027. Um em cada seis workflows usa um data store. Veja data stores e arquivos do Pipedream (em inglês).
5. Planeje a troca dos webhooks. Metade dos workflows começa com um trigger HTTP, e cada serviço que envia webhooks precisa da nova URL do n8n.

Para ter esses números dos seus próprios workflows, exporte-os e arraste o ZIP para o relatório de migração gratuito. Ele roda no seu navegador e classifica cada workflow do mesmo jeito.

Metodologia e limitações

• Fontes. Só dados públicos: repositórios do GitHub com arquivos do GitHub Sync do Pipedream, templates publicados por links de compartilhamento do Pipedream e etapas de código publicadas em repositórios e gists. Workflows privados podem ser diferentes: provavelmente têm menos projetos de demonstração e mais apps de negócios.
• Concentração. Um único repositório tem 35 dos 172 workflows do GitHub Sync, a maioria usando o Snowflake. Isso eleva os números do Snowflake.
• Templates. Os templates compartilhados contêm triggers, ações de apps e configurações, mas não código personalizado, então as estatísticas de código usam só os workflows do GitHub Sync e os arquivos de código avulsos.
• O que "não roda no n8n Cloud" significa. Uma etapa em JavaScript que importa qualquer coisa além de crypto ou moment (pacotes npm e módulos nativos do Node.js, como fs), ou uma etapa em Python que importa qualquer módulo. Não inclui as mudanças no wrapper e nos helpers de que toda etapa de código do Pipedream precisa.
• Contagem. Um pacote conta uma vez por etapa que o importa. Os percentuais são arredondados.

Esta análise foi feita pelo Workflow Exit (em inglês), uma ferramenta independente que converte workflows do Pipedream para o n8n. Não temos vínculo com o Pipedream, a Workday ou o n8n.