# Pipedream Alternatives for Webhooks: Hookdeck Event Gateway, n8n, Trigger.dev, and Cloudflare Workers Compared Pipedream has announced that Workflows and String will shut down on [March 31, 2027](https://pipedream.com/docs/workflows), with all Workflows data deleted a month later. Pipedream is focusing on Connect, its API for connecting AI agents and apps to external services, which isn't affected. If you run anything on Pipedream Workflows, it needs a new home within six months. For a lot of teams that means more than rewriting code steps. Every workflow with an HTTP trigger has a `*.m.pipedream.net` URL registered with Stripe, Shopify, GitHub, or an internal system, and each of those URLs stops working at the shutdown. That adds up to three different migrations: 1. Your webhooks need a new URL. Every provider that sends to Pipedream has to be updated. If you point them at another workflow tool's URL, you'll repeat this the next time you change tools. You want a stable URL you control, with verification, queueing, and replay in front of whatever runs the logic. 2. Your workflow is really just receive, transform, forward. It's an HTTP trigger, a Node.js step that reshapes the payload, and a request to another API. That's a job a webhook gateway does without a runtime. 3. Your workflow needs a new runtime. It has several code steps, uses pre-built actions, or calls an LLM. Here the alternatives are Trigger.dev and Inngest for code-first workflows, Cloudflare Workers and AWS Lambda for single functions, and n8n, Zapier, or Make for visual tools. This guide covers all three. ## What the Pipedream Workflows shutdown means Per [Pipedream's announcement](https://pipedream.com/docs/workflows): * Now: Workflows is in maintenance mode. Existing workflows keep running, but Pipedream isn't accepting new signups or subscriptions, and won't ship new Workflows features. * March 31, 2027: Workflows and String shut down. Subscriptions are cancelled automatically with a prorated refund. * April 30, 2027: All Workflows data is permanently deleted, including the credentials and OAuth tokens for connected accounts. * Not affected: Pipedream Connect, including the Connect API, MCP servers, and API Proxy. Pipedream provides an [export tool](https://pipedream.com/docs/workflows/export-workflows) that writes a ZIP per project, with one JSON file per workflow containing its triggers, steps, code, and props. It's useful as a record of what you built, with limits: * There's no import. Pipedream documents no way to load the files into another platform, so each workflow is rebuilt by hand. * Secrets aren't included. Secret prop values are redacted, and credentials, OAuth tokens, and environment variables are left out. Connected accounts have to be reconnected wherever you move. * Data isn't included. Event history, data stores, and File Store files are downloaded separately. * It runs one project at a time, up to 500 workflows or 256 MB per export, and needs a plan that includes File Stores. ## How to evaluate a Pipedream alternative Pipedream Workflows combined three things that most alternatives split up: an HTTP endpoint that receives webhooks, a runtime for code steps, and a catalog of pre-built actions with managed auth. A useful comparison names which of those each tool replaces: Ingress vs runtime: Is the tool receiving and holding webhooks from third parties (a gateway), or running your code once they arrive (a runtime or workflow tool)? Code steps: Can you write steps in Node.js or Python and import packages, the way you did in Pipedream? App integrations and auth: Are there pre-built actions and managed OAuth for the APIs you call, or do you bring your own clients and tokens? Webhook reliability: Does the tool verify signatures, queue events, retry failures, and replay past events? Migration risk: Can you move providers to the new tool without dropping events during the cutover, and avoid repeating the work if you move again? Hosting and pricing: Self-hosted, managed, or both, and priced per run, per step, or per event? ## Where Pipedream's HTTP trigger fell short for webhooks Before rebuilding, it's worth knowing which of Pipedream's webhook limits you've been working around, so you don't carry them to the next platform: * No signature verification. HTTP triggers are public by default. The built-in options are a static bearer token or OAuth, neither of which Stripe or Shopify can send. Verifying a provider's HMAC signature is code you write at the start of the workflow. * 10 requests per second. HTTP triggers accept around 10 requests per second on average and return a 429 above that, unless support raises the limit. * 512 KB bodies. Larger requests get a 413, unless the sender adds a Pipedream-specific query parameter or header to upload the body to a file. * No queue on HTTP triggers. Pipedream's concurrency and throttling queue applies to event-source triggers, and is not supported for native HTTP triggers. * Disabled means 404. A disabled workflow's HTTP endpoint returns a 404, and the event isn't kept. * Retries on one plan. Automatic retries of a failed step, up to 8 times over 10 hours, are only on the Advanced plan, and don't apply to out-of-memory errors or timeouts. These limits are common in workflow tools, because the ingress layer is usually left to you. ## Pipedream alternatives Which alternative fits depends on which migration you're doing: * [Hookdeck Event Gateway](/event-gateway): For your webhook URLs, and for workflows that only receive, transform, and forward. A managed webhook gateway with 160+ pre-configured sources, signature verification, a durable queue, filters, JavaScript transformations, deduplication, retries, and replay. Delivers to any runtime over HTTP, including Pipedream while you migrate. * Trigger.dev or Inngest: Code-first workflows in TypeScript with retries per step, the closest match to Pipedream's code steps. * Cloudflare Workers or AWS Lambda: Plain functions, for workflows that are one code step and an API call. * n8n: A visual canvas with JavaScript and Python Code nodes, a large node catalog, and a free self-hosted edition. * Zapier or Make: The largest app catalogs, for workflows maintained by people who don't write code. ### Hookdeck Event Gateway (for your webhook URLs) [Hookdeck Event Gateway](/event-gateway) sits between your providers and whatever runs your logic. Webhooks arrive at a Hookdeck source URL, get verified against the provider's signing secret, get deduplicated and held in a durable queue, and get delivered to your destination over HTTP. The destination can be Pipedream today and Trigger.dev, a Worker, or n8n next month, and the providers never see the change. #### Migrating webhooks off Pipedream without losing events The cutover is where events get lost: a provider is updated before the new handler works, or the old workflow is switched off while retries are still arriving. Putting Event Gateway in front first turns the migration into a series of steps you can undo: 1. Put Event Gateway in front of Pipedream. Create a Hookdeck source for each provider, with a connection whose destination is your existing Pipedream endpoint URL. Nothing changes in Pipedream. 2. Move each provider once. Update the provider's webhook URL to the Hookdeck source URL. Pipedream keeps processing events as before, now with Event Gateway verifying, queueing, and retrying in front of it. 3. Run the new handler alongside. Build the replacement and [add a second connection](/docs/connections) from the same source to it, so every event goes to both. Compare the results on real traffic. If the new handler has side effects, like writing to a database or calling a paid API, use a [filter](/docs/filters) to send it a subset first. 4. Cut over. [Pause](/docs/guides/how-to-pause-connections) the Pipedream connection. If the new handler fails on an event, fix it and [bulk retry](/docs/retries) the failures. Every request is stored, so nothing depends on the provider retrying. After that, the Hookdeck source URL is the one registered with your providers, and moving runtimes again is a change to a destination rather than to every provider. #### Hookdeck Event Gateway key features * 160+ pre-configured sources: Stripe, Shopify, GitHub, Twilio, and the rest ship with [signature verification](/docs/sources), so there's no HMAC code to port from your Pipedream steps. * Durable queueing: Inbound requests are always accepted and stored, with payloads up to 10 MiB by default. Events above your delivery rate wait in the queue rather than getting a 429. * Retries: Up to 50 automatic retries with linear or exponential backoff, configurable by status code, plus manual and bulk retry. See [retries](/docs/retries). * Replay: Find any past webhook with full-text search across payloads and headers, and redeliver it singly or in bulk, including to a new destination. * Rate limits per destination: Cap deliveries per second, minute, or hour, or by concurrent requests, so a burst arrives at your new runtime at a pace it can handle. [Delivery Groups](/docs/delivery-groups) give each customer its own rate. * Deduplication: Drop repeat events within a window from 1 second to 1 hour. See [deduplication](/docs/deduplication). * Pause and resume: [Pausing a connection](/docs/guides/how-to-pause-connections) keeps accepting and storing events without delivering them, so turning off a handler doesn't lose anything. * Local development: The [Hookdeck CLI](/docs/cli) delivers the same events to localhost while you rebuild. #### When Hookdeck Event Gateway replaces the workflow outright Many Pipedream workflows are an HTTP trigger, a Node.js step that reshapes the payload, and a request to another API. A Hookdeck connection does the same job without a runtime: the source receives and verifies the webhook, a [transformation](/docs/transformations) reshapes the payload and headers in JavaScript, and the destination posts it to the target API with an API key, bearer token, basic auth, or a custom signature. You get queueing, retries, and replay on that hop, priced per event: 10,000 a month free on the Developer plan, then $3.00 per 100,000 on paid plans, falling with volume. The limit is that transformations run for at most 1 second and can't make network calls or import packages. If the workflow looks something up, calls a second API, or uses pre-built actions, move the logic to a runtime and keep Event Gateway in front. #### How does Hookdeck Event Gateway compare to Pipedream Workflows?
Capability Hookdeck Event Gateway Pipedream Workflows
Primary role Webhook gateway / ingress edge Workflow runtime with an HTTP trigger
Availability ✅ Generally available ❌ Shuts down March 31, 2027
Provider signature verification ✅ 160+ pre-configured sources ❌ DIY in a code step
Inbound rate ✅ Always accepts, then queues ℹ️ About 10 requests per second, then 429
Max payload 10 MiB by default 512 KB, or larger via a Pipedream-specific upload option
Events while the handler is off ✅ Held while the connection is paused ❌ 404
Automatic retries ✅ Up to 50 ℹ️ Up to 8 over 10 hours, Advanced plan only
Deduplication ✅ 1 s to 1 h window ❌ DIY
Code steps and pre-built actions ❌ 1 s transformations, no network calls ✅ Node.js and Python steps, app actions

