Inngest Alternatives: Hookdeck Event Gateway, Trigger.dev, Temporal, and Restate Compared

Inngest comes up whenever a team is building event-driven systems, background jobs, LLM and agent workflows, multi-step processing triggered by events. It's a durable workflow runtime: you write functions as a series of checkpointed steps, and Inngest persists state between them so a function that crashes halfway through resumes where it left off.

People often seek Inngest alternatives for two very different reasons, and the right answer depends on which one you are:

1. You actually need a webhook gateway, not a runtime. You reached for Inngest to receive webhooks from Stripe, Shopify, GitHub etc. and you've hit the fact that Inngest's HTTP intake is a generic authenticated endpoint, not a per-provider webhook receiver. You're verifying signatures, normalizing payloads, and absorbing spikes yourself. What you want is something that owns the ingress edge.
2. You want a different durable runtime. You like the durable-execution model but want different trade-offs, self-hosting, language support, pricing, or a different programming model. Here the alternatives are Trigger.dev, Temporal, Restate, and similar.

This guide covers both. For the ingress problem, Hookdeck Event Gateway is the answer, and it's complementary to Inngest rather than a replacement. For the durable-runtime problem, we compare Trigger.dev, Temporal, and Restate.

How to evaluate an Inngest alternative

Inngest blurs two layers that are worth keeping separate: receiving an event and processing an event. A useful comparison names which layer each tool serves and judges it there:

Ingress vs execution: Is the tool receiving webhooks from third parties (a gateway), or executing your code reliably after events arrive (a runtime)?

Webhook source coverage: For the ingress use case, does the tool ship pre-configured signature verification for Stripe, Shopify, GitHub, and the rest, or do you write it per provider?

Durable execution: For the runtime use case, does it checkpoint steps so a crash mid-function resumes at the failed step rather than re-running everything?

Language and SDK fit: Inngest is SDK-based. Does the alternative match your stack, or is it HTTP-delivery and stack-agnostic?

Self-hostability: Open-source and self-hostable, or managed-cloud only?

Pricing model: Per execution and step-second (Inngest, Trigger.dev), per event (gateways), or self-hosted compute (Temporal)?

Observability: Function-run traces, webhook-level traces, or both?

What Inngest does well

Inngest is genuinely good at its category. You define functions as a series of step.run() calls, and the platform persists state between steps:

• Durable step functions: Each step is checkpointed, so a retry after a failure resumes at the failed step rather than re-running the whole function, the expensive LLM calls that already succeeded aren't repeated.
• Per-step retries: Default 4 retries with exponential backoff and jitter, configurable per function or per step. Each step keeps its own retry counter.
• Waitpoints: step.waitForEvent() and step.sleep() let a function pause for minutes, hours, or days while waiting for a downstream event or a human approval.
• Scheduling, concurrency, throttling: Cron and delayed triggers, plus function-level concurrency and rate-limiting primitives.
• Replay over function runs: Selectively re-run functions against historical events, filtered by date, status, or event type.
• Self-hostable: An open-source runtime alongside the managed cloud.

If your events come from your own code and your processing is a real multi-step workflow, Inngest is a strong choice.

Where Inngest falls short (and why people look for alternatives)

It's not a webhook gateway. Inngest exposes a generic HTTP endpoint authenticated with its own API key. To accept a signed webhook from Stripe, Shopify, or GitHub, you implement the integration yourself: verify the signature, normalize the payload, then call inngest.send(). There's a webhook transform feature for some providers, but it's a per-source script you write and maintain rather than a curated catalog. There's no source normalization, no request-inspection UI for raw provider traffic, no durable queue absorbing spikes before function code runs, and no CLI for local webhook development. If your real problem is ingesting third-party webhooks, you're rebuilding the ingress layer one provider at a time, which is exactly the job a webhook gateway is built for.

Durable execution is overkill for simple handlers. If your code is receive webhook, call one model, write one row and return, there are no checkpoints worth persisting, and you're paying execution-billed pricing for trivial work. See why most webhook-triggered agents don't need a workflow engine.

SDK and language lock-in. Inngest is SDK-based, primarily TypeScript and Python. If your backend is Go, Ruby, Elixir, or anything else, the integration surface is narrower than an HTTP-delivery model.

Execution-based pricing at scale. Per-execution and step-second billing is reasonable for complex workflows but expensive for high-volume pass-through work where each event does one cheap thing.

Inngest alternatives

Which alternative fits depends on which layer your problem is on:

• Hookdeck Event Gateway: For the ingress problem. Managed webhook gateway, 120+ pre-configured sources, signature verification, durable queueing, filtering, transformations, and replay. Complementary to a runtime, not a competitor.
• Trigger.dev: The closest like-for-like durable runtime, open source, TypeScript-first, with a similar step/retry model.
• Temporal: The heavyweight durable-execution engine for complex, long-running, polyglot workflows.
• Restate: A newer durable-execution platform with a lightweight single-binary model.
• DIY (queue + worker): A queue (SQS, BullMQ, Sidekiq) plus your own worker, when the workflow is simple enough not to need durable steps.

Hookdeck Event Gateway (for the ingress problem)

If you reached for Inngest to receive webhooks, Hookdeck Event Gateway is the tool that's built for that job. It sits at the ingress edge: webhooks from third-party providers arrive at a Hookdeck Event Gateway source, get verified against the provider's signing secret, get deduplicated and held in a durable queue, and get delivered to your code, or to an Inngest intake endpoint, at a rate your system can handle.

