O que quebra ao levar as etapas de código do Pipedream para o n8n Cloud

No n8n Cloud, o nó Code só consegue carregar dois módulos, crypto e moment, e o código Python não consegue importar nada, nem mesmo a biblioteca padrão (documentação do nó Code do n8n). As etapas de código do Pipedream que importam axios, date-fns, um SDK ou qualquer outro pacote npm falham até que você os substitua por recursos nativos do n8n, como this.helpers.httpRequest e Luxon, ou migre para o n8n self-hosted com NODE_FUNCTION_ALLOW_EXTERNAL. Os helpers do próprio Pipedream (steps, $.export, $.respond, data stores, process.env) também precisam de equivalentes no n8n.

O Pipedream Workflows está em modo de manutenção desde 30 de setembro de 2026 e para de funcionar em 31 de março de 2027, então até lá cada etapa de código precisa de um novo runtime. O limite do npm é a parte que mais toma tempo, porque o Pipedream deixava usar o npm à vontade: você escrevia import axios from "axios" e o Pipedream instalava o pacote no deploy (documentação de Node.js do Pipedream). Uma pessoa que analisou exportações reais do Pipedream no fórum da comunidade do n8n resumiu assim: "Cerca de 7 em cada 10 etapas de código que eu analisei importam um pacote ou chamam uma API" (comunidade do n8n).

Pipedream vs n8n Cloud vs n8n self-hosted

Recurso	Etapa de código do Pipedream	Nó Code do n8n Cloud	Nó Code do n8n self-hosted
Pacotes npm	Qualquer um, instalado no deploy	Só crypto e moment	Qualquer módulo instalado listado em NODE_FUNCTION_ALLOW_EXTERNAL
Módulos nativos do Node.js (fs, path)	Sim	Não	Se listados em NODE_FUNCTION_ALLOW_BUILTIN
Sintaxe de módulos	import ou require	Só require	Só require
Pacotes Python	Qualquer pacote do PyPI	Nenhum, nem mesmo a biblioteca padrão	Se incluídos na imagem do task runner e liberados na allowlist
Requisições HTTP	Qualquer cliente	this.helpers.httpRequest ou nó HTTP Request	O mesmo, ou um cliente npm liberado
Datas	Qualquer biblioteca	DateTime do Luxon nativo, mais o moment	O mesmo, ou uma biblioteca liberada
Variáveis de ambiente	process.env	$vars no Pro e no Enterprise	$vars no Business e no Enterprise, ou $env se habilitado
Tokens de contas conectadas	this.app.$auth	Nós Code não conseguem ler credenciais	O mesmo
Estado chave-valor	Data stores	Dados estáticos ou Data Tables	O mesmo
Arquivos	/tmp e File Stores	Sem sistema de arquivos	fs se liberado, ou nós de arquivos

Fontes: nó Code, habilitar módulos, problemas comuns.

1. Clientes HTTP: axios, got, node-fetch

O n8n disponibiliza o this.helpers.httpRequest dentro do nó Code (referência de opções). Por padrão, ele retorna o corpo da resposta, o que coincide com o que o axios do @pipedream/platform retornava em caso de sucesso.

Antes, no Pipedream:

import axios from "axios";

export default defineComponent({
  async run({ steps, $ }) {
    const { data } = await axios.get("https://api.example.com/orders", {
      params: { status: "open" },
      headers: { Authorization: `Bearer ${process.env.SHOP_TOKEN}` },
    });
    return data;
  },
});

Depois, em um nó Code do n8n (modo: Run Once for All Items):

const orders = await this.helpers.httpRequest({
  method: "GET",
  url: "https://api.example.com/orders",
  qs: { status: "open" },
  headers: { Authorization: `Bearer ${$vars.SHOP_TOKEN}` },
  json: true,
});

// An item's json must be an object, so wrap the array.
return [{ json: { orders } }];

Os nomes das opções são diferentes dos do axios: params vira qs, e data vira body. Defina returnFullResponse: true quando precisar do status e dos headers; aí você recebe { body, headers, statusCode, statusMessage }.

Para chamadas que usam uma conta conectada, não leve o token para o código. Por design, os nós Code do n8n não acessam credenciais (documentação do n8n). Coloque essa requisição em um nó HTTP Request, escolha o tipo de credencial predefinido do app e deixe o n8n cuidar da renovação do token OAuth. Uma etapa que lia this.github.$auth.oauth_access_token vira um nó HTTP Request com uma credencial do GitHub.

