Migrating off Pipedream Workflows

1. Why Pipedream users are moving, and what to move to

1.1 The shutdown

Pipedream Workflows and String stop on March 31, 2027; all Workflows data, including credentials and OAuth tokens, is deleted by April 30, 2027. Workflows is in maintenance mode, closed to new signups and subscriptions, with no new features. Subscriptions are canceled on the shutdown date with a prorated refund. Pipedream Connect, the integration layer for AI agents, continues; that is where the company is going (Pipedream’s notice).

The practical consequence is a project with a fixed end date and a hard floor: every workflow that matters has to be running somewhere else by the end of March, and anything you have not exported by the end of April is gone.

1.2 Choosing what to move to

Ask three questions of every option on your shortlist, including Kestra.

1. Does it run your code, or only its own connectors? Most Pipedream estates lean on Node.js and Python steps. A no-code tool makes you rewrite that logic into blocks; a code-only tool makes you rebuild the connectors. You want both in one place.

2. Who holds the credentials? In Pipedream, OAuth grants lived inside Pipedream’s workspace, which is why they cannot be exported. If the next platform does the same, the next migration costs the same.

3. How hard would it be to leave? Where do definitions live, can you read them without the product, and can you run the engine yourself if the commercial relationship ends? On Pipedream, definitions and grants lived in its workspace and the engine was never yours to run, which is why this migration is as much work as it is.

For workflows that are mostly connectors with little code, a connector-first tool such as Zapier, Make or n8n fits, as long as you accept the answers it gives to questions 2 and 3. For workflows that are mostly code and API calls with a few connectors, Kestra does. One estate can land in more than one place: the team in 2.2 moved a few workflows to AWS Lambda. The comparison of Pipedream alternatives puts Zapier, Make, n8n, Temporal, Windmill and Kestra side by side.

1.3 Why Kestra Cloud

It runs your code. Node.js, Python and Bash steps copy into script tasks; what changes is how they read their input and return their results. Go steps run in a Go Script task. The 2,300+ plugins cover the data, infrastructure and notification systems most code steps call, and an HTTP task covers the rest.

You own the credentials. Secrets live in a managed secret manager scoped by namespace, referenced from flows and never in Git. You re-enter them once, with your own OAuth clients and API tokens, and they are portable from then on.

It is managed, and it is open. Kestra Cloud is run by the team that builds Kestra: hosting, scaling, upgrades, backups, SSO, RBAC, audit logs, Apps and remote runners, with a 14-day trial and no credit card. The core underneath is Apache 2.0 and the flows are YAML in your repository. If a vendor retires a product again, you keep running the same flows self-hosted the next day.

The economics are legible. No credits per 30-second slice and no memory tuning per workflow. Plugin tasks such as an HTTP call, a Slack message or a database query count as one task run and use no compute time; only script tasks that run on the Kestra Cloud task runner add compute. Send scripts to your own AWS, GCP or Azure runners and that compute is billed by your cloud provider, not by Kestra Cloud. Task runs and compute are reported in your instance.

For the full feature-by-feature view, see Kestra vs Pipedream.

Start your Cloud trial

1.4 What your security and finance reviewers will ask

The questions that stall a Pipedream migration come from the finance owner and the security reviewer, not from the workflow list: who can see the finance flows, how long the audit trail is kept, whether SSO is SAML or OIDC, where the data runs, and what the contract says. Kestra Cloud answers them with namespace-scoped RBAC, audit logs, SSO, SOC 2 Type 2 and GDPR attestations on the Trust Center, a data processing agreement, and remote runners that keep execution inside your own cloud account.

2. The migration in four stages

The four stages below are the sequence teams leaving Pipedream are following now. The first takes days; the second fits inside the 14-day trial.

2.1 Pipedream keeps running until each wave is cut over

Nothing in Pipedream changes until the Kestra flow has handled real events. Every wave stays reversible until you disable its Pipedream trigger, and the subscription keeps running until the last one. The overlap costs your team’s time and the Pipedream subscription you would have canceled anyway at the end of March.

2.2 One migration in progress

3. Stage 1, Assess: what moves, and what you export

3.1 What moves, what stays

A Pipedream workflow bundles three things most platforms separate: an endpoint that receives events, a runtime for your code, and a catalog of pre-built actions with managed auth. The systems around it (NetSuite, Box, Google Workspace, Slack, your database, AWS) stay where they are. What moves is the orchestration layer and the glue code written for it.

