Pipedream vs n8n: a concept-by-concept comparison for migration

Pipedream runs each event through a list of steps that share one steps object, so every step runs once per event. n8n passes arrays of items between nodes, and most nodes run once per item. Pricing units, credentials, webhook URLs, schedules and error handling also differ, which is why a workflow that works in Pipedream can misbehave in n8n until those differences are handled.

This comparison is written for people moving off Pipedream Workflows before it stops running on March 31, 2027 (it has been in maintenance mode since September 30, 2026, and its data is deleted by April 30, 2027). It focuses on what changes during a migration, not on feature checklists.

Side-by-side summary

Concept	Pipedream Workflows	n8n
Unit of work	One event, one execution, each step runs once	Arrays of items; most nodes run once per item
Passing data	steps.name.$return_value, $.export	$('name').first().json, $json
Code	Node.js, Python, Go, Bash steps	JavaScript and Python Code nodes
npm	Any package, installed on deploy	Cloud: crypto and moment. Self-hosted: any allowed module
Credentials	Connected accounts, readable in code via this.app.$auth	Credentials on nodes; Code nodes can't read them
Webhooks	*.m.pipedream.net, any method and path	Test and production URLs per Webhook node, set method and path
HTTP response	Default 200, or $.respond()	Webhook Respond option, or Respond to Webhook node
Schedules	Every N, or cron with timezone	Schedule Trigger, intervals or cron, workflow timezone
Branching	If/Else and Switch blocks that merge at an end phase	If and Switch nodes; branches stay separate unless merged
Delays	Delay action, $.flow.delay, $.flow.suspend	Wait node
State	Data stores, shared across workflows, with TTL	Workflow static data, Data Tables
Errors	Email on unhandled errors, $errors stream, auto-retry	Error workflows, per-node retry and On Error settings
Pricing unit	Credits for compute time per segment	Cloud: per execution. Self-hosted: none
Hosting	Pipedream only	n8n Cloud or self-hosted

Execution model: one event per run vs items

This is the difference that causes the most surprises.

In Pipedream, each trigger event starts one execution, and each step runs once. If a code step returns an array of 50 rows, steps.get_rows.$return_value is one value that happens to be an array. A Slack action after it sends one message.

In n8n, data between nodes is "an array of objects," and nodes process "each item individually" (n8n data structure docs). If a Code node returns 50 items, the Slack node after it sends 50 messages.

Two ways to keep Pipedream's behavior when porting:

• Return a single item that holds the array: return [{ json: { rows } }].
• If a node has already split data into items, add an Aggregate node before the step that should run once.

The Code node has two modes: Run Once for All Items (default) and Run Once for Each Item. Converted Pipedream steps belong in the first mode. Use $('name').first() rather than $('name').item when you mean "the output of that step," since .item follows n8n's item linking and only makes sense when items line up.

The Respond to Webhook node also works on items: it "runs once, using the first incoming data item" (n8n docs).

Data between steps

Pipedream	n8n
{{steps.trigger.event.body.email}}	{{ $('trigger').first().json.body.email }}
{{steps.code.$return_value.id}}	{{ $('code').first().json.id }}, or .json.$return_value.id if the Code node keeps that key
{{steps.code.domain}} (from $.export)	{{ $('code').first().json.domain }}
steps.trigger.context.id in code	$execution.id

Keeping node names identical to Pipedream step names makes these rewrites mechanical.

Pricing models

Pipedream Workflows charged "one credit per 30 seconds of compute time at 256MB" per workflow segment, and did not charge per step (Pipedream pricing docs). Each branch, delay or other control flow block started a new segment, so a workflow with a branch could use two or three credits per run. Registry event sources that triggered a workflow were free.

n8n Cloud charges per workflow execution, "with unlimited steps" (n8n pricing). As of October 2026 the listed plans are Starter at 20€/month for 2,500 executions and Pro at 50€/month for 10,000, both billed annually. Self-hosted Community Edition has no execution fee; you pay for the server and your own time running it.

What that means in practice:

• Long-running workflows (minutes of compute) cost more in Pipedream credits than as a single n8n execution.
• Workflows with branches or delays were several segments in Pipedream and are one execution in n8n.
• Very high-volume, short webhooks deserve a calculation against your n8n plan's execution quota, or a self-hosted instance.

Credentials and connected accounts

Pipedream managed OAuth for you. A step declared an app prop, and code read this.slack.$auth.oauth_access_token. The export keeps only an authProvisionId, and Pipedream deletes the tokens by April 30, 2027 (Pipedream notice).