2. Datas: date-fns, dayjs, moment-timezone

O n8n vem com o Luxon, e a documentação de datas dele apresenta o DateTime como a abordagem recomendada. Este exemplo vem do próprio workflow de exemplo do GitHub Sync do Pipedream.

Antes:

import { parseISO, endOfDay } from "date-fns";

export default defineComponent({
  props: { timestamp: { type: "string" } },
  async run({ steps, $ }) {
    return endOfDay(parseISO(this.timestamp)).toISOString();
  },
});

Depois:

const ts = $input.first().json.timestamp; // e.g. "2026-10-13T09:00:00.000Z"
const end = DateTime.fromISO(ts, { zone: "utc" }).endOf("day");
return [{ json: { endOfDay: end.toISO() } }]; // "2026-10-13T23:59:59.999Z"

O date-fns calculava o endOfDay no fuso horário local do servidor. No Luxon, passe um fuso explicitamente para que o resultado não dependa da configuração de fuso horário da instância do n8n.

O formatInTimeZone(parseISO(start), tz, "H:mm") do date-fns-tz vira DateTime.fromISO(start).setZone(tz).toFormat("H:mm"). O moment puro funciona no n8n Cloud com require("moment"), mas o moment-timezone não.

3. steps, $.export e valores de retorno

O Pipedream passa os resultados anteriores em steps. O n8n lê os nós anteriores com $('node name'), e um nó Code precisa retornar um array de itens { json: {...} }.

Antes:

export default defineComponent({
  async run({ steps, $ }) {
    const { email } = steps.trigger.event.body;
    if (!email) return $.flow.exit("no email");
    $.export("domain", email.split("@")[1]);
    return { email };
  },
});

Depois:

const { email } = $('trigger').first().json.body;
if (!email) return []; // no items: downstream nodes don't run, like $.flow.exit
return [{ json: { domain: email.split("@")[1], $return_value: { email } } }];

Os nós seguintes passam a ler {{ $('validate').first().json.domain }} onde o Pipedream usava {{steps.validate.domain}}, supondo que o nó tenha o mesmo nome da etapa do Pipedream. As props de código do Pipedream (this.firstName) não têm equivalente direto: escreva os valores direto no código ou leia-os de um nó Edit Fields posicionado antes do nó Code.

4. $.respond, esperas e suspensões

No n8n, esses são recursos do workflow, não do código:

• $.respond() vira um nó Respond to Webhook, com a opção Respond do nó Webhook definida como "Using 'Respond to Webhook' Node". Faça o nó Code gerar o status e o corpo e depois use esses valores no nó Respond to Webhook. Se o workflow terminar sem chegar a esse nó, o n8n retorna uma mensagem padrão com status 200, enquanto o Pipedream retornava um 400 "No $.respond called in workflow."
• $.flow.delay(ms) significa dividir a etapa em duas, com um nó Wait (After Time Interval) no meio.
• $.flow.suspend() vira um nó Wait com Resume: On Webhook Call.

5. process.env e segredos

Antes: process.env.STRIPE_KEY. Depois, escolha uma destas opções:

• $vars.STRIPE_KEY. As Variables do n8n são strings somente leitura (valores de até 1.000 caracteres), definidas na interface. Estão disponíveis no n8n Cloud Pro e Enterprise e no self-hosted Business e Enterprise.
• $env.STRIPE_KEY no n8n self-hosted. Desde o n8n 2.0, N8N_BLOCK_ENV_ACCESS_IN_NODE vem como true por padrão, então isso só funciona se você mudar para false (breaking changes do n8n 2.0).
• Uma credencial em um nó HTTP Request. Geralmente é o melhor lugar para API keys, e a escolha prática no n8n Cloud Starter, que não inclui Variables.

6. Data stores

Um contador típico no Pipedream, usando uma prop de data store:

export default defineComponent({
  props: { db: { type: "data_store" } },
  async run({ steps, $ }) {
    const count = ((await this.db.get("count")) ?? 0) + 1;
    await this.db.set("count", count);
    return count;
  },
});

O mesmo com os dados estáticos do workflow do n8n:

