Pipedream Alternatives After the Workflows Shutdown: What Moves, What to Save, and How to Migrate

Pipedream Workflows, the serverless product for connecting APIs with triggers, code steps and pre-built actions, is being retired. Pipedream was acquired by Workday, and Workflows is now in maintenance mode: no new signups, no new features, and a hard stop on March 31, 2027. A month later, on April 30, 2027, all Workflows data is permanently deleted, including the credentials and OAuth tokens of every connected account.

That changes the usual “Pipedream alternatives” question. It is no longer whether to move, but where to, and how to get every workflow, secret and webhook across before the data is gone. This page covers what the shutdown removes, what the export does and does not give you, how the alternatives compare for the workflows teams actually built on Pipedream, and a four-stage plan that finishes before the deadline.

TL;DR: Pipedream Workflows stops on March 31, 2027 and deletes all data, credentials included, on April 30. The export gives you workflow structure as JSON, not secrets, env vars, data stores or OAuth connections, so save those first. Kestra runs the same triggers and code steps as declarative YAML and adds native loops, retries, Git and observability. Kestra Cloud keeps the hosted model you had on Pipedream; if you prefer to self-host, Kestra Open Source (Apache 2.0) and Enterprise run the same flows on your own infrastructure. If you have already decided to move, go straight to the Pipedream migration guide: export, concept mapping, a worked conversion and the cutover plan.

The shutdown timeline

The dates come from Pipedream’s own shutdown notice. Monthly subscribers can cancel early in account settings; annual subscribers contact Pipedream support for an early, prorated cancellation.

What the export gives you, and what it leaves behind

Pipedream ships an export tool for the migration. In each project, open Settings and click Export Workflows. Pipedream writes project_export-<project_id>.zip to the project’s File Store, which means you need a plan that includes File Stores. The archive holds a manifest.json with a status and warnings for every workflow, plus one JSON file per workflow with its latest deployed version. One export covers up to 500 workflows or 256 MB; larger projects have to be split first. The export documentation has the details.

The export is structure, not state. Plan for everything in the second half of this table before you need it.

The manifest’s warnings name every step and prop you will have to re-enter or reconnect, so it doubles as the checklist for the “save it first” pass. The export checklist in the migration guide lists where to get each missing piece and where it goes in Kestra.

What moves, and what stays put

Leaving Pipedream Workflows replaces the engine, not the systems around it. Slack, Google Sheets, your ERP, your database and every API your workflows called keep running; the new orchestrator calls them. A practical way to scope the move is to give each part of the estate a verdict: replace (the new orchestrator takes it over), re-create (it has to be entered again by hand), keep (it stays and gets called) or retire (nothing replaces it).

Pipedream concepts in Kestra

Every Pipedream construct has a Kestra equivalent, most of them in the open-source edition. The complete Pipedream-to-Kestra mapping in the migration guide covers every construct, from $.flow.exit() to per-workflow memory settings.

What gets better on the way over

A forced migration is also the moment to stop living with the workarounds. Six come up in nearly every Pipedream estate.

Loops. Pipedream has no loop step, so iterating over records means a loop inside one code step, where one bad record fails the whole run, or a workflow that calls itself. In Kestra a Loop is a task: each item runs the same tasks with its own logs, retries and status, and a failed item can be replayed alone.

Memory and credits. In Pipedream, each step’s return value is kept and exposed to the steps after it, and a credit covers up to 30 seconds of compute, with more credits used when you raise a workflow’s memory. Long workflows that pass a large payload from step to step end up with memory set far above what the data needs. In Kestra, large outputs are written once to internal storage and later tasks receive a reference, so a 40-step flow does not carry 40 copies of the same file.

Slow APIs and long jobs. ERP and finance APIs can take minutes to answer. Kestra sets a timeout and a retry policy per task, and heavy or long-running steps can run on a task runner in your own AWS, GCP or Azure account, where they use your compute rather than a shared time limit.