Hookdeck Event Gateway key features

• 120+ pre-configured sources: Stripe, Shopify, GitHub, Twilio, and the rest ship with signature verification handled, so no verification code to write or maintain per provider.
• Durable queueing with backpressure: A Shopify flash sale or a Stripe end-of-month dispatch is absorbed at the edge before any function code runs.
• Filtering and transformations at the edge: Drop the 80% of events you don't care about before paying to process them, and reshape payloads into the { name, data } form Inngest expects. See filters and transformations.
• Webhook-level observability: A visual trace per request, full-text search across payloads and headers, and Issues for failure recovery, a view of the raw provider traffic that a runtime's function-run dashboard doesn't give you.
• Replay over webhooks: Re-deliver any past webhook, singly or in bulk, to know whether the provider sent the event and whether your pipeline handled it.
• Local development with the CLI: hookdeck listen 3000 proxies live webhooks to localhost, multiple developers at once, history preserved across restarts. See the Hookdeck CLI documentation.
• Stack-agnostic: Delivers over HTTP to any backend, in any language.

How does Hookdeck Event Gateway compare to Inngest?

They sit on either side of the line between receiving an event and processing one. Hookdeck Event Gateway handles the ingress edge, verification, dedup, queueing, observability of raw provider traffic. Inngest handles the execution layer, durable step state, per-step retries, waitpoints. The most common production pattern puts Event Gateway in front of Inngest, so each does the part it's best at.

Trigger.dev (for the durable-runtime problem)

Trigger.dev is the closest like-for-like alternative to Inngest as a durable runtime. Open source, TypeScript-first, with a step/retry model, waitpoints, scheduling, and a function-run dashboard. Teams choose it over Inngest for its self-hosting story, its long-running-task ergonomics, or simply because they prefer its developer experience. Like Inngest, it's a runtime, not a webhook gateway, the same ingress gap applies, and the same Hookdeck-in-front pattern works. The architecture is documented in GitHub agent automation with Hookdeck, Trigger.dev, and Claude.

Temporal (for complex, polyglot workflows)

Temporal is the heavyweight of durable execution, workflows-as-code with deterministic replay, used for complex, long-running, mission-critical orchestration across many languages (Go, Java, TypeScript, Python, .NET). It's far more powerful than Inngest and far more operationally involved: you run a Temporal cluster (or pay for Temporal Cloud) and adopt its programming model. Choose it when your workflows are genuinely complex and long-lived and you need polyglot workers.

Restate (lightweight durable execution)

Restate is a newer durable-execution platform built around a single binary, with durable functions, virtual objects, and a lighter operational footprint than Temporal. It's worth a look if you want durable execution without the cluster overhead and prefer its model to Inngest's.

DIY (queue + worker)

If your workflow is one or two steps, a queue plus a worker is often enough, AWS SQS, BullMQ, or Sidekiq depending on your stack. You give up checkpointed steps and waitpoints, but you avoid a workflow DSL you don't need. Pair it with a gateway for ingress and you've covered the failure modes that actually bite at small scale.

When to keep Inngest

Inngest is the right tool, and worth keeping, when:

• Your events come from your own code, not third-party webhooks. There's no signed-webhook ingress problem to solve, so inngest.send() is the natural integration point and you don't need a gateway in front.
• Your workflows are genuinely multi-step and long-running. Five or more discrete steps, waitpoints for external events or human approvals, compensating transactions, or survival across deploys mid-execution.
• Per-step work is expensive. Multi-dollar LLM calls or large data transforms where re-running an entire function on a late failure is unaffordable, checkpointed steps pay for themselves.
• You're happy with the TypeScript/Python SDK model and the managed-cloud or self-hosted runtime fits your ops.

The reason to add or switch tools is usually that your real problem turned out to be on the ingress side, or that your processing is simpler than a durable runtime assumes.

Using Hookdeck Event Gateway and Inngest together

For most teams that receive third-party webhooks and run real workflows, then run Event Gateway in front of the runtime:

1. Providers (Stripe, Shopify, GitHub, Twilio, etc.) send signed webhooks to a Hookdeck source URL.
2. Hookdeck verifies the signature, deduplicates, filters, and transforms the payload into the { name, data } shape Inngest expects.
3. Hookdeck delivers the event to an Inngest intake endpoint with the right authentication.
4. Inngest enqueues the event and runs the subscribed functions, with checkpointed steps and per-step retries.

Each tool owns the layer it's good at, and the failure modes are scoped: an Inngest outage doesn't lose webhooks because Hookdeck queues and retries delivery; a downstream code bug doesn't lose webhooks because Hookdeck has the original request stored for replay. For the full breakdown, see Hookdeck Event Gateway vs Inngest.

Choosing the right Inngest alternative

If you searched for an Inngest alternative because you're drowning in per-provider signature verification and spike handling, you don't need a different runtime, you need a webhook gateway at the edge. Hookdeck Event Gateway owns that layer with 120+ pre-configured sources, durable queueing, and replay, and it sits in front of Inngest rather than replacing it.

If you searched because you want different durable-execution trade-offs, Trigger.dev is the closest like-for-like, Temporal is the heavyweight for complex polyglot orchestration, and Restate is the lightweight newcomer. And if your processing is really only a step or two, a gateway plus a plain handler covers the failure modes that matter without a workflow engine at all.