const store = $getWorkflowStaticData("global");
store.count = (store.count ?? 0) + 1;
return [{ json: { count: store.count } }];

Conheça as diferenças antes de depender disso:

• Os dados estáticos só são salvos quando um workflow publicado roda a partir de um trigger ou webhook. Execuções manuais de teste não os mantêm.
• Eles pertencem a um único workflow. Os data stores do Pipedream podiam ser compartilhados por vários workflows.
• O n8n diz que eles "devem ser pequenos", e não há TTL como em set(key, value, { ttl }).
• Eles só funcionam em nós Code em JavaScript, não em Python.

Para dados compartilhados ou maiores, use as Data Tables do n8n pelo nó Data Table (os nós Code não acessam as Data Tables diretamente; o limite padrão é de 200 MiB por instância), ou um banco de dados externo. De qualquer forma, os registros dos data stores não estão na exportação do Pipedream, então copie-os antes de 30 de abril de 2027.

7. /tmp e File Stores

O Pipedream dava a cada execução um /tmp gravável, e File Stores para guardar arquivos por mais tempo. No n8n Cloud, o nó Code não tem acesso ao sistema de arquivos. Passe os arquivos entre os nós como dados binários, use os nós Convert to File e Extract From File, ou guarde os arquivos no S3 ou no Google Drive. No n8n self-hosted, você pode liberar o fs com NODE_FUNCTION_ALLOW_BUILTIN ou usar o nó Read/Write Files from Disk. Baixe o conteúdo dos File Stores do Pipedream antes do encerramento, porque ele não é exportado.

8. Etapas de código em Python

No n8n Cloud, o nó Code em Python não consegue importar nenhuma biblioteca. No n8n 2.x self-hosted, o Python roda nativamente nos task runners: os imports só funcionam se a imagem n8nio/runners incluir o pacote e ele estiver liberado na allowlist, o código lê _items ou _item em vez de pd.steps, e os campos são acessados com colchetes (item["json"]["email"]). O Python baseado em Pyodide foi removido no n8n 2.0. Se as suas etapas em Python usam principalmente requests, reescrevê-las em JavaScript com this.helpers.httpRequest costuma ser mais rápido.

9. Self-hosted: libere os seus pacotes

Instale os módulos na sua imagem do n8n e depois libere-os:

NODE_FUNCTION_ALLOW_BUILTIN=crypto,fs
NODE_FUNCTION_ALLOW_EXTERNAL=date-fns,lodash,stripe

A documentação do n8n observa que, se a sua instância usa task runners, essas variáveis vão nos task runners, e não no processo principal do n8n. Converta as instruções import em require.

Como o Workflow Exit lida com as etapas de código

O relatório de migração gratuito lista cada pacote npm que cada etapa de código importa e se o n8n Cloud consegue executá-lo, junto com as variáveis de ambiente, os data stores, as chamadas a $.flow e as contas conectadas. Ele roda no seu navegador.

A conversão paga transforma cada etapa Node.js em um nó Code do n8n com uma camada de compatibilidade acima do seu código original. A camada recria steps, $.export, $.flow.exit, as props de this, os data stores (sobre os dados estáticos do workflow), as leituras de process.env (um bloco de segredos no topo do nó Code, ou Variables do n8n nos planos pagos) e as chamadas ao axios do @pipedream/platform, ao axios e ao node-fetch (sobre this.helpers.httpRequest). Ela foi testada executando workflows convertidos no n8n 2.x. Para pacotes que o n8n Cloud não consegue carregar, uma reescrita opcional com IA os substitui por recursos nativos do n8n ou por chamadas HTTP. Blocos Delay viram nós Wait. Uma chamada a $.flow.delay ou $.flow.suspend dentro do código significa que a etapa precisa ser dividida em torno de um nó Wait, então o relatório sinaliza essas etapas, e elas precisam de revisão depois da conversão. As contas conectadas continuam precisando de credenciais do n8n, e o CHECKLIST.md gerado lista cada uma delas.

Os planos começam em US$ 49 para até 25 workflows, e o primeiro workflow é grátis (preços). Para o processo completo, veja o guia de migração do Pipedream para o n8n e, para uma visão geral, Pipedream vs n8n (em inglês). Se você ainda não exportou, comece por exportar seus workflows e depois rode o relatório para ver quantas das suas etapas esbarram nesses limites.