Trigger.dev

Quick Verdict

Trigger.dev is a strong fit for TypeScript teams moving multi-minute or multi-hour AI processing, batch jobs, schedules, and human approval flows out of short-lived server functions. Tasks can call any model or SDK, install system packages, run Python, browsers, or FFmpeg, and connect to an application through queues, concurrency controls, waits, retries, idempotency keys, and Realtime updates. It is not a visual agent builder, and it does not invent correct compensation logic for a business. Durable infrastructure makes recovery easier; it does not make every external side effect safe.

The repository had activity on July 21, 2026, and stable version 4.5.5 shipped on July 20. That release fixed per-item idempotency-key deduplication in batch triggers and improved internal synchronization retries, providing a current maintenance signal. Trigger.dev uses Apache-2.0 and supports Docker or Kubernetes self-hosting. Its managed cloud combines a monthly plan with actual execution seconds and run-invocation charges. Teams upgrading v4 SDK, CLI, and self-hosted images should keep versions aligned and replay critical jobs in staging.

Best For

• TypeScript teams running AI generation, document processing, media jobs, email sequences, and batches from Next.js, Node.js, or Bun applications.
• SaaS developers who need traces, logs, alerts, bulk replay, cancellation, and frontend progress updates for background jobs.
• AI application teams that pause work for human approval or an external callback and then resume durably.
• Developers who want job definitions in the same repository and review process as application code.
• It is not ideal for a Python-first team unwilling to retain a TypeScript orchestration layer, a simple cron-only need, or a workflow owned primarily by nondevelopers.

Key Features

• Durable background tasks: Ordinary TypeScript functions are deployed, queued, checkpointed, and restored by the platform for work beyond a conventional function window.
• Retries and error policies: Global and task-level maximum attempts, exponential backoff, error-specific handling, and AbortTaskRunError cover transient and permanent failures.
• Idempotent triggering: An idempotencyKey deduplicates the same business event, supports a TTL, and can be supplied per item in a batch.
• Queues and concurrency: Task, tenant, or user limits combine with TTL, priority, batches, and debounce to manage bursts and fairness.
• Waits and human approval: Waits and Waitpoints pause execution for time, events, or approval. Longer built-in waits checkpoint rather than consuming active compute.
• Realtime and observability: Applications can subscribe to progress and AI streams, while the dashboard provides traces, logs, tags, metadata, alerts, replay, and cancellation.
• Versions and environments: Dev, Preview, Staging, and Prod support, plus atomic task versions and build extensions, provide a controlled path to deployment.

Use Cases

Typical workloads include long-document extraction and summarization, multi-stage LLM calls, image or video generation, embedding batches, tool-using AI agents, scheduled synchronization, webhook fan-out, and workflows that continue after human review. Split different failure domains into smaller tasks. Model calls, file conversion, and external writes should have independent traces and retry policies rather than living in one enormous run. Rate limits may deserve response-header-based backoff; exhausted credit or invalid input should stop rather than retry.

Automatic retries amplify side-effect risk. Email, order creation, charges, deletion, and publishing require a business idempotency key, and the task should query the external system before replaying an uncertain write. Browser or computer-use agents also need a domain allowlist, separate accounts, temporary credentials, and isolated execution. Web prompt injection must not change task permissions. Destructive actions, final submission, and payment should pause at a Waitpoint or business approval. Durable execution and sandboxes improve resilience, but they do not eliminate malicious input, secret exposure, or incorrect business logic.

Pricing

The July 21, 2026 cloud rate card listed Free at $0 per month with $5 monthly credits, 20 concurrent runs, and one-day logs; Hobby at $10 with $10 credits, 50 concurrency, and seven-day logs; Pro at $50 with $50 credits, 200 concurrency, and 30-day logs; and Enterprise by quote. Compute is also billed by active execution second. The default Small 1x machine, with 0.5 vCPU and 0.5 GB RAM, was $0.0000338 per second. Each run that starts on managed workers adds $0.000025; development runs do not incur that invocation fee.

Built-in waits longer than five seconds checkpoint, and waiting time does not count as active compute. Standard monthly-budget and spike alerts are available, but an alert is not a hard stop. Paid-plan overages continue at published rates, while Free requires an upgrade after included credits are exhausted. Set organization budgets, task maxDuration, concurrency, maximum attempts, batch size, and provider token caps, then add application logic that stops or degrades when a threshold is reached.

Pros

• TypeScript-native tasks stay with application source control, tests, and code review.
• Long execution, queues, checkpoints, retries, idempotency, and concurrency are first-class capabilities.
• Traces, logs, alerts, Realtime, replay, and cancellation cover the run lifecycle.
• Checkpointed waits reduce idle compute cost for approvals and delayed flows.
• Apache-2.0 licensing provides a managed-cloud or Docker/Kubernetes self-hosting choice.
• Public per-second machine and invocation rates support unit-economics modeling.
• Version 4.5.5 directly addressed idempotent batch behavior, relevant to reliable production use.

Cons

• Orchestration remains JavaScript and TypeScript first; Python is generally called through a build extension.
• Automatic retries do not understand side effects and can duplicate messages, writes, or charges without idempotency and compensation.
• Cloud cost combines plans, execution time, machine size, run count, and external model usage, making it more complex than a fixed subscription.
• Budget alerts are not a default hard cap, so runaway loops and high concurrency can still create overages.
• Self-hosting returns database, scaling, upgrades, monitoring, backups, and disaster recovery to the operator.
• It is less approachable to nondevelopers than a canvas such as n8n.

Alternatives

FAQ

Does Trigger.dev really avoid serverless timeouts?

It is designed for long-running tasks and allows jobs to run as long as needed. Production tasks should still set maxDuration, business deadlines, and external API timeouts to prevent stuck work from consuming resources indefinitely.

Can automatic retries execute a task twice?

A failed attempt can run again. Pure computation is usually safe, but writes need an idempotency key, unique business ID, and result lookup. Permanent errors should explicitly stop retrying.

Is the Free plan enough?

It is useful for prototypes and low-volume tasks, with $5 monthly credits, 20 concurrency, and one-day logs. Persistent production work often needs more credits and longer retention.

Does waiting for human approval keep billing compute?

Official pricing says built-in waits longer than five seconds checkpoint and do not bill active compute while waiting. Models, databases, and external services may still have their own charges.

How should a team cap an AI background-job budget?

Combine platform budget alerts with duration, concurrency, retry, and model-token limits. Attribute cost by task, tenant, and model, then stop, downgrade, or require review at a threshold.

Can Trigger.dev be self-hosted?

Yes. Official Docker Compose and Kubernetes guidance is available. Open-source software does not make the deployment free; the team operates databases, workers, storage, upgrades, and availability.

Bottom Line

Trigger.dev turns AI background work from “keep a function alive” into observable, recoverable, concurrency-controlled, and replayable execution. It is especially well matched to TypeScript product teams, and version 4.5.5 confirms active maintenance around idempotency and reliability. The production decision should focus on side effects: design idempotency, compensation, and approval before enabling retries, and cap spend by model, task, and tenant. Benchmark one real workload using execution seconds, run count, retry rate, and external token cost to compare managed cloud with self-hosting.