Inngest vs Trigger.dev vs BullMQ in 2026: Which Background Job System Should Your SaaS Use

Because serverless functions are the wrong shape for background work, and understanding why is the whole reason these tools exist. A Next.js API route (or route handler) on a platform like Vercel is a short-lived serverless function: it spins up to handle a request, runs for a limited number of seconds, and then is frozen or killed. That's perfect for returning a response, but it breaks for anything that needs to outlive the request. If you kick off a slow task — sending a sequence of emails, processing an upload, calling a rate-limited third-party API, running a multi-step AI pipeline — inside the request, the user waits, and if it runs past the timeout the function is terminated mid-flight with no retry, no state, and no record of where it stopped. Even 'fire and forget' doesn't help: once you return the response, the platform can freeze the function and your 'background' work simply stops. You also can't easily run anything on a schedule (there's no always-on process to hold a cron), you can't guarantee a failed step is retried, and you can't limit concurrency so you don't hammer a downstream API. Background-job systems solve exactly this: they move the work out of the request/response cycle into something durable that can run longer, survive restarts, retry failed steps, run on a schedule, and control concurrency. Inngest and Trigger.dev do it with a managed orchestrator so you don't run infrastructure; BullMQ does it with a Redis queue and your own always-on worker. The unifying idea is the same — real background work needs durability, retries, and scheduling that a bare serverless request can't provide.

It comes down to who runs your job code and who owns the queue infrastructure, and that single split explains almost every trade-off. With BullMQ, you own everything: it's a library backed by Redis, so you provision and run a Redis instance, you write a worker process that stays alive and pulls jobs off the queue, and you deploy and monitor that worker yourself. Your code runs in your worker, on your infrastructure, and BullMQ gives you the queue primitives (concurrency, priorities, retries, repeatable jobs, flows). It's the most control and the lowest per-job cost, but you're responsible for the moving parts. With Inngest, a cloud orchestrator owns the queue and the durability, but your functions still run in your own deployment: you register functions, and when an event fires or a schedule hits, Inngest calls your function over HTTP, step by step, persisting state between steps and retrying failed steps automatically. There's no Redis and no worker to manage — it's designed to sit on top of serverless. With Trigger.dev, the platform owns both the orchestration and the compute: your tasks run on Trigger.dev's dedicated long-running infrastructure (not inside your serverless functions), which is why jobs can run for minutes or hours without hitting serverless timeouts, and it checkpoints state so a job can resume after an interruption; it's open-source, so you can self-host that infrastructure if you want to own it. So the spectrum is: BullMQ = your queue, your compute, your ops; Inngest = managed orchestration, your compute (serverless-friendly), no queue infra; Trigger.dev = managed orchestration and managed long-running compute, open-source if you'd rather host it. Pick based on how much infrastructure you want to own and where your jobs need to run.

For a serverless-first SaaS on Vercel or a similar platform, Inngest is usually the best default, and the reason is that it was built for exactly this constraint. On Vercel you don't have an always-on process, which means running BullMQ is awkward — BullMQ needs a persistent worker to pull jobs off Redis, and a pure serverless deployment has nowhere clean to run that worker, so you'd end up hosting a separate always-on service just for the queue. Inngest sidesteps that entirely: it needs no Redis and no worker, because its cloud orchestrator handles the queue and simply invokes your functions over HTTP when there's work. You define functions with retryable steps right inside your Next.js app, deploy as normal, and get durable execution, scheduled (cron) functions, event-driven fan-out, concurrency limits, and automatic step-level retries — all without provisioning or babysitting any infrastructure. That's the least-ops path to real background jobs on serverless, which is why it's the natural first choice for most Vercel-hosted SaaS boilerplates. Trigger.dev is also a strong serverless-friendly option and becomes the better pick when your jobs are genuinely long-running or compute-heavy (video, large imports, long AI chains) or when you want its deep run-visibility dashboard, because it runs those jobs on its own long-running compute instead of trying to fit them into a function invocation. BullMQ only makes sense on Vercel if you're already committed to running a separate always-on worker elsewhere (say, a small service on Railway or Fly.io) and want Redis-level control and cost. The short version: serverless SaaS → start with Inngest; go to Trigger.dev for long/heavy jobs and run visibility; use BullMQ when you already run a persistent worker.

BullMQ makes the most sense when you already run persistent infrastructure and want maximum control at the lowest cost — and that's a very common situation once an app grows past pure serverless. The precondition is an always-on process: if your app already runs on a platform where a long-lived worker is natural — Railway, Fly.io, Render, a VPS, or a container platform like Kubernetes — then adding a BullMQ worker alongside your app is straightforward, and you're not paying for anything you don't already have. In that setup BullMQ shines: it's a mature, widely used library, it gives you fine-grained control over concurrency, rate limiting, job priorities, delayed and repeatable (cron) jobs, and flow graphs where a parent job fans out to children, and critically it has no per-run pricing. Your cost is just your Redis instance plus the compute your worker already uses, which is why at high volume BullMQ is typically far cheaper than a per-run managed platform — a busy app can process very large numbers of jobs for the price of Redis hosting rather than a bill that scales linearly with every execution. The trade-off is ownership: you manage the Redis connection and its reliability, you write and deploy the worker processes, you handle scaling those workers, and you build or wire up your own monitoring and dashboards, since BullMQ is a library, not a hosted product with a polished UI (though tools like Bull Board help). So the honest rule is: if you have (or want) an always-on worker and value control and cost over convenience, BullMQ is excellent; if you're serverless or you'd rather not run and monitor queue infrastructure at all, a managed option earns its price by removing that operational surface.

