92 Pipedream workflows in n8n: what imports and what runs
Updated 2026-10-22 · 6 min read
- 84 of 84 non-empty workflows imported into n8n 2.44.5 with no errors.
- In an offline test run, most first errors were missing input, credentials or network, not the conversion.
- The real blockers: Python needs the runner sidecar, npm packages and built-ins need allow-listing.
Pipedream Workflows stops on March 31, 2027. We wanted to know what really happens when real Pipedream workflows land in n8n. So we took every public Pipedream workflow we could find on GitHub, converted each one, imported it into n8n 2.44.5 and ran it.
This page has the results. The raw data, one row per workflow, is on GitHub: aidnurs/pipedream-n8n-migration-data. Run date: October 22, 2026.
The sample
We searched GitHub for files in Pipedream's GitHub Sync format (schema: workflow/2022.04 in workflow.yaml). The search returned 95 files. 3 were test files of our own converter, so we left them out. That leaves 92 workflows from 14 public repositories.
| Measure | Value |
|---|---|
| Workflows | 92 (8 of them have no steps) |
| Steps | 391, median 3.5 per workflow, max 17 |
| Code steps | 266, or 68% of all steps |
| Workflows with at least one code step | 82 of 92 |
| Python steps | 42, in 21 workflows |
| Workflows that import npm packages | 29 (snowflake-sdk in 15) |
| If/else or switch blocks | 0 |
Most workflows come from three repositories:
| Repository | Workflows | Steps | Code steps |
|---|---|---|---|
| mjmena/Trend-Tree | 30 | 172 | 112 |
| cfjedimaster/General-Pipedream-Stuff | 23 | 84 | 62 |
| CPL-Compliance/priority-xero | 14 | 81 | 58 |
| 11 other repositories | 25 | 54 | 34 |
What the code uses
We searched the code of every workflow for the patterns that matter in n8n. Count of workflows, out of 92:
| Pattern in the code | Workflows | In n8n |
|---|---|---|
fetch( |
31 | Not defined in the Code node |
axios |
29 | npm package; not allowed by default |
$.respond( |
27 | Respond to Webhook node |
$.flow.* |
20 | Early return, Wait node or sub-workflow |
AbortController |
18 | Not defined in the Code node |
process.env |
15 | Not defined; move secrets to credentials |
| Data stores | 12 | Data tables |
new URL( / URLSearchParams |
9 | Not defined in the Code node |
Node built-ins (crypto, fs…) |
9 | Blocked until you allow them |
Files in /tmp |
6 | Binary data or a mounted volume |
The trigger is stored only as an id in GitHub Sync files. Its prefix still shows the kind: HTTP 50 workflows, schedule 24, deployed source 21, app subscription 8. The URL, the interval and the app options are not in the file. You set them again in n8n.
Import: 84 of 84
We converted the 84 workflows that have steps with our converter and imported each file with n8n import:workflow into the n8nio/n8n:2.44.5 Docker image. All 84 imported with no errors.
Import is the easy part. The report put 64 of them in yellow (works after a few manual items) and 20 in red (at least one step needs hand work). None of the 84 came out green, because GitHub Sync files never carry trigger settings. Our estimate: about 199 hours of work left after conversion, against about 318 hours to rebuild them by hand. That is a median of 2 hours instead of 3.25 per workflow.
Run: the first error of each workflow
Then we ran each workflow once with n8n execute. The container had no network. The CLI cannot start a workflow from a webhook, so we swapped every Webhook and Schedule trigger for a manual trigger. Every run started with no input, no credentials and no network. That is harsh on purpose: it shows the first thing that breaks.
| Result | Workflows | What it means |
|---|---|---|
| Ran to the end | 8 | |
| Needs real trigger data | 20 | The code expects a request body, such as missing 'query' in request body |
| Python runner missing | 16 | The plain n8n image has no Python. Self-hosted n8n needs the n8nio/runners sidecar |
| Module disallowed | 13 | snowflake-sdk ×4, crypto ×4, date-fns, fast-xml-parser, @atproto/api and others |
| No network | 10 | Expected: the network was off |
| No credentials | 8 | Expected: you create credentials in n8n |
| Step left for manual work | 6 | App actions the converter does not map. Flagged red in the report before import |
| HTTP Request without a URL | 1 | The URL was already empty in the Pipedream workflow |
Dynamic import() |
1 | Not supported in the Code node |
| Timeout after 60 seconds | 1 |
So 38 of the 76 failures come from the test setup: no input, no network, no credentials. Those go away when the workflow runs with real data. The other failures are what you plan your migration around:
- Python. 16 workflows stopped because the default image has no Python. On self-hosted n8n you add the external task runner. On n8n Cloud, Python runs. See Pipedream Python steps in n8n.
- Packages and built-ins. 13 workflows stopped on a blocked module. On self-hosted n8n you install the package in the runner image and allow it. On n8n Cloud only
cryptoandmomentload. See npm packages in n8n. - No
fetch is not definederrors. In our first run on October 21, two workflows failed on it. Our converter now replacesfetchwith a small wrapper around n8n's own HTTP helper. On October 22 no workflow failed onfetch.
Which globals the Code node has
We ran a probe workflow in the same n8n 2.44.5 image with the default JavaScript task runner. You can import it yourself: code-node-globals.json.
| Not defined | Available |
|---|---|
fetch, URL, URLSearchParams, AbortController, structuredClone, Blob, process, global crypto |
require, Buffer, setTimeout, TextEncoder, atob, btoa, FormData, this.helpers.httpRequest |
In the plain image, require('crypto'), require('fs'), require('moment') and require('lodash') all failed with "Module … is disallowed". You allow built-ins with NODE_FUNCTION_ALLOW_BUILTIN and npm packages with NODE_FUNCTION_ALLOW_EXTERNAL. To check a single code step, paste it into the free n8n Code node compatibility check.
Limits of this test
- Not a random sample. Public GitHub Sync repos are what people chose to share. Three repos hold 67 of the 92 workflows.
- No branches. None of the 92 uses if/else or switch blocks, so this test says nothing about them.
- Sync files are not exports. A project export (Project Settings → Export Workflows) has a different format. Neither has secrets or connected accounts.
- First error only. A workflow that stopped on missing input may hit another error later.
The data
The GitHub repo aidnurs/pipedream-n8n-migration-data has:
data/workflows.csvanddata/workflows.json: one row per workflow with step counts, patterns found, report result, run result and first error.data/sources.csv: the 14 repositories and the commit we read.probe/code-node-globals.json: the probe workflow.
The data is free to use under CC BY 4.0. The repo links to each workflow and does not copy its code. We built this test while working on moveworkflows, a paid converter. The report and 1 workflow are free. Full export: $3 per workflow, $1 each after 50, $19 minimum, one-off.
FAQ
Can I download the data?
Yes. The CSV and JSON with one row per workflow are on GitHub at aidnurs/pipedream-n8n-migration-data, under CC BY 4.0. The repo links to each source workflow at a fixed commit and does not copy its code.
Why did only 8 workflows run to the end?
Because the test ran with no network, no credentials and no input. Webhook and schedule triggers were swapped for a manual trigger, so code that expects a request body stops at once. 38 of the 76 failures come from that setup.
Is this sample typical for Pipedream users?
No. It is every public GitHub Sync workflow we could find, and 3 repositories hold 67 of the 92 workflows. None of them uses if/else or switch blocks. Treat it as real examples, not a survey.
How do I check my own workflows?
Run the free report on your Pipedream export. It lists npm imports, Python steps, missing globals and manual items per workflow before you import anything.