Split your estate into seven parts and give each one a verdict: replace (Kestra takes it over), re-create (the export does not carry it, so you enter it again), keep (the system stays and gets called), retire (nothing replaces it).

The difference between the Pipedream model and Kestra is who owns the integration: Pipedream held your tokens inside its workspace, Kestra reads them from a secret manager you control.

3.2 Pipedream to Kestra: concept mapping

Every Pipedream construct has a Kestra equivalent, and most of them keep the same shape. The differences that cost time are three: outputs are declared instead of returned, control flow is a task rather than a step type, and credentials live outside the flow.

3.3 Export your workflows today

Export before you decide anything else. The export is the only record of your workflow logic that survives April 30. If you never connected Pipedream’s GitHub Sync, it is also the first copy of your workflows outside Pipedream.

1. Open the project in the Pipedream dashboard and select Settings in the left navigation.
2. Click Export Workflows at the bottom of the settings panel. Pipedream builds the archive in the background.
3. Download project_export-<project_id>.zip from the project’s File Store (your plan must include File Stores).
4. Repeat for every project. One export holds at most 500 workflows or 256 MB; if truncated is true in manifest.json, move workflows to another project and export again.
5. Commit the archives to a Git repository. This is your source of truth for the migration.

What the archive contains. One JSON file per deployed workflow (schema workflow.json/2026.01) with its triggers, steps in order, code for code steps, component key and version for actions, configured props and control-flow branches. manifest.json lists every workflow with a status (exported, skipped_never_deployed, skipped_export_limit) and a warnings list naming each prop you will have to re-enter.

What it does not contain, and what you must collect separately:

Source: Pipedream export documentation.

While you are in the dashboard, note what the export will not give you: monthly volume and peak concurrency. The Usage chart in Pipedream’s billing settings shows daily credits; click a day to see them broken out by workflow, and note the busiest workflows over a full billing period. For each of those, filter the event history by workflow and count its executions over a range your plan still keeps (a busy week is enough for a high-volume workflow), scale that count to a month, then open one execution to see the steps it runs. Note when traffic peaks and the concurrency setting in the workflow’s settings. Executions per month times steps per execution is your monthly step count. These numbers size your Kestra Cloud plan and your concurrency limits.

3.4 Triage before you convert

The raw count from manifest.json is always higher than the real work. Three passes get you to a defensible number.

Then rank what is left by two criteria, and convert in that order:

1. Business criticality: finance processing, HR sync and anything with a month-end deadline go first, because they need a full cycle of testing before March.
2. Conversion cost: count the code steps and the actions without a Kestra plugin. A workflow with 40 steps and a NetSuite call takes far longer than a timer plus one Python step.

For each remaining workflow, record four things in your tracker: trigger type, number of code steps, external systems called, and whether it writes to a Data Store. Those four columns decide the pattern you convert it with.

Decide your fallback now. Workflows at the bottom of the list may not make the deadline. Agree with the business owner whether each one gets a manual procedure for a month or is simply switched off, so nobody discovers a gap on April 1.

4. Stage 2, Trial: prove the pattern on Kestra Cloud in 14 days

Request trial access with your export in hand.

Before it starts, agree on three things with the people who own the workflows: which two or three workflows you convert, what “it works” means for each one (same output as Pipedream on the same input), and who reviews the result.

Choose the workflows from the triaged backlog in 3.4:

1. One difficult workflow you would run in production: many steps, a long external call, a Data Store. A happy-path webhook proves nothing.
2. One the business owner recognizes: a finance file, a staff sync.
3. One scheduled workflow, so the trial covers timers as well as webhooks.

What the trial proves

SSO and audit logs are on from day one of the trial, along with custom roles, the managed secret manager, Apps, the AI Copilot and the Playground. With role-based access, the finance owner can follow the trial from a read-only role, and the trial becomes part of the security review. Trials run 14 days by default; teams that share feedback get longer.

Start your Cloud trial

Talk to our team

5. Stage 3, Migrate: convert by pattern, with Pipedream still running

5.1 Convert a workflow

The most common Pipedream pattern is an HTTP trigger, a code step that reshapes the payload, a call to a business system, and a notification. In Pipedream that is four steps and a connected account. In Kestra it is one flow, and the code step is copied almost unchanged.

Before (Pipedream, from the export): an http trigger, a Python step transform that returns invoice_id, amount and vendor, a NetSuite action configured with a connected account, and a Slack send_message action.

After (Kestra flow):