Errors and environments. Pipedream teams often build their own error router to send failures to the right people. In Kestra the errors block, a flow trigger on failed executions, and log exporters to tools such as Datadog do that as configuration. Flows live in Git, promote from dev to prod, and can be tested before they run for real.

Access and audit. Finance, HR and payroll workflows are often the ones Pipedream ran, and they need tighter control than a shared workspace gives. In Kestra each team’s flows live in a namespace, and Kestra Cloud and Enterprise add SSO, role-based access per namespace, and audit logs of who changed or ran what.

People who are not developers. Pipedream let analysts make small changes and watch runs. In Kestra, business users can work in the no-code editor, follow executions and usage on dashboards, or launch a process from a form built with Apps without touching the flow itself.

Four tests for any Pipedream alternative

Most tools that come up in a Pipedream replacement search are strong in one slice of what Pipedream did. Ask four questions of each.

1. Does it run your code as code? Pipedream steps are Node.js, Python, Go and Bash. An alternative that only offers a visual builder means rewriting that logic.
2. Can the control flow grow? Loops, branches, waits, approvals and calls to other workflows should be native, not workarounds.
3. How hard is it to leave? Where do definitions live, can you read them without the product, and could you run it yourself if the vendor changed course? Could you rebuild your business logic from a backup if you had to? This is the test Pipedream just failed.
4. Can more than one team use it? Integrations rarely stay integrations; the same platform ends up running data loads, finance processes and infrastructure tasks.

Choose Zapier or Make when business users own simple automations and no code needs to move. Choose n8n for a self-hosted visual builder, and Temporal when the workflow belongs inside an application your developers ship. Choose Kestra when you need the layer Pipedream was for engineering teams, triggers plus code plus API calls, with the control flow, Git, observability and portability it never had, hosted for you on Kestra Cloud or run on your own infrastructure. The Kestra vs. Pipedream comparison goes feature by feature.

A Pipedream workflow rebuilt as a Kestra flow

A common Pipedream pattern: a file lands in shared storage, a code step parses it, a loop inside the next step posts each record to an ERP API, and a final step notifies the team. In Kestra it is one flow, and it runs the same on Kestra Cloud, Open Source and Enterprise. For a webhook-driven example with a code step, an ERP call over HTTP and a Slack alert on failure, see the worked conversion in the migration guide.

id: post_journal_entries
namespace: finance.integrations
description: Replaces a Pipedream workflow triggered by new files in a shared folder.

triggers:
  - id: new_file
    type: io.kestra.plugin.aws.s3.Trigger
    bucket: finance-drop
    prefix: journal/
    interval: PT1M
    action: MOVE
    moveTo:
      key: journal/processed/

concurrency:
  limit: 2
  behavior: QUEUE

tasks:
  - id: parse
    type: io.kestra.plugin.scripts.python.Script
    containerImage: python:3.12-slim
    outputFiles:
      - entries.json
    script: |
      import csv, json
      rows = list(csv.DictReader(open("{{ trigger.objects[0].uri }}")))
      json.dump(rows, open("entries.json", "w"))

  - id: each_entry
    type: io.kestra.plugin.core.flow.Loop
    values: "{{ fromJson(read(outputs.parse.outputFiles['entries.json'])) }}"
    tasks:
      - id: post_entry
        type: io.kestra.plugin.core.http.Request
        uri: "{{ secret('ERP_URL') }}/journal-entries"
        method: POST
        contentType: application/json
        body: "{{ item.value | toJson }}"
        headers:
          Authorization: "Bearer {{ secret('ERP_TOKEN') }}"
        timeout: PT10M
        retry:
          type: exponential
          interval: PT30S
          maxInterval: PT5M
          maxAttempts: 5

  - id: notify
    type: io.kestra.plugin.slack.notifications.SlackIncomingWebhook
    url: "{{ secret('SLACK_WEBHOOK') }}"
    messageText: "Posted {{ outputs.each_entry.iterationCount ?? 'all' }} journal entries"

errors:
  - id: route_failure
    type: io.kestra.plugin.slack.notifications.SlackIncomingWebhook
    url: "{{ secret('FINANCE_ONCALL_WEBHOOK') }}"
    messageText: "Journal posting failed, execution {{ execution.id }}"

