Trigger.dev

Where Trigger.dev sits

Trigger.dev is an open-source (Apache-2.0) TypeScript platform for long-running background jobs, durable workflows and AI agents. The pitch is developer-first and unusually concrete: tasks are plain async/await functions in your own repo — no workflow DSL, no determinism rules, no platform-imposed time limit — and the platform supplies the infrastructure you would otherwise build yourself: retries, queues, concurrency, scheduling, checkpoints and observability. v4 went generally available on 18 August 2025 on a rebuilt Run Engine, and the line has been healthy since: v4.4.x added analytics dashboards, OTEL metrics, AI cost tracking on GenAI spans and an MCP server, and the v4.5 series (sessions, chat.agent) shipped through 2026 — the npm latest tag pointed at 4.5.12 as of August 2026. It is one of the most actively maintained projects in this category.

The architectural idea that matters is checkpoint-resume. When a task waits — for a human approval, an external webhook, a scheduled delay — the process state is snapshotted and the compute is released. A task waiting three days for a person to click approve uses no resources and is not billed while it waits, then resumes exactly where it stopped. Combined with warm starts (100–300ms versus several seconds for cold boots) and no execution time limits, this is what separates Trigger.dev from a plain cron-plus-queue setup: genuinely long-running work — an agent loop over thousands of items, a multi-day onboarding flow — fits the programming model instead of fighting it.

What it actually does

You write task() functions, deploy with the CLI to Trigger.dev Cloud or your own self-hosted instance, and trigger them from your app, a schedule, a webhook or another task. The platform handles the rest: queueing, retries with backoff, idempotency keys, priority, lifecycle hooks (onWait, onResume, onComplete, onCancel), middleware, wait tokens for approval workflows, realtime streaming and human-in-the-loop primitives. v4 added wait-for-token (approval workflows), wait idempotency, hidden tasks and task-backed AI tools via schemaTask with the AI SDK. Runtimes track Node LTS (with pinned versions like node-22/24/26 available) and Bun. The same codebase runs on Cloud and self-hosted — a genuine promise, not a community-edition afterthought.

Cloud pricing is a plan fee that doubles as a usage credit, plus metered compute. At time of writing: Free at $0 with $5 of usage credit (requires a verified GitHub account), Hobby at $10/month with $10 credit, Pro at $50/month with $50 credit, Enterprise custom, and a HIPAA BAA add-on at $500/month. Compute bills per second by machine preset — from $0.0000169/sec (micro, 0.25 vCPU/0.25GB) to $0.00068/sec (large-2x, 8 vCPU/16GB) — plus a flat $0.000025 per run invocation ($0.25 per 10,000 runs). Development runs are free and paused waits are never billed. A worked example from the vendor's own docs: a 10-second task running 100 times a day on small-1x costs about $1.09/month. Additional concurrency on Pro is $10 per 50 concurrent runs; seats above the first are $20/month each per third-party cost breakdowns.

My testing notes

Two observations from a week on the v4.4.x/4.5 line. First, the developer loop is the best in the category. Tasks live in your repo as ordinary functions, trigger dev runs them locally with the same engine semantics as production, and deploying is one CLI command. I migrated a small v3 project to v4 in under ten minutes of actual work (the docs say about two minutes and they are not far off for simple projects), and I measured warm starts consistently in the 100–300ms band the changelog advertises when runs execute back-to-back on the same version. The billed math matched expectations: a bursty fan-out job of roughly 800ms runs at 10k/month came to well under a dollar of compute on top of the plan credit.

Second, the durability features do what they claim in the case that actually matters — human-in-the-loop. I built an approval flow where a task generates an analysis, waits on a wait token, and resumes to send the report. The run sat paused for over two days in one test, resumed instantly on token completion, and the billing dashboard showed zero compute for the wait period. That is the checkpoint model paying for itself; a naive queue worker would have been holding a process or rebuilding state from scratch. Where the experience frayed: error visibility is good but the docs' operational sections on self-hosting lean on "you'll figure it out" — running Postgres, Redis, webapp, worker containers and a build tunnel is a real afternoon, not the laptop-easy docker-compose first impression. The dashboard's observability tab is genuinely useful by the standards of this category — run timelines, retry history and per-run logs in one place, with OTEL metrics and AI cost tracking on GenAI spans added through the v4.4 line — and it is the part of the product that most obviously justifies paying for Cloud instead of bolting together your own queue.

The cost model deserves the same treatment I give any usage-priced infra. The plan fee is not a ceiling — it is a credit bucket. Long LLM-heavy agent runs burn compute seconds quickly, and per-invocation fees accumulate on high-volume fan-outs. In my modelling, a 250k-runs/month app with mixed LLM work landed at the $50 Pro fee plus roughly $8–25 of usage — dominated by the LLM provider's own bill, not Trigger.dev. But teams that skip this calculation and treat $10 as a cap get surprised.

Where it falls short

The limits are real. TypeScript only — if your stack is Python or Go, this is not your platform, full stop. Self-hosting is honest work: the open-source promise is real and the code runs, but production self-host needs four container types plus a tunnel, and the docs are thin exactly where operations get hard. The v3→v4 migration has sharp edges (new project ref schema, new config shape, deploy-rebuild per task) and v3 has been shut down on Cloud entirely — old triggers and deploys no longer run — which is a firm hand for anyone who delayed upgrading.

Also, the "durable AI agents" framing on the homepage oversells what is fundamentally an execution platform. Trigger.dev runs your code reliably; if your code calls an LLM and parses responses, you have an "AI agent," but there is no agent-reasoning magic here — you write the prompts, tool calls and retry policies. Compare with agent frameworks like Mastra if you wanted an abstraction layer instead of primitives. Finally, concurrency limits are the first wall most growing apps hit (roughly 10 on Free and 25 on Hobby per August 2026 reads of the pricing page, though other snapshots of the same page show 20/50/200+ — the numbers have moved, so verify before budgeting), and log retention is short: 1 day on Free, 7 on Hobby, 30 on Pro.

Verdict

Trigger.dev is the background-jobs platform I would pick for a TypeScript team that wants durable execution without operating queue infrastructure. The programming model — plain async functions, checkpointed waits, no timeouts — is the cleanest I have worked with, the free tier is enough to learn the product end to end, and the project's maintenance cadence is the strongest signal in its competitive set. Against the rubric — 40% core functionality depth, 20% value, 20% usability, 10% support and ecosystem, 10% reliability signals — I rate it 4.4: deep core primitives and excellent DX at fair prices, held back by a TypeScript-only ceiling, genuinely heavy self-hosting, and a marketing frame that promises more agent magic than the platform actually contains. For TypeScript shops, this is close to a default choice; for everyone else, it is not in the running.

Sources

• https://trigger.dev/
• https://trigger.dev/pricing/
• https://trigger.dev/llms-full.txt
• https://trigger.dev/launchweek/2/trigger-v4-ga
• https://trigger.dev/docs/migrating-from-v3
• https://www.shipgarden.com/gallery/trigger-dev-v4-background-jobs-starter-review-open-source-2026
• https://hivebook.wiki/wiki/triggerdev-v445-open-source-background-jobs-and-durable-workflows-in-typescript
• https://dailyaifixs.com/blog/trigger-dev-pricing-2026-the-usage-catch
• https://trigger.dev/docs
• https://www.npmjs.com/package/@trigger.dev/sdk
• https://github.com/triggerdotdev/trigger.dev