id: invoice_intake
namespace: finance.intake
description: Replaces the Pipedream "Invoice intake" workflow (p_abc123).

triggers:
  - id: webhook
    type: io.kestra.plugin.core.trigger.Webhook
    key: "{{ secret('INVOICE_WEBHOOK_KEY') }}"
    allowConcurrent: true

tasks:
  - id: transform
    type: io.kestra.plugin.scripts.python.Script
    dependencies:
      - kestra
    script: |
      from kestra import Kestra
      import json
      body = json.loads(r'''{{ trigger.body | toJson }}''')
      # code copied from the Pipedream step; only the input read and the export change
      Kestra.outputs({
          "invoice_id": body["id"],
          "amount": round(float(body["total"]), 2),
          "vendor": body["vendor"]["name"],
      })

  - id: post_to_netsuite
    type: io.kestra.plugin.core.http.Request
    uri: "https://{{ secret('NETSUITE_ACCOUNT') }}.suitetalk.api.netsuite.com/services/rest/record/v1/vendorBill"
    method: POST
    contentType: application/json
    headers:
      Authorization: "Bearer {{ secret('NETSUITE_TOKEN') }}"
    # abridged: a real request also sends the vendor ("entity", by internal ID) and the bill's lines
    body: |
      {
        "tranId": "{{ outputs.transform.vars.invoice_id }}",
        "total": {{ outputs.transform.vars.amount }}
      }
    timeout: PT15M
    options:
      timeout:
        readIdleTimeout: PT10M

  - id: notify
    type: io.kestra.plugin.slack.notifications.SlackIncomingWebhook
    url: "{{ secret('SLACK_WEBHOOK') }}"
    messageText: "Invoice {{ outputs.transform.vars.invoice_id }} from {{ outputs.transform.vars.vendor }} posted to NetSuite"

errors:
  - id: alert
    type: io.kestra.plugin.slack.notifications.SlackIncomingWebhook
    url: "{{ secret('SLACK_WEBHOOK') }}"
    messageText: "Invoice intake failed: {{ execution.id }}"

Five things to notice:

1. Input and return. The Python code is the body of the Pipedream step’s handler. It reads the payload from {{ trigger.body }} instead of pd.steps["trigger"]["event"]["body"], and return becomes Kestra.outputs(). The kestra package that provides Kestra.outputs() is not in the default Python image, so the task lists it under dependencies.
2. Slow API. The NetSuite call may sit idle for ten minutes while it waits for a response (the default is five minutes), because NetSuite sometimes takes several minutes to answer. The task timeout caps the whole call.
3. Concurrency. The trigger sets allowConcurrent: true, so an invoice that arrives during a slow call starts its own execution.
4. Errors. The errors block replaces the per-step error handling you built by hand.
5. Token. The static NETSUITE_TOKEN secret keeps the example short. In production, fetch a fresh token in the flow (see 5.2).

Convert with the AI Copilot. Kestra Cloud includes an AI Copilot that generates and edits flow YAML from a prompt. Paste a workflow’s JSON from the export, ask for the equivalent flow, and review the result; nothing is deployed without a human. For bulk work, connect your own AI coding assistant to the Kestra MCP server, which gives it live plugin schemas, blueprints and docs, open the export folder in it, and commit the drafts to Git for review. Treat the output as a first draft: conditions, loops and code-step outputs are where the two dialects differ most, and those are what the review checks.

Convert by pattern, not by workflow. Most of a Pipedream estate is five patterns: webhook → code → API, timer → fetch → load, file arrives → process → notify, poll an app → sync records, and approval chains. Build one clean flow per pattern, save it as a custom blueprint, and convert the rest by changing inputs and secrets.

5.2 Reconnect credentials, secrets and state

This is the step teams underestimate, because in Pipedream it was a button. Every connected account was an OAuth grant held in Pipedream’s workspace, and none of it travels. The warnings list in manifest.json is your checklist.

