# Cloudflare Workers Alternatives for Webhooks: Hookdeck Event Gateway, AWS Lambda, Vercel Functions, and Inngest Compared Cloudflare Workers is the developer's default for small pieces of glue code. A Worker that receives a webhook, reshapes the JSON, and posts it to another API is a dozen lines, deploys in seconds, and runs on the $5/month Workers Paid plan with 10 million requests included. When you need more, Cloudflare Queues, Workflows, and Durable Objects are bindings away. People look for alternatives to Workers for webhooks for three different reasons: 1. You don't want to build the ingress layer. The dozen lines grew into signature verification per provider, a queue, a dead letter queue with its own consumer, deduplication, and a way to replay last Tuesday's events. You want to keep writing Workers; you don't want to maintain the plumbing in front of them. 2. Your Worker is really just receive, transform, forward. It verifies, reshapes, and posts to one API, and everything else is reliability code. That's a job a webhook gateway does without code. 3. You want a different runtime. You're on AWS, deploy on Vercel, or need durable multi-step workflows. This guide covers all three. ## How to evaluate a Cloudflare Workers alternative for webhooks A webhook handler has two jobs that are worth judging separately: receiving the webhook reliably and running your code on it. Ingress vs compute: Is the tool receiving, holding, and redelivering webhooks (a gateway), or running your code (a runtime)? Signature verification: Is verification for Stripe, Shopify, and GitHub handled for you, or written per provider? What happens on failure: If your code throws or a downstream API is down, is the event stored and retried, or does recovery depend on the sender retrying? Replay: Can you find a webhook from last week and redeliver it, including to new code? Delivery rate: Can you cap how fast events reach a downstream API with its own rate limit? Deduplication: Are provider retries dropped before your code runs? Observability: Can you search past payloads and see every delivery attempt? Pricing model: Per request and CPU time (Workers, Lambda), per execution and step (durable runtimes), or per event (gateways)? ## What Cloudflare Workers does well Workers is excellent at what it's built for: * Price: Workers Paid is $5/month with 10 million requests and 30 million CPU milliseconds included, then $0.30 per million requests, per [Cloudflare's pricing docs](https://developers.cloudflare.com/workers/platform/pricing/). There are no egress fees. * Speed and scale: Code runs at the edge close to the sender, with fast cold starts and up to 5 minutes of CPU per request on the Paid plan. * Full code: Any logic you can write in JavaScript, TypeScript, Python, or Rust, including the Stripe SDK through its Web Crypto provider. * Composable primitives: Queues for buffering, Workflows for durable multi-step logic with `step.waitForEvent`, Durable Objects for per-key state, and the Agents SDK for stateful agents. * Platform reach: If your DNS, WAF, and front end are already on Cloudflare, a Worker is the shortest path to production. If you want maximum control at minimum cost and you're happy to own the code, Workers is a strong choice. ## Where Cloudflare Workers falls short for webhooks (and why people look for alternatives) There's no managed webhook ingestion. Cloudflare has no product that receives third-party webhooks and verifies them for you. You write verification per provider with `crypto.subtle`. Cloudflare's own [Agents SDK webhooks guide](https://developers.cloudflare.com/agents/communication-channels/webhooks/) says to always verify signatures before processing, and leaves signature verification and deduplication to the developer. A failed request isn't stored or retried. If your Worker throws, the sender gets a Cloudflare 1101 error; if it runs out of CPU, a 1102. The inbound request isn't kept, and outbound `fetch` doesn't retry. Whether the event is ever processed depends on the sender's retry policy, which ranges from days of retries at Stripe to none at all for some providers. Durability means assembling Queues yourself. The usual fix is a producer Worker that verifies and enqueues, and a consumer Worker that forwards. That works, with limits you design around: * 128 KB messages. Bigger webhooks need the body stored in R2 and a pointer enqueued. * At-least-once delivery, with no deduplication and no user-settable message ID, so idempotency is your job. * Retries default to 3, with a maximum of 100. Exponential backoff is something you code using `msg.attempts`. * Dead letters are deleted. Without a dead letter queue, messages that exhaust retries are deleted permanently. A dead letter queue needs its own consumer, and its messages are deleted after 4 days if nothing consumes them. * Retention is 4 days by default (up to 14) on Paid, and fixed at 24 hours on Free. The [Cloudflare Queues alternatives guide](/webhooks/platforms/cloudflare-queues-alternatives-for-webhooks) covers these in detail. No replay of past requests. Workers Logs keeps events for 7 days on Paid and truncates logs over 256 KB, and request bodies are only there if you log them. None of Cloudflare's observability tools replay an inbound request. If a bug mangled a week of webhooks, there's no button to send them through the fixed code, unless you built that store yourself. Throttling a downstream API is coarse. Queues' `max_concurrency` (1 to 250) and batch settings limit how many consumers run, but there's no requests-per-second setting per destination. The Rate Limiting binding is eventually consistent and per location, so it isn't built for strict outbound quotas. Precise rate limits mean building a token bucket in a Durable Object. Workers is a compute platform, so a reliable ingress layer is something you assemble from its parts. ## Cloudflare Workers alternatives for webhooks Which alternative fits depends on which problem you have: * [Hookdeck Event Gateway](/event-gateway): For the ingress problem, and for Workers 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 your Worker over HTTP. * AWS Lambda (with API Gateway and SQS): The equivalent on AWS, with the same build-it-yourself ingress work. * Vercel Functions: Webhook handlers next to your Next.js app. * Inngest or Trigger.dev: Durable multi-step workflows, when the processing needs waits and retries per step. * Zapier, Make, or n8n: Visual workflow tools, when the people maintaining the logic don't write code. ### Hookdeck Event Gateway (for the ingress problem) [Hookdeck Event Gateway](/event-gateway) sits between the provider and your Worker. 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 Worker's URL, with the Worker treated like any other HTTP destination. Your Worker gets verified, deduplicated events and keeps only the business logic. #### 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 `crypto.subtle` code per provider. Deliveries to your Worker carry a Hookdeck signature you verify once. * Durable queueing: Inbound requests are always accepted and stored, with payloads up to 10 MiB by default, so no R2 pointer pattern for large webhooks. * Retries: Up to 50 automatic retries with linear or exponential backoff, configurable by status code. A destination can return `Retry-After` to schedule a retry up to 7 days out. See [retries](/docs/retries). * Replay: Find any past webhook with full-text search across payloads and headers, and retry it singly or in bulk, including after you've deployed a fix. * Rate limits per destination: Cap deliveries per second, minute, or hour, or by concurrent requests. [Delivery Groups](/docs/delivery-groups) give each customer its own rate, keyed on a field in the payload. * Deduplication: Drop repeat events within a window from 1 second to 1 hour, on the whole event or chosen fields. See [deduplication](/docs/deduplication). * Issues and alerts: Failed deliveries open an [Issue](/docs/issues) with alerts by email, Slack, or webhook, and you can bulk retry from it. * Local development: The [Hookdeck CLI](/docs/cli) delivers the same events to `wrangler dev` on localhost. #### When Hookdeck replaces the Worker outright If the Worker verifies, reshapes, and posts to one API, a Hookdeck connection does that with no deploy. The source 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. Delivery timeouts are configurable up to 15 minutes, and retries, rate limits, and replay apply to that hop. The limit is that transformations run for at most 1 second and can't make network calls. If the handler needs to look something up in a database, call a second API, or write to D1 or KV, keep the Worker and put Event Gateway in front of it. #### How does Hookdeck Event Gateway compare to Cloudflare Workers?
Capability Hookdeck Event Gateway Cloudflare Workers (+ Queues)
Primary role Webhook gateway / ingress edge Compute platform
Provider signature verification ✅ 160+ pre-configured sources ❌ DIY with crypto.subtle
Inbound request stored if processing fails ✅ ℹ️ Only once you've enqueued it
Max payload in the queue 10 MiB by default 128 KB per message
Automatic retries ✅ Up to 50, by status code ℹ️ Queues: default 3, max 100
Deduplication ✅ 1 s to 1 h window ❌ DIY
Replay of past webhooks ✅ Single and bulk, with search ❌ DIY
Per-destination rate limit ✅ Per second, minute, hour, or concurrency ℹ️ Consumer concurrency only
Arbitrary code, network calls, storage ❌ 1 s transformations, no I/O ✅
Self-hostable ❌ Managed cloud ❌ Cloudflare only (workerd runtime is open source)
Pricing model Per event; free for 10,000/month, Team from $39/month Per request and CPU; $5/month minimum on Paid