All three give you retries, scheduling, and durability, but they express them differently, and the differences matter in practice. On retries, Inngest's signature feature is step-level retries: you break a job into named steps, and each step is retried independently and idempotently, so if step three fails, steps one and two aren't re-run — the orchestrator remembers their results and resumes from the failure. Trigger.dev similarly offers durable, resumable tasks with checkpointing, so an interrupted long-running job can pick up where it left off rather than restarting from zero. BullMQ retries at the job level with configurable attempts and backoff strategies; if you want step-level resumability you structure it yourself (for example, by splitting work into multiple queued jobs or a flow), which is more manual but fully in your control. On scheduling, all three support cron-style recurring work: Inngest has scheduled functions, Trigger.dev has scheduled tasks, and BullMQ has repeatable jobs — the difference is that Inngest and Trigger.dev hold the schedule in their managed orchestrator (nothing of yours needs to stay awake), while BullMQ's repeatable jobs rely on your always-on worker and Redis being up. On durability, the managed platforms persist job state for you: Inngest stores step state so functions survive restarts and redeploys, and Trigger.dev checkpoints so long jobs resume after interruption. BullMQ's durability comes from Redis — jobs and their state live in Redis, so durability is as strong as your Redis persistence and reliability configuration, which is powerful but is now your responsibility to get right. The theme repeats: managed tools give you durability and resumable steps out of the box as part of the price; BullMQ gives you the primitives to build equivalent guarantees while owning the infrastructure that backs them.

Two categories cause most of the pain: per-run costs that scale with volume, and self-hosted infrastructure you didn't fully account for. On cost, the managed platforms (Inngest and Trigger.dev cloud) are priced around usage — runs, steps, and for long jobs, compute time — which is great at low volume (both have usable free tiers) but grows roughly linearly as your job count climbs. A chatty design that triggers far more runs than necessary — firing a job per tiny event, retrying aggressively on expected failures, or fanning out into thousands of trivial steps — can turn a small feature into a surprisingly large bill. The fixes are deliberate: batch where you can, don't enqueue work that doesn't need to be a job, cap retries on errors that won't succeed on retry, and watch your run volume the way you'd watch any usage-priced service. BullMQ flips the trap: there's no per-run fee, so it's cheap at scale, but you inherit infrastructure risk. The classic failure modes are Redis running out of memory or losing data because persistence wasn't configured, a worker process crashing or being under-provisioned so the queue backs up, no dead-letter handling so failed jobs vanish silently, and no visibility because you never set up a dashboard. On reliability generally, the traps that bite everyone regardless of tool are non-idempotent jobs (a retry runs the side effect twice — charging a card or sending an email again), missing concurrency limits (a burst of jobs hammers a rate-limited API and gets you throttled or banned), and unbounded retries that turn a transient error into a storm. The discipline that pays off across all three: make jobs idempotent so retries are safe, set sensible concurrency and rate limits, cap and back off retries, handle permanent failures explicitly (dead-letter or alert), and — for self-hosted BullMQ — treat Redis persistence, worker scaling, and monitoring as first-class, not afterthoughts.

For a boilerplate, SaaS starter, or app you intend to hand off or sell, the guidance mirrors every other infrastructure decision: default to what fits the template's host, is easy for the buyer to re-point at their own account, is safe by default, and won't hand them a surprise bill or a hidden dependency — and deviate only for a stated reason. Because most Next.js SaaS starters target serverless deployment, Inngest is usually the strongest default: it needs no Redis and no separate worker process, so the buyer can clone the repo and deploy to Vercel without standing up extra infrastructure, and it wires in cleanly keyed off the buyer's own Inngest credentials via environment variables with an example env file. Critically, it should no-op or be clearly gated without keys, so an unconfigured clone doesn't send events to your account or crash on boot — the same disabled-without-a-key discipline you'd apply to analytics, email, or error tracking. If your template is built around a persistent host (a Railway or Fly.io starter that already runs an always-on service), BullMQ can be the better fit, since the worker has a natural home and you avoid a third-party dependency entirely — just document the Redis requirement clearly and provide the connection via env vars, never hardcoded. Trigger.dev is a good default when the template's whole point is long-running or AI-heavy workflows where run visibility is a selling point, and its open-source nature means the buyer isn't locked into a vendor. Whatever you choose, the resale rules are the same as for any code you sell: no hardcoded API keys or Redis URLs, an example env file, the job layer disabled or no-op without configuration, sensible defaults for concurrency and retries so the buyer doesn't inherit a runaway bill or a rate-limit ban, idempotent example jobs, and clear docs on which service the template expects and how to plug in their own account. A background-job layer that's cleanly abstracted, key-free, safe by default, and documented does as much to make a codebase read as production-ready as any feature built on top of it.