1. List the apps. From the export, collect every distinct app prop and authProvisionId. Group them by system: one NetSuite, one Box, one Google Workspace account usually serve many workflows.
2. Create credentials where you own them. For OAuth apps, register your own OAuth client (Google, Box, Slack, NetSuite) or generate an API token (Mailgun, Monday). NetSuite OAuth 2.0 access tokens are valid for 60 minutes, so do not store the token itself. NetSuite’s client credentials (machine-to-machine) flow uses a certificate, not a client secret. Store the client ID, the certificate ID and the certificate’s private key as secrets, and have a short script task at the start of the flow sign the JWT assertion and request a fresh token. Sign it with PS256 or ES256; NetSuite does not accept RS256. Keep the token out of Kestra.outputs(), because task outputs are stored in clear text and shown on the execution page. Make the NetSuite call from the same script, or emit the token as an encrypted output (::{"encryptedOutputs":{"token":"..."}}::), which Kestra Cloud stores and displays encoded. You now own the grant, which is what makes the next migration cheap.
3. Store them in the Kestra secret manager, scoped to the namespace that needs them. Finance secrets live under finance.*, visible only to the roles you assign; set allowedNamespaces on finance so flows elsewhere cannot read them. Reference them in flows with {{ secret('NAME') }}; nothing lands in Git.
4. Move state. Export each Data Store with Pipedream’s chunked-export example, with shouldDeleteKeys set to false so live workflows keep their data, and load it into the KV Store with a one-off flow. Replace the Data Store calls in code (this.<store>.get() and .set() in Node.js, pd.inputs["data_store"] in Python) with {{ kv('key') }} reads and io.kestra.plugin.core.kv.Set writes.
5. Move files. Download File Store contents you still need and put them in your own object storage or as namespace files. Flows reference them by URI; large files never sit in memory between tasks.
6. Replace environment variables with flow variables: for non-sensitive values and secrets for the rest.

For the systems where Pipedream offered a pre-built component and Kestra does not yet have a plugin (NetSuite is the usual example), you have two options: an HTTP Request task with the REST call, authenticated from secrets as in step 2, or a custom plugin versioned and installed in your Cloud instance. The first is quick to set up and covers most cases; the second is worth it when ten flows share the same calls.

6. Stage 4, Exit: test, promote, cut over, cancel

Run both platforms side by side for each wave, and switch the trigger last. Nothing in Pipedream changes until the Kestra flow has processed real events.

1. Build in dev. Use a dev namespace, or a separate dev instance if you have one. Convert, run the flow with the Playground on sample payloads, and check inputs, outputs and logs on the execution page.
2. Write a test per critical flow. Flow tests mock task outputs and assert the result, so a month-end finance flow can be validated weeks before the real file lands.
3. Shadow run. Point a copy of the webhook at Kestra (or let the Schedule trigger run in parallel) while Pipedream keeps serving. Compare outputs for a few cycles.
4. Promote to production after review, through a Git pull request or Promote between instances, then repoint the source system’s webhook or disable the Pipedream trigger. The Pipedream workflow stays available as a rollback until you delete it.
5. Repeat per wave, critical flows first. Keep each wave reversible until its Pipedream side is switched off.

Plan backwards from March 31, 2027. An illustrative schedule for a 60-workflow estate: export and triage in week 1, patterns and credentials in weeks 2 to 3, conversion waves in weeks 4 to 12, buffer and month-end validation in the last month. Cancel the Pipedream subscription once the last wave is in production; annual subscribers get a prorated refund on request. Then revoke the OAuth grants Pipedream held in each connected app, so no grant outlives the migration.

After cutover, switch on what makes the next change cheap: Git sync so every flow is backed up and reviewed, SLA and failure notifications to Slack or PagerDuty, and dashboards over your executions.

7. Getting started

7.1 Start the Cloud trial with your export in hand

Request access to Kestra Cloud, pick the two or three workflows from Section 4, and build them. Send the team your integration list and your monthly step count, and we will tell you which plugins cover it and what the plan looks like before you commit.

Start your Cloud trial

Talk to our team

7.2 Start on open source, move to Cloud

If you want to test the conversion pattern before talking to anyone, the open-source edition runs the same flows. Pull the Docker Compose file, rebuild two workflows from your export (one webhook-driven, one scheduled) and measure the hours each took. That rate, multiplied across your triaged backlog, is your migration estimate.

curl -o docker-compose.yml https://raw.githubusercontent.com/kestra-io/kestra/develop/docker-compose.yml
docker compose up -d

The open-source edition stops where a Pipedream migration crosses into operations: SSO, role-based access per namespace, the managed secret manager, audit logs, Apps for business users, dev-to-prod promotion and someone else running the upgrades. Those are what you were paying Pipedream for, and they are what Kestra Cloud provides. The flows you wrote on open source move to Cloud unchanged, as long as they do not pin the Process or Docker task runner. You can also run the trial on Cloud from the start and skip the self-hosted step. The open-source vs. Cloud and Enterprise comparison lists the full split.