Trigger.dev is an open-source platform for building durable AI agents and background workflows in TypeScript. Teams write tasks in their existing codebase with the SDK and CLI, then get long-running execution with no timeouts, automatic retries, queues with concurrency control, and full run tracing without building queue or worker infrastructure. The Apache-2.0 licensed core runs self-hosted from the public triggerdotdev/trigger.dev repository or as the managed Trigger.dev Cloud, which meters compute seconds and run invocations from a free tier up to enterprise plans.[1][2][3]
Quick verdict
Trigger.dev fits TypeScript teams that run long-lived background work or AI agents and want durable tasks, retries, queues, and tracing without operating queue infrastructure. Its documented strengths are no-timeout execution, durable cron and concurrency controls, realtime frontend streaming, human-in-the-loop pauses, and an Apache-2.0 licensed core that self-hosts via Docker or runs on the metered Cloud. The material constraints are its code-first TypeScript surface, Cloud-only warm starts, auto-scaling, and checkpoints, and usage-metered pricing that needs volume modelling. Choose Trigger.dev when your team writes backend code and owns async reliability; choose the published catalogue peer Inngest when you prefer step functions embedded in your existing app.[1][2][3][4][5]
What Trigger.dev does
No-timeout long-running tasks Tasks execute with no timeouts, unlike typical serverless platforms, so resource-heavy and hours-long agent runs complete instead of being killed mid-flight.[1][2]
Durability, retries, and queues Durable tasks ship with retries, queues, and idempotency keys, so a retried or duplicated trigger runs once and transient downstream failures recover without bespoke retry code.[1][2]
Durable cron schedules Recurring schedules attach directly to tasks with cron-style durability, covering recurring background work without operating a separate scheduler fleet.[1][2]
Concurrency and queue controls Per-task and per-tenant concurrency limits and queues cap how many runs execute at once, protecting fragile APIs and databases during bursts.[1][2]
Realtime run updates The Realtime API with React hooks streams run status and LLM output to the frontend, moving background jobs into foreground user experiences with subscription support.[1][2]
Human-in-the-loop pauses Runs pause programmatically on waitpoints until a person approves, rejects, or gives feedback, and a waiting run consumes no compute while paused.[1][2]
Runtime freedom via build extensions Build extensions hook into the build system so tasks can run system packages such as browsers, Python scripts, and FFmpeg alongside TypeScript code.[1]
Observability per run Every run records status, retries, traces, and logs, with error alerts and AI-call spans carrying model, token counts, cost, and latency.[1][2]
Who will love it
TypeScript teams running agents Backend teams already writing TypeScript who need durable AI-agent and workflow execution will feel at home: the SDK, CLI, and AI-assistant integrations match how they already build.[1][2]
Long work that outgrows serverless Teams hitting serverless timeouts on heavy jobs get the clearest win, since no-timeout execution with retries and queues is the documented core promise.[1][2]
Operators needing data control Organizations with data-residency or infrastructure-control requirements can run the same platform self-hosted on their own containers instead of the managed Cloud.[1]
Where it falls short
Code-first surface only Everything is authored as TypeScript with the SDK and CLI, so non-engineering operators cannot build or modify workflows without developer involvement.[1][2]
Self-hosting gaps versus Cloud Self-hosted instances lack warm starts, auto-scaling, checkpoints, and dedicated support, and the operator assumes all responsibility for security, uptime, and data integrity.[1]
Metered pricing needs modelling Cloud billing meters both compute seconds and run invocations on top of plan fees with paid add-ons, so costs scale with volume and need volume modelling rather than a flat license comparison.[1]
Trigger.dev versus Inngest
Trigger.dev versus Inngest Both are durable execution options for background jobs and agent workflows, and Trigger.dev publishes a direct comparison page against Inngest. The positioning difference that page draws: Trigger.dev runs durable tasks on its own workers or self-hosted containers with no timeouts, while Inngest orchestrates step functions inside the reader's existing app. Choose Trigger.dev when you want Apache-2.0 licensed, self-hostable task execution with realtime frontend streaming; evaluate the published catalogue peer Inngest when you prefer functions embedded in your own app. This is an editorial comparison, not a vendor endorsement.[1][2][3]
Questions worth asking
How much does Trigger.dev cost per month?
Trigger.dev Cloud pricing checked October 13, 2026: Free at $0 per month with 20 concurrent runs; a $10 per month tier with 50 concurrent runs; Pro at $50 per month with 200-plus concurrent runs; and an Enterprise tier. Usage is metered two ways, compute seconds plus a $0.25 invocation cost per 10,000 runs, with per-seat, branch, and dashboard add-ons, so model run volume and duration before committing.[1]
Can I self-host Trigger.dev?
Yes. The self-hosting overview documents running the platform on your own infrastructure as version-tagged Docker containers split into a webapp and a worker, functionally the same as Cloud except for warm starts, auto-scaling, checkpoints, and dedicated support. You own provisioning, updates, security, and scaling, and should lock container tags with your CLI version.[1][2]
Is Trigger.dev no-code?
No. Trigger.dev is code-first: you write tasks and agents in TypeScript with the SDK and CLI, optionally with AI coding assistants, the MCP server, and Skills generating that code. There is no documented visual builder or no-code surface; teams uncomfortable writing backend code will feel that immediately.[1][2]
Is Trigger.dev really open source?
The core is Apache-2.0 licensed, a genuine OSI license: the LICENSE file at the repository root carries the full Apache 2.0 text and the docs state this explicitly. That covers the self-hostable core; the managed Cloud service around it is a commercial offering with its own pricing, which is the normal open-core-adjacent split, not a license contradiction.[1][2]
Sources and editorial review
Source research. Reviewed on October 13, 2026. Written by Sanjib Sah. AI assisted; reviewed by a human editor.
We have not run or tested this product.
- triggerdotdev/trigger.dev README
official · Observed October 13, 2026
Positioning, features, SDK, realtime, self-hosting links, license and npm badges.
- triggerdotdev/trigger.dev on GitHub
official · Observed October 13, 2026
Canonical repository identity, owner and name.
- triggerdotdev/trigger.dev LICENSE
official · Observed October 13, 2026
Full Apache License 2.0 text at the repository root.
- Trigger.dev docs introduction
official · Observed October 13, 2026
Open-source positioning, Apache-2.0 core, no-timeout tasks, Cloud versus self-host, core concepts.
- Trigger.dev self-hosting overview
official · Observed October 13, 2026
Docker container architecture, Cloud-only features, operator responsibilities, v3 end of life.
- Trigger.dev Cloud pricing
official · Observed October 13, 2026
Free, $10, Pro $50, Enterprise tiers; compute-second plus per-run-invocation metering.
- Trigger.dev changelog
official · Observed October 13, 2026
Active development evidence, latest v4.7.3 release date.
- Trigger.dev vs Inngest
official · Observed October 13, 2026
Official vendor comparison framing both as durable execution options.
- triggerdotdev/trigger.dev package.json
official · Observed October 13, 2026
pnpm/turbo TypeScript monorepo toolchain evidence.
Compared with these products
No explicit proprietary baseline is recorded.