Inngest vs Trigger.dev vs BullMQ: Next.js Background Jobs (2026)

We keep a shelf in the ShipGarden gallery for the plumbing nobody photographs: the background-job runner. It is the part of a Next.js SaaS that sends the welcome email, resizes the upload, runs the nightly export, and calls the model without freezing the request. Get it wrong and every slow task becomes a timeout your user watches spin.

This quarter we put three of the most-shipped options side by side: Inngest, Trigger.dev, and BullMQ. They solve the same problem from three different addresses, and the honest answer to "which one" is decided by where your jobs actually run, not by whose feature list is longest.

Quick answer (2026)

For a Next.js SaaS in 2026, pick Inngest if you live on serverless and want zero queue infrastructure to babysit, Trigger.dev if you run long tasks that blow past serverless timeouts, and BullMQ if you already operate Redis and a persistent Node host and want the cheapest, most controllable option. All three are production-grade. The tiebreaker is your runtime, not a checklist.

The three at a glance

Star counts and versions from each project's GitHub repo, and free-tier and paid figures from each vendor's pricing page, all read July 2026 (sources linked in each section below).

The real dividing line: where does the work happen?

Every background-job tool answers one architectural question: what machine keeps running after the HTTP response is sent? Serverless functions are born to die fast, so a job that takes ninety seconds needs somewhere durable to live.

• Inngest keeps nothing of yours running. You send an event, and Inngest calls your function back over HTTP in durable steps, retrying and pacing each step for you. The queue is theirs; you never see it.
• Trigger.dev runs your task on its own managed compute (or your self-hosted stack), so a task can run for minutes or hours with no serverless timeout hanging over it.
• BullMQ runs inside your own always-on Node process, backed by a Redis you operate. Maximum control, and the machine is yours to keep alive.

That single distinction predicts most of the trade-offs below.

Inngest: event-driven jobs with no queue to run

Inngest is the pick when you never want to think about a queue. You define functions triggered by events, wrap the slow parts in step.run(...), and Inngest handles retries, concurrency, throttling, and multi-step durable flows. It is serverless-native, so it drops onto Vercel without a separate worker host. The server is source-available under SSPL (with delayed Apache-2.0 publication), and you can self-host it. The Inngest repo sits at 5.6k stars on v1.37.0 (July 2026).

Pricing is execution-based: a free Hobby tier of 50k executions a month, then Pro from $99/mo covering 1M+ executions and $50 per additional 1M (Inngest pricing, 2026).

Where it loses: you adopt Inngest's step model, and each step counts as an execution, so a workflow with many small steps burns the quota faster than a naive job count suggests. Pure CPU-bound grinding on serverless is still bound by your host's function limits unless you self-host. And the durable-step API, lovely as it is, is a shape your code marries.

Trigger.dev: managed compute for the jobs that run long

Trigger.dev is the answer when a job is genuinely long: rendering video, chaining model calls, crunching a big export. Tasks run on Trigger.dev's compute with no timeout, durable retries, and a proper run dashboard for observability. It is fully Apache-2.0 and self-hostable, and it is the most-starred of the three at 15.7k on v4.5.4 (July 2026) per the Trigger.dev repo.

The Free plan gives $5 of monthly credits and 20 concurrent runs; Hobby is $10/mo and Pro is $50/mo with 200+ concurrent runs and 30-day log retention (Trigger.dev pricing, 2026).

Where it loses: the pricing is credit-and-compute based, which is harder to forecast than a flat per-run number until you have run real workloads through it. Self-hosting is a heavier lift than dropping in a library, because you are standing up its whole stack. And on the lower tiers, concurrency caps will bite a spiky workload before anything else does.

BullMQ: the library you own, Redis and all

BullMQ is the classic move: an MIT-licensed, Redis-backed queue that runs inside your own Node workers. No vendor, no per-execution meter, and the lowest raw cost of the three because you only pay for Redis and the host it runs on. It is battle-tested at 9.1k stars on v5.80.4 (July 2026), and the BullMQ repo ships frequently. When founders on r/nextjs ask what to use for background jobs, the recurring line is "Inngest or Trigger if you are serverless; BullMQ if you have a VPS or a dedicated server," and that is the honest split.

Where it loses: BullMQ needs an always-on worker process, which is a poor fit for a pure-serverless Vercel deploy. You will want a persistent host (Railway, Render, Fly, or a VPS) to run the workers, and you build retries dashboards and alerting yourself, or add the paid Taskforce board. Redis operations, memory limits, and eviction policy all become your job. Control has an ops bill.

So which one do you ship?

• You are Vercel-only and want zero queue infra: Inngest. It is the shortest path from "no jobs" to "durable jobs" on serverless.
• Your tasks run for minutes or need heavy managed compute: Trigger.dev. It was built for the long-running case that serverless timeouts kill.
• You already run Redis and a persistent Node host, and want lowest cost with full control: BullMQ. No vendor, no meter, your rules.

A useful gut check: if you cannot name where a long-running worker would live in your current deploy, you want Inngest or Trigger.dev, because they answer that for you. If you can point at the box, BullMQ will be cheaper and more yours.

Cost at scale, honestly

At a few thousand jobs a month, all three are effectively free. The divergence starts when volume climbs. Inngest's execution meter is predictable but steps add up; a step-heavy pipeline at a couple million executions lands in low-hundreds-of-dollars territory on Pro. Trigger.dev's credit model rewards short, bursty tasks and costs more as compute-seconds pile up, so long jobs are where you watch it. BullMQ's bill is just your Redis plus the worker host, often the cheapest line item, with the caveat that your own time is the hidden cost when something needs debugging at 2am. Model your real workload before you commit; none of these numbers substitute for running your own jobs through a free tier for a week.

We test these building blocks because owning the stack is how you own the outcome. Both the Inngest starter review and the Trigger.dev background-jobs starter review in the gallery go deeper on the deploy paths for each if you want the hands-on install notes.

FAQ

Your move: spin up the free tier that matches your runtime, push one real slow job through it this week, and let the bill and the DX, not the marketing, make the call.