---
title: "Inngest vs Trigger.dev vs Temporal (2026): Background Jobs & Durable Workflows Compared"
description: "On September 14, 2026 Temporal Cloud dropped its base monthly fee, removing the main reason small teams skipped it. Inngest, Trigger.dev and Temporal compared on where your code runs, what each one meters, real cost for 100,000 workflow runs, and when a plain queue is still the right answer."
source: https://appstackbuilder.com/blog/inngest-vs-trigger-dev-vs-temporal-2026
retrieved: 2026-09-27
---

[Back to Blog](https://appstackbuilder.com/blog)

Background Jobs2026 Guide

# Inngest vs Trigger.dev vs Temporal: Background Jobs in 2026

On September 14, 2026 Temporal Cloud dropped its base monthly fee — the main reason small teams used to skip it. That leaves three serious options for jobs that must not fail halfway, and they differ on one thing above all: **where your code actually runs**. We compare Inngest, Trigger.dev and Temporal on that, price 100,000 workflow runs on each, and say when a plain queue is still enough.

14 min read3 platforms analyzed, 3 challengersPublished September 2026

## First: why background jobs need more than a cron

Every SaaS grows work that cannot happen inside a web request: sending the welcome sequence, syncing a customer's data, generating a report, running an AI agent that takes four minutes. The first version is a cron job or an `await` nobody waits for. It works until the process restarts halfway through, the job silently vanishes, and a customer finds out before you do.

The tools on this page do **durable execution**: they save the result of every step, retry only the step that failed, and resume a job exactly where it stopped — after a crash, a deploy, or a three-day wait for a human to approve something.

### No half-finished jobs

A deploy in the middle of a job no longer loses it. The job picks up at the step it was on, with the results of earlier steps intact.

### Retries that do not double-charge

If step four fails, steps one to three are not run again. The card is charged once, the email goes out once — the bug class that hurts most in production.

### Waiting without a server

"Send a reminder in three days unless they upgrade" becomes one line of code instead of a database table, a cron and a state machine you maintain.

### Agents that survive their own failures

An AI agent makes dozens of slow calls that rate-limit and time out. Saving each one means a failure on call 30 does not re-run — and re-pay for — calls 1 to 29.

**What it does not do:** it does not make your steps safe to repeat. A step can still run more than once in rare failure cases, so anything with side effects — payments, emails — should use an idempotency key. And it adds a new dependency to your system: if the orchestrator is down, your jobs wait.

**Do you need this yet?** If your background work is a handful of single-step jobs that are safe to run twice, a simple queue is cheaper and simpler — see the challengers below. The switch is worth it once you have multi-step jobs where a failure halfway through costs money or trust.

## Quick Verdict

![](https://www.google.com/s2/favicons?domain=inngest.com&sz=128)Inngest

No workers. Your functions live in your existing app, and Inngest calls them over HTTP step by step. The shortest path from a Next.js or serverless app to durable workflows.

No infrastructureEvent-driven

![](https://www.google.com/s2/favicons?domain=trigger.dev&sz=128)Trigger.dev

Your task code runs on Trigger.dev's own compute, so a job can run for as long as it needs with no serverless timeout. Open source and self-hostable, with a TypeScript-first developer experience.

No timeoutsOpen source

![](https://www.google.com/s2/favicons?domain=temporal.io&sz=128)Temporal

The heavyweight. Workers you run pull work from the Temporal service; SDKs in seven languages; used for business-critical workflows at very large scale. Now with no monthly minimum on the cloud.

Most controlSteepest setup

TL;DR

No single winner — pick on where your code should run. Inside your existing serverless app → **Inngest**. On managed compute with no time limit → **Trigger.dev**. On workers you control, across several languages, at large scale → **Temporal**. And for single-step jobs that are safe to repeat, a plain queue like **QStash** or BullMQ is enough.

## The question that decides it: where does your code run?

All three save step results and resume after failures. They disagree about who executes your code, and that one choice decides your infrastructure, your timeouts and what you get billed for.

### 1\. In your app, called over HTTP — Inngest

You add an endpoint to the app you already deploy. Inngest stores the state and calls that endpoint once per step. Nothing new to host, and it works on Vercel, Cloudflare and any serverless platform. The trade: each step still runs inside your platform's request limits, so a single very long step needs splitting up.

### 2\. On the vendor's compute — Trigger.dev

You deploy your task code to Trigger.dev, which runs it on its own machines, sized per task. Jobs can run for minutes or hours, and you pick the CPU and memory. The trade: compute is on the bill, and your task code is a separate deploy from your web app.

### 3\. On workers you operate — Temporal

You run long-lived worker processes that poll the Temporal service — Temporal Cloud or your own cluster — for work. Maximum control, any language, no platform limits. The trade: you run and scale those workers, and workflow code must follow Temporal's determinism rules, which takes time to learn.

A quick test: if your whole app is serverless and you do not want a single new server, that points to Inngest. If your jobs are long and heavy, Trigger.dev. If you already run services on your own infrastructure and a platform team would own this, Temporal.

## The three, in detail

Plans and prices as published on each vendor's pricing page in September 2026\. Note what each price covers: Inngest and Temporal do not include the compute your code runs on; Trigger.dev does.

No workers to run

![](https://www.google.com/s2/favicons?domain=inngest.com&sz=128)

### Inngest

Durable functions in your own app

$0 up to 50K executions

Pro from $99/mo with 1M executions

* Free: 50K executions, 5 concurrent steps, 500K events, 24h traces
* Pro $99/mo: 1M executions, 100+ concurrency, 7-day traces
* Business $499/mo: 10M executions, 500 concurrency
* One run plus each step counts as an execution
* Event-driven: functions trigger from events, crons or other functions
* Runs on Vercel, Cloudflare and any serverless host
* CaveatExecutions add up with step count — a five-step function is six executions, so a free tier of 50K is about 8,000 five-step runs. The free plan pauses at its limit rather than charging overage.

Best for: Serverless and Next.js teams who want durable workflows without adding infrastructure.

Open source

![](https://www.google.com/s2/favicons?domain=trigger.dev&sz=128)

### Trigger.dev

Long-running tasks on managed compute

$0 with $5 usage

Hobby $10/mo, Pro $50/mo — each includes that much usage

* Per run: $0.000025 invocation plus per-second compute
* Smallest machine (0.25 vCPU) at $0.0000169 per second
* Free: 20 concurrent runs, 10 schedules, 1-day logs
* Pro: 200+ concurrent runs, 1,000+ schedules, 30-day logs
* Runs in the dev environment are not charged
* Self-hostable if you would rather run it yourself
* CaveatCompute time is the bill, so a slow task costs more than a fast one. Pick the smallest machine that works, and watch tasks that hold a machine while waiting on a slow API.

Best for: TypeScript teams with long or heavy jobs — AI agents, media processing, big syncs — that break serverless timeouts.

No base fee since Sep 14

![](https://www.google.com/s2/favicons?domain=temporal.io&sz=128)

### Temporal

Durable execution at any scale

$0 base fee

$50 per million Actions, pay as you go

* Pay-as-you-go cloud with no base monthly fee (from Sep 14, 2026)
* $0.042 per GB-hour active storage, $0.00105 retained
* Developer support at 10% of usage; $150 credits for 90 days
* Commitments cut the Actions price by more than 50%
* Open-source server you can self-host
* SDKs for Go, Java, TypeScript, Python, .NET, PHP and Ruby
* CaveatYou run the workers, so their compute is a second bill, and the determinism rules for workflow code take real time to learn. Expect days to production, not an afternoon.

Best for: Teams with a platform or backend group running business-critical workflows across several services and languages.

## What 100,000 workflow runs a month costs

One realistic workload: a five-step onboarding workflow, run 100,000 times a month. Every tool meters a different unit, so each line states its assumption. Figures from published September 2026 rates.

![](https://www.google.com/s2/favicons?domain=inngest.com&sz=128)

### Inngest

\~$99/mo

6 executions per run × 100K = 600K executions, inside Pro's 1M. Plus the serverless compute your own functions use on your host.

![](https://www.google.com/s2/favicons?domain=trigger.dev&sz=128)

### Trigger.dev

\~$36/mo

Assuming one run of 10 seconds of compute on Small 1x: 100K × ($0.000025 + 10 × $0.0000338). Compute is included; longer tasks scale this linearly.

![](https://www.google.com/s2/favicons?domain=temporal.io&sz=128)

### Temporal Cloud

\~$55/mo

Assuming about 10 Actions per run: 1M Actions at $50, plus 10% developer support. Plus storage, plus the servers your workers run on.

**Do not pick on this number alone:** at this size all three cost less than an hour of engineering time a month, and the assumptions above move each figure a lot — a Temporal workflow with more activities uses more Actions, a slower Trigger.dev task uses more compute. The difference that matters at this scale is setup time and who maintains it, not the invoice.

## Feature comparison

Capability

![](https://www.google.com/s2/favicons?domain=inngest.com&sz=128)Inngest

![](https://www.google.com/s2/favicons?domain=trigger.dev&sz=128)Trigger.dev

![](https://www.google.com/s2/favicons?domain=temporal.io&sz=128)Temporal

Where code runs

Your app

Their compute

Your workers

Workers to operate

✗

✗

✓

Serverless-friendly

✓

✓

Workers needed

Long-running tasks

Split into steps

✓

✓

Self-host option

Yes

✓

✓

Languages

TS, Python, Go

TypeScript

7 SDKs

Meter

Executions

Runs + compute

Actions + storage

Free tier

50K executions

$5 usage

$150 credit

Time to first workflow

Minutes

An hour

Days

"Time to first workflow" is a rough guide for a team new to each tool, not a benchmark.

## Challengers worth knowing

The big three are not the only options. These are younger or narrower, and worth a look when one of their specific strengths is exactly your problem.

![](https://www.google.com/s2/favicons?domain=hatchet.run&sz=128)Hatchet

Open-source durable task queue built on Postgres. Appealing if you want Temporal-style guarantees with a database you already run, and no separate cluster.

![](https://www.google.com/s2/favicons?domain=restate.dev&sz=128)Restate

A lightweight durable execution runtime, shipped as a single binary, that also handles durable RPC between services. Worth watching for teams building distributed services.

![](https://www.google.com/s2/favicons?domain=upstash.com&sz=128)Upstash QStash

Not durable execution — an HTTP message queue and scheduler with retries. For single-step jobs it is the simplest serverless option there is, and often all you need.

If you run your own servers, the classic queues still work well: BullMQ on Redis for Node, Celery for Python, Sidekiq for Ruby. They retry whole jobs rather than individual steps, which is fine when each job is one step.

## Which one should you pick?

### Your app is on Vercel or another serverless host

**Inngest.** Your workflow code deploys with the rest of the app, and there is nothing new to run. Keep each step shorter than your platform's function timeout and it just works.

![](https://www.google.com/s2/favicons?domain=inngest.com&sz=128)Inngest

### Your jobs are long, heavy or AI agents

**Trigger.dev.** Tasks run on dedicated machines with no timeout, so a ten-minute agent run or a large video render is just a task. Size the machine to the job to keep compute costs down.

![](https://www.google.com/s2/favicons?domain=trigger.dev&sz=128)Trigger.dev

### Workflows are business-critical and span several services

**Temporal.** Payments, order fulfilment, anything that crosses teams and languages. With the base fee gone, you can now start small on the cloud and grow — but budget real time for the learning curve.

![](https://www.google.com/s2/favicons?domain=temporal.io&sz=128)Temporal

### Each job is one step and safe to repeat

A queue, not a workflow engine. **QStash** if you are serverless, BullMQ or your language's standard queue if you run servers. Move up to durable execution the day you write your first job with three steps that must not repeat.

![](https://www.google.com/s2/favicons?domain=upstash.com&sz=128)Start with a queue

## Build the rest of the stack around it

Use our AI-powered generator to build a complete stack — hosting, database, auth, background jobs, monitoring — sized to your budget and your team.

[Generate Your Tech Stack](https://appstackbuilder.com/build-stack?budget=100&appType=saas&teamSize=small)

## Frequently Asked Questions

### Which is best for background jobs in 2026: Inngest, Trigger.dev or Temporal?

There is no single best one — the difference is where your code runs. Inngest calls functions that live in your existing app over HTTP, so it fits serverless apps on Vercel or Cloudflare with no extra infrastructure. Trigger.dev runs your task code on its own managed compute, so long jobs never hit a serverless timeout. Temporal runs your code on workers you operate, which is the most work to set up and the most control and durability at large scale. Pick on where you want the code to execute, then check the bill.

### What is durable execution?

Durable execution means a multi-step job remembers how far it got. If step three of five fails, or the server restarts, the job resumes at step three instead of starting again or silently dying. Each step result is saved, so retries do not repeat work that already succeeded — no double-charged cards, no duplicate emails. A plain job queue retries a whole job; a durable execution engine retries the step that failed.

### How much does Temporal Cloud cost now?

Since September 14, 2026, Temporal Cloud offers pay-as-you-go pricing with no base monthly fee: $50 per million Actions, $0.042 per GB-hour of active storage and $0.00105 per GB-hour of retained storage. Developer support is charged at 10% of usage, and new sign-ups receive $150 in credits for 90 days. Commitments reduce the Actions price by more than 50%. You still pay separately for the compute your workers run on.

### Does Inngest work with Next.js and Vercel?

Yes, that is the setup it is designed for. Inngest does not need workers: you expose an endpoint in your app, and Inngest calls it to run each step, so your functions deploy with the rest of your Next.js app. The free plan includes 50,000 executions a month, where a function run counts as one execution and each step counts as another — a five-step function is six executions.

### Is Trigger.dev open source?

Yes. Trigger.dev is open source and can be self-hosted, and the company also runs Trigger.dev Cloud. On the cloud, you pay a per-run invocation fee of $0.000025 plus per-second compute by machine size, starting at $0.0000169 a second for the smallest machine. The free plan includes $5 of usage a month, Hobby is $10 with $10 of usage, and Pro is $50 with $50 of usage.

### Do I need a durable workflow engine for AI agents?

Usually, once an agent runs longer than a single request. Agents make many slow, failure-prone calls — model APIs that rate-limit, tools that time out, humans who approve something hours later. A durable engine saves each step, retries only the failed call, and can pause for days waiting for an event without holding a server open. All three tools on this page now market directly to agent builders for this reason.

### When is a simple queue like BullMQ or QStash enough?

When each job is a single step that is safe to run twice — send one email, resize one image, call one webhook. A queue with retries handles that cheaply and simply. Reach for durable execution when a job has several steps that must not be repeated, needs to wait for something external, or runs long enough that a restart in the middle is likely.

### Related Articles

[Best AI Agent Sandbox 2026Where agent code runs safely](https://appstackbuilder.com/blog/best-ai-agent-sandbox-2026)[Sentry vs Datadog vs New RelicKnowing when a job fails](https://appstackbuilder.com/blog/sentry-vs-datadog-vs-new-relic-2026)[PostHog vs Mixpanel vs AmplitudeProduct analytics compared](https://appstackbuilder.com/blog/posthog-vs-mixpanel-vs-amplitude-2026)

### Explore More

[All Blog Posts](https://appstackbuilder.com/blog)[Background Job Tools](https://appstackbuilder.com/categories/background%5Fjobs)[Inngest Pricing](https://appstackbuilder.com/tools/inngest)[Stack Generator](https://appstackbuilder.com/build-stack)