### AWS Lambda (with API Gateway and SQS) On AWS, the equivalent stack is API Gateway or a Lambda function URL in front of a Lambda that verifies and enqueues to SQS, with a second Lambda consuming the queue. It's a natural fit if the rest of your system is on AWS and the downstream work needs IAM access to AWS services. The ingress work is the same as on Workers: per-provider verification, a dead letter queue, idempotency, and replay are yours to build. See [AWS SQS alternatives for webhooks](/webhooks/platforms/aws-sqs-alternatives-for-webhooks). ### Vercel Functions If your app is a Next.js project on Vercel, a route handler is the obvious place for a webhook: it shares types, environment variables, and deploys with the app. The trade-off is the same as a Worker without Queues: when the function throws or times out, the event's fate depends on the sender retrying, and there's no store of past requests to replay. Many teams put a gateway in front of Vercel routes for exactly that reason. ### Inngest or Trigger.dev (durable workflows) If the processing is a real multi-step workflow, with an LLM call, a wait for a human approval, and a follow-up a day later, a durable runtime checkpoints each step so a failure resumes where it left off. Cloudflare Workflows is Cloudflare's own take on this. Inngest and Trigger.dev are the managed, SDK-based options. None of them is a webhook gateway, so the verification and replay gaps still apply, and the common pattern puts a gateway in front. See [Inngest alternatives](/webhooks/platforms/inngest-alternatives) and [why most webhook agents don't need a workflow engine](/webhooks/platforms/most-webhook-agents-dont-need-a-workflow-engine). ### Zapier, Make, or n8n (visual workflow tools) If the people maintaining the logic don't write code, a visual workflow tool trades the Worker for a canvas and pre-built app actions. They cost more per event at volume, and their webhook triggers have their own reliability gaps. See [Zapier alternatives](/webhooks/platforms/zapier-alternatives), [Make alternatives](/webhooks/platforms/make-alternatives), and [n8n alternatives](/webhooks/platforms/n8n-alternatives). ## When to keep Cloudflare Workers Workers is the right tool, and worth keeping, when: * The handler does real work. It reads from D1 or KV, calls several APIs, writes to R2, or hands off to a Durable Object or agent. That's compute, which a gateway doesn't do. * Your events come from your own systems. If you sign and send the events yourself, there's no per-provider verification problem, and Queues covers buffering. * Cost is the main constraint and you have the time. At very high volume, Workers and Queues are hard to beat on price if you're willing to build and maintain the ingress layer. * You're already deep in Cloudflare. Bindings to the rest of your stack are a real advantage. The reason to add or switch tools is usually that the ingress layer turned out to be most of the code, or that the handler was simpler than a runtime assumes. ## Using Hookdeck Event Gateway and Cloudflare Workers together For teams that receive third-party webhooks and run logic on Workers, the answer is both. Event Gateway owns delivery, and the Worker owns the logic: 1. Providers send signed webhooks to a Hookdeck source URL. 2. Event Gateway verifies the signature, deduplicates, filters, and optionally reshapes the payload. 3. Event Gateway delivers each event to your Worker's URL at the rate you set, signed with a Hookdeck signature. 4. The Worker verifies the Hookdeck signature once, runs the business logic, and returns a 2xx. Any other response is retried. The failure modes are scoped. An exception in your Worker doesn't lose the event, because Event Gateway retries it. A bad deploy doesn't lose a week of events, because you fix the code and bulk retry them. And the Worker shrinks to the code that's specific to your product. For a step-by-step setup, see [how to receive and replay external webhooks in Cloudflare with Hookdeck](/webhooks/platforms/how-to-receive-and-replay-external-webhooks-in-cloudflare-with-hookdeck). If Cloudflare's Bot Fight Mode is on for the zone, see [using Hookdeck with Bot Fight Mode](/docs/guides/how-to-use-hookdeck-with-cloudflare-bot-fight-mode). ## Choosing the right Cloudflare Workers alternative If you searched for a Workers alternative because your webhook handler has turned into verification code, a queue, a dead letter consumer, and a replay tool, you don't need a different runtime. You need a webhook gateway in front of your Worker. [Hookdeck Event Gateway](/event-gateway) owns that layer. If the Worker only reshapes and forwards to one API, Hookdeck Event Gateway can replace it. And if you want a different runtime, AWS Lambda fits AWS-native stacks, Vercel Functions fit Next.js apps, and Inngest or Trigger.dev fit multi-step workflows that need durable steps.