The durable execution category has converged on a broadly similar set of capabilities, and once you have read the documentation for two of them the feature comparison stops being the interesting question. Everyone does checkpointed steps, retries, long waits, scheduling and some form of concurrency control. What actually differentiates them, and what a team should be deciding on, is the licence, the mental model and the operational shape. On the licence, Trigger.dev has by some distance the strongest position in this batch.
It is Apache 2.0. You can self-host it, run unlimited jobs, deploy it inside your own infrastructure, and there is no licensing conversation with anyone. Compare that with Inngest under SSPL, which is not OSI-approved and which a meaningful number of organisations will not permit, or with the AGPL positions taken by RudderStack and Unleash, or with Snowplow's move to a licence that prohibits production use outright without a commercial agreement. In a catalogue where I keep having to warn readers to check a licence with their legal team before building anything, a genuinely permissive one is worth saying plainly.
It removes an entire category of risk: if the vendor's pricing changes, if the company is acquired, if the commercial terms become unattractive, you run it yourself. That option existing changes the negotiation even if you never exercise it. The mental model is the other real axis. Trigger.dev works on direct invocation: you define a task, you call it from your application, it runs somewhere else with its own machine allocation, retries and checkpointing.
Inngest works on events: something publishes an event and functions subscribe to it. Neither is correct in the abstract, and I would resist the framing that event-driven is more sophisticated, because for a large share of real background work it is not. Most background jobs are conceptually a function call that should happen later and reliably: resize this image, generate this report, send this sequence of emails. Expressing that as an event that a function subscribes to adds a layer of indirection that buys decoupling you frequently do not need, and costs you the ability to trace what triggered what by reading the code.
Direct invocation keeps the causal chain visible. For a small team, that legibility is worth more than the decoupling, which is why Trigger.dev tends to be the lower-risk default for a typical product team rather than an infrastructure organisation. The explicit machine sizing and queue configuration deserve a mention because they address something the serverless-flavoured competition often hides. If a task needs four gigabytes of memory for twenty minutes, you want to say so, and you want to know what that costs before you run ten thousand of them.
Being able to configure machines, queues, concurrency limits and waits explicitly gives you a cost model you can reason about rather than a bill you discover. The docs cover this properly, and the practical guidance around queue design is better than the category norm. Community size is a genuine practical advantage here too. Trigger.dev has substantially more GitHub stars and a larger public presence than Inngest, and while star counts are a poor proxy for quality they are a decent proxy for how likely it is that someone has already written up the answer to the strange problem you are about to hit at eleven at night.
That matters more in day-to-day work than most feature comparisons. The criticisms are real but mostly mild. The orchestration primitives are fewer and simpler than the event-driven alternatives offer, which is the flip side of the legibility argument: if you genuinely need complex fan-out patterns, event-driven coordination between many independent consumers, or sophisticated debouncing, you will find Inngest or Temporal has thought about your case more. Know which you are before you choose.
The self-hosting advocacy needs the same caveat I have applied to Matomo, RudderStack and every other self-hostable product in this catalogue: Apache 2.0 means you are permitted to run it, not that running it is free. You are operating a distributed execution system with a database, workers and a scheduler, all of which need monitoring, capacity planning and someone who understands them at two in the morning. For most teams the managed service is the right answer and the self-hosting option is valuable primarily as insurance. The docs are enthusiastic about self-hosting without pricing the operational commitment, which is the standard omission.
Maturity is worth weighing if your workload is genuinely critical. Temporal has been operated at serious scale for longer and has a deeper body of public operational knowledge around it. Trigger.dev is younger, and younger means fewer people have found the failure modes for you. And as with every product in this batch, nothing here will tell you that a queue and a worker would have been sufficient, which for a substantial share of readers it would be.
Four point zero. The same good ideas as its competitors with a genuinely permissive licence, a more legible mental model for ordinary background work and a larger community, marked down for having no teaching layer, fewer advanced primitives, and the usual silence about the simpler alternative.