When to Use Inngest vs Trigger.dev vs a Plain Queue in 2026

Every Inngest vs Trigger.dev comparison skips the option most indie hackers should pick first. Both tools are excellent. Both have generous free tiers. And both are overkill for a huge share of the apps paying for them, because those apps just need a queue, and they're often sitting on a server that already has one.

So here's the honest framing. This isn't a two-way race between two YC-backed job platforms. It's a three-way decision where the third option is free, boring, and already installed. If you run Laravel, it's Horizon. If you run Node, it's BullMQ. The interesting question is where the boring option stops being enough.

I'll give you the short version now. Always-on server plus simple jobs means plain queue. Serverless plus multi-step workflows means Inngest. Long-running or compute-heavy jobs mean Trigger.dev. All pricing below was verified against the vendors' pages this week.

Quick Decision Table

When Is a Plain Queue the Right Call?

More often than the modern job platforms would like you to believe. A queue with a worker is the right tool when three things are true. Your jobs are mostly single-step. Your app runs somewhere that's always on. And failure handling means "retry the whole job," not "resume from step three."

That describes most of what indie apps actually do in the background. Welcome emails, receipt PDFs, image processing, webhook fan-out, nightly cleanup. None of it needs orchestration. It needs a queue, a worker process, and retries, which Redis plus Horizon or BullMQ has handled well for a decade.

The economics are hard to argue with. Horizon is a first-party Laravel package, free, with a dashboard, metrics, and retry management on top of Redis. BullMQ gives Node the same, free. Your only cost is the server you're already paying for. We ranked the whole category in our background job tools roundup, and the free tier of "software you already have" won for simple workloads there too.

And there's a hidden benefit nobody markets. No new vendor. No new dashboard, no new API keys, no new failure mode where a third party's outage becomes your outage.

When is a plain queue NOT the right call?

The moment orchestration creeps in. If a signup flow dispatches a job that dispatches two more, passes state between them through the database, and has a cron job checking whether the chain finished, you've built a workflow engine by hand. A bad one. That's the signal to graduate.

Same if you've gone serverless. Vercel functions time out, and there's no always-on worker to drain a Redis queue. Fighting that constraint costs more than either paid tool does.

When Is Inngest the Right Call?

Inngest is what you pick when your workflows have real structure and your compute is serverless. Its model is event-driven. You send events, Inngest triggers functions, and each function breaks into steps that are individually retried, individually resumed, and can sleep for days between steps without holding a server open.

That last part is the killer feature. A "send onboarding email, wait three days, check activity, send the right follow-up" flow is miserable on a plain queue and about ten lines with Inngest steps. The work still runs on your own infrastructure (Vercel, Lambda, containers), so you're not moving compute, just orchestration.

Pricing runs on executions, meaning individual step runs. The free Hobby tier includes 50,000 executions a month with 5 concurrent steps, no card required. Pro starts at $99/month with 1 million executions included, 100+ concurrent steps, and pay-as-you-go beyond that. Overage examples from their pricing page include $25 per 25 extra concurrent steps and $0.50 per million extra events.

Watch the concurrency limit, not the execution count. Five concurrent steps on the free tier is the constraint indie apps hit first, since one burst of traffic queues everything behind it.

When is Inngest NOT the right call?

When your jobs have one step. Paying per execution to send emails a Redis worker could send for free is how tool bills creep up without anyone deciding it. And the jump from free to $99/month is steep for a solo project in the awkward middle, where 50,000 executions is too few but a million is science fiction. Trigger.dev's $10 tier sits exactly in that gap.

It's also not the tool for very long-running compute. Inngest orchestrates your functions, and your functions still live with your platform's timeouts.

When Is Trigger.dev the Right Call?

Trigger.dev takes the opposite approach. Instead of orchestrating compute you already have, it runs the compute itself on its own machines. Write a task in TypeScript, deploy it, and it executes on Trigger.dev's infrastructure with no timeouts at all.

No timeouts changes what's possible. Video transcoding, big scraping runs, AI agent loops that think for twenty minutes, PDF generation for a thousand invoices. Anything that would die at a serverless timeout or hog your only worker just runs. You get retries, queues, scheduling, and a real-time dashboard with React hooks to stream progress into your UI.

Billing is per second of actual execution. Machine time ranges from $0.0000169 per second for a micro machine up to $0.00068 for the largest, plus a $0.25 per 10,000 runs invocation fee. The free tier includes $5 of usage credits and 20 concurrent runs each month. Hobby is $10/month with $10 in credits, and Pro is $50/month with $50 in credits and 200+ concurrent runs. Do the math for a typical side project (say 10,000 five-second runs on a micro machine) and you land around $1.10 a month, comfortably inside the free credits.

And if the bill ever matters more than the convenience, the whole platform is Apache 2.0 licensed and self-hostable for free. That's a real exit hatch, not a marketing one.

When is Trigger.dev NOT the right call?

When you're not in TypeScript land. Trigger.dev tasks are TypeScript code, so a Laravel or Python app can only use it as a detached sidecar service, which adds more moving parts than it removes. Laravel apps with heavy jobs are usually better served by Horizon on a beefier VPS.

It's also weaker as a pure event router. If what you need is fan-out of webhooks to consumers with delivery guarantees, that's a different category, and we compared it in Svix vs Hookdeck vs QStash.

How Much Does Each Actually Cost?

At true indie scale, all three are free. Take an app doing 10,000 background jobs a month, averaging three steps each. That's 30,000 Inngest executions, inside the 50,000 free tier. On Trigger.dev, 10,000 short runs costs roughly a dollar of the $5 free credits. On a plain queue it costs nothing beyond the VPS you already rent.

The costs diverge at growth, and they diverge by shape, not just size. Inngest charges for orchestration, so many small steps add up fastest there, and the next stop after free is $99/month. Trigger.dev charges for compute seconds, so long heavy jobs add up fastest there, but the paid ladder starts at a gentle $10. The plain queue charges you in ops time instead of dollars, which is free until the night it isn't.

One number worth repeating from each pricing page. Inngest Pro: $99/month, 1M executions. Trigger.dev Hobby: $10/month. Horizon and BullMQ: $0, forever, plus your server.

My Recommendation

Start with the queue you already have. Genuinely. Most apps never outgrow it, and the ones that do will tell you loudly, through hand-rolled orchestration code that keeps breaking.

When you do graduate, pick by shape. Multi-step logic on serverless goes to Inngest, and its free tier means trying it costs nothing but an afternoon. Long or heavy compute goes to Trigger.dev, and $10/month is a very fair price for "timeouts stop existing." If you're the kind of builder who self-hosts on principle, Trigger.dev's Apache license makes it the only one of the paid pair you can run for free.

flowchart TD
    A{Always-on server available?} -- no --> B{Jobs long or compute-heavy?}
    A -- yes --> C{Multi-step flows that must resume?}
    C -- no --> D[Plain queue: Horizon or BullMQ]
    C -- yes --> E[Inngest]
    B -- yes --> F[Trigger.dev]
    B -- no --> E

This is the same logic we applied to automation platforms in when to use Make vs Zapier vs n8n. The boring option that's already in your stack wins by default, and the paid option has to earn its seat by solving a problem you can name. If you can't name the problem, you don't have it yet.

Found a better option? Let me know on Twitter @hafizdev.