The parsing code is the code from the Pipedream step, reading its input from the trigger instead of the steps object. The loop is a task, so one rejected entry retries on its own instead of failing the batch, and the ten-minute timeout covers an ERP that is slow to answer. Concurrency is capped in the definition, failures go to the team that owns them, and the whole thing is a file you review in a pull request. The Blueprints library has ready-made flows for many of the same integrations.

Kestra Cloud, Open Source or Enterprise

Pipedream teams are used to a platform someone else runs, and a deadline is a bad time to start operating new infrastructure. That is why we recommend Kestra Cloud for most Pipedream migrations; the self-hosted editions are there for teams that want them.

The flows are the same YAML in all three, so starting on Kestra Cloud does not lock you in: the same Git repository can move to a self-hosted edition later.

A four-stage plan that finishes before March 31

The plan below is the short version. The Pipedream migration guide runs the same work as four stages, Assess, Trial, Migrate and Exit, with the export checklist, the Pipedream-to-Kestra mapping table, a full worked conversion and what to test before you repoint a webhook.

1. Save and inventory (now). Export every project and keep the ZIPs outside Pipedream. In the same pass, copy environment variable names and values, list every connected account and the app it belongs to, dump the data stores you still need, download File Store files and event history you need for audits, and write down every external system that sends to a *.m.pipedream.net URL. The manifest’s warnings tell you which steps and props will need attention.

2. Triage. Many teams came to Pipedream through a migration of their own, often from Workato, and remember it taking months. This one has to take weeks, and triage is what makes that possible. The first workflow count is always larger than the real work. Three passes shrink it. The figures are illustrative, not a benchmark; plug in your own export.

Give the rest a verdict: convert as-is, rebuild because the Pipedream version was full of workarounds, or move somewhere else entirely, such as a function inside an application that already exists. Put the workflows with the highest business risk in the first wave, not the last.

3. Convert in waves. Start on Kestra Cloud, or self-host Kestra Open Source or Enterprise, and convert one wave at a time. Hand an exported workflow JSON to the AI Copilot, or connect your own assistant through the Kestra MCP server, and ask for the equivalent flow. Review each draft: replace pre-built actions with plugins or HTTP calls, re-create secrets, reconnect accounts. Run the new flow next to the Pipedream one on the same inputs until the outputs match.

4. Cut over and close down. Repoint each webhook sender, one at a time, and watch executions arrive in Kestra before you disable the Pipedream workflow. Revoke the OAuth grants Pipedream held in each connected app. Finish before March 31, 2027, and keep April as the buffer, because after April 30 there is nothing left to go back to.

How teams have run the switch

Víssimo Group, the company behind Brazil’s Evino and Grand Cru wine brands, ran its commerce integrations on an iPaaS and its BI pipelines on AWS Lambdas, with retries, timeouts and reprocessing hand-coded into each integration. It evaluated n8n, Temporal, Prefect, Airflow and Kestra, and consolidated both layers onto Kestra Open Source. Integration costs dropped by 90% and BI costs by 40%, it runs around 600 workflows in production, and Black Friday 2025 was its first without a major incident. Retries, timeouts and concurrency limits now live in the flow definitions instead of in each engineer’s code.

Where to start

1. Export every Pipedream project this week, and save the secrets, env vars, data stores and webhook senders the export leaves out.
2. Request Kestra Cloud access for a managed setup like the one you had on Pipedream, or start Kestra Open Source with Docker Compose if you prefer to self-host, and have the people doing the migration take the free courses on Kestra Academy.
3. Convert two or three real workflows first: one webhook-triggered, one scheduled, and the most complex one you have. Measure the hours each took; that rate, across your triage count, is the estimate.
4. Plan the waves backwards from March 31, 2027 with the migration guide, and talk to us if you want help with the conversion or a review of the plan.

Pipedream Workflows keeps running until the shutdown, so every wave stays reversible until you disable its Pipedream side. The goal is to make that the last migration your automation ever has to make.