In n8n you create a credential per app and select it on each node that needs it. Two consequences:

1. Code nodes can't read credentials. n8n blocks this.getCredentials() in the Code node by design (n8n docs). Authenticated API calls that lived in Pipedream code usually move to an HTTP Request node with a predefined credential type.
2. Self-hosted OAuth may need your own app. For some services, such as Google, a self-hosted n8n instance needs an OAuth client ID and secret that you register yourself. Check each credential's page in the n8n docs.

Secrets that were process.env values or secret props go into n8n Variables ($vars, on n8n Cloud Pro and Enterprise or self-hosted Business and Enterprise) or into credentials.

Webhook URLs and HTTP responses

Pipedream: an endpoint like https://<id>.m.pipedream.net, or a custom domain. It accepted any HTTP method and any path on that host, parsed JSON into steps.trigger.event.body, and returned a default 200 OK unless the workflow called $.respond(). The default body limit was 512 KB (Pipedream triggers docs).

n8n: each Webhook node has a test URL and a production URL on your instance, a configured HTTP method and a path (with optional route parameters). The production URL registers when you publish the workflow. The maximum payload is 16 MB, adjustable on self-hosted with N8N_PAYLOAD_SIZE_MAX. The Respond option controls the response: immediately, when the last node finishes, through a Respond to Webhook node, or streaming. Since n8n 1.103.0, HTML responses are wrapped in a sandboxed iframe.

Every service that calls a Pipedream endpoint has to be updated with the new URL. Inventory those senders early, since the change usually happens in third-party dashboards. The free migration report lists every workflow with an HTTP trigger, which gives you the starting list.

Response edge cases differ too. Pipedream returned 400 with "No $.respond called in workflow" if a workflow that uses $.respond never called it. n8n returns a standard 200 message if the workflow finishes without reaching Respond to Webhook, and a 500 if it errors before that node.

Schedules

Both support intervals and cron. n8n's Schedule Trigger uses the workflow timezone if set, otherwise the instance timezone, and only runs after the workflow is published. Its cron field accepts an optional sixth position for seconds. By default, executions missed while an instance is down are not run later.

Branching, delays and sub-workflows

• If/Else in Pipedream could have several rule branches, running the first match. n8n's If node has two outputs; use a Switch node when you need more.
• Merging: Pipedream blocks had an end phase that exported the branch result to later steps. In n8n, branches continue independently. Add a Merge node, or duplicate the shared tail, where the Pipedream workflow continued after the block.
• Delays: the Wait node covers $.flow.delay (After Time Interval) and $.flow.suspend (On Webhook Call).
• Calling other workflows: $.flow.trigger becomes an Execute Sub-workflow node.

Error handling

Pipedream emailed you when a workflow threw an unhandled error, at most once per error per workflow per 24 hours, exposed a global $errors stream you could build a workflow on, and offered automatic retries (Pipedream errors docs).

n8n uses error workflows: build a workflow that starts with an Error Trigger node, then select it as the Error workflow in each workflow's settings. One error workflow can serve all of them. Individual nodes have Retry On Fail and On Error settings (stop the workflow, continue, or continue using an error output), and the Stop And Error node fails an execution on purpose. Set this up before cutover so failures don't go unnoticed.

Code and state

Both platforms run JavaScript and Python, but the environments differ: n8n Cloud allows only crypto and moment, Code nodes use require rather than import, and Pipedream helpers don't exist. Pipedream data stores were shared key-value stores with TTL; n8n offers per-workflow static data and project-scoped Data Tables. The details, with before-and-after code, are in Pipedream code steps on n8n Cloud.

What you gain and what you give up

Gains: self-hosting, per-execution pricing on Cloud, a large library of app nodes, sub-workflows, error workflows and larger webhook payloads.

Losses: arbitrary npm packages on n8n Cloud, Pipedream's managed OAuth for connected accounts used inside code, key-value TTL, endpoints that accept any path and method, and GitHub Sync (n8n lists Git-based version control as an Enterprise feature).

Next steps

Read the Pipedream to n8n migration guide for the full process, or the alternatives comparison if n8n isn't a clear fit. To see how these differences affect your own workflows, export your projects and run the free migration report. It runs in your browser and lists, per workflow, the trigger and its n8n equivalent, npm packages n8n Cloud can't load, connected accounts, redacted secrets and data stores. Automated conversion to n8n starts at $49 for up to 25 workflows, with the first workflow free (pricing).