### Trigger.dev or Inngest (code-first workflows) If your Pipedream workflows were mostly code steps, a code-first durable runtime is the closest replacement. Trigger.dev and Inngest let you write workflows as TypeScript functions, deployed from your own repo, with retries per step and checkpointing so a failure resumes where it left off. Both have open-source, self-hostable editions as well as managed clouds, and Inngest also has Python and Go SDKs. The trade-off is Pipedream's app catalog. You call APIs with their own SDKs and manage the tokens yourself. Neither is a webhook gateway, so signature verification and replay are still yours, and the common pattern puts Event Gateway in front, as in [this GitHub, Trigger.dev, and Claude setup](/webhooks/platforms/github-trigger-dev-claude-automation). See [Inngest alternatives](/webhooks/platforms/inngest-alternatives) for how they compare. ### Cloudflare Workers or AWS Lambda (single functions) If a workflow is one code step and an API call, a serverless function is the cheapest place to put it. Cloudflare Workers runs on the $5/month Workers Paid plan with 10 million requests included, and Lambda suits teams already on AWS. You write signature verification, retries, and replay yourself, or put Event Gateway in front. See [Cloudflare Workers alternatives](/webhooks/platforms/cloudflare-workers-alternatives) for the trade-offs. ### n8n (visual canvas with code nodes) n8n is the closest match for teams who used Pipedream's pre-built actions alongside code. Workflows mix a large catalog of nodes with Code nodes in JavaScript or Python, and the Community Edition is free to self-host. Importing npm packages into Code nodes is limited to self-hosted instances that allow it, so heavy code steps may fit a code-first runtime better. n8n's Webhook node doesn't verify provider signatures and has no inbound buffer, which Hookdeck's [verified n8n node](/blog/hookdeck-n8n-node) covers. See [n8n alternatives](/webhooks/platforms/n8n-alternatives). ### Zapier or Make (no-code automation) If the people maintaining a workflow don't write code, Zapier and Make have the largest catalogs of pre-built actions. Both price per step, which adds up at webhook volume, and neither verifies HMAC signatures on incoming webhooks. See [Zapier alternatives](/webhooks/platforms/zapier-alternatives) and [Make alternatives](/webhooks/platforms/make-alternatives). ## A Pipedream migration checklist Whatever you move to, these steps apply to every project: * Export each project before March 31, 2027, and keep the ZIPs outside Pipedream. The export needs a plan with File Stores, and anything left is deleted on April 30, 2027. * List every HTTP trigger with the provider that sends to it and where its signing secret lives. These are the URLs you'll need to change. * Collect secrets and environment variables from their sources, since the export redacts them. * Download event history, data stores, and File Store files you need to keep. They aren't in the export. * Reconnect accounts on the new platform. OAuth tokens don't carry over. * Move webhook URLs to a stable gateway first, so the runtime migration can happen workflow by workflow without a hard cutover. If you use Pipedream Connect for your own product's integrations, it carries on as before, and none of this applies to it. ## Choosing the right Pipedream alternative Every Pipedream workflow with an HTTP trigger has to change its URL before March 31, 2027. Moving those URLs to [Hookdeck Event Gateway](/event-gateway) first means you only update your providers once, you can run old and new handlers side by side, and nothing is lost during the cutover. If a workflow only reshapes and forwards a webhook, Event Gateway can replace it. For the rest, Trigger.dev and Inngest are the closest fit for code-first workflows, Cloudflare Workers and Lambda suit single functions, n8n suits teams who want a canvas with code, and Zapier or Make suit people who don't write code.