What It Does
Trigger.dev is an open-source platform for running TypeScript background jobs, scheduled tasks, and AI agent workflows without the execution time limits imposed by serverless platforms like Vercel or AWS Lambda. Tasks are written as plain async TypeScript functions and deployed alongside your existing codebase; Trigger.dev handles queuing, retries, concurrency management, observability, and compute lifecycle.
The v4 release (January 2026) introduced a new Run Engine with warm-start container reuse (100–300ms repeat start times), Waitpoint primitives for human-in-the-loop approval flows, HTTP callback support for third-party service integration, and schemaTask for exposing tasks as tools compatible with the Vercel AI SDK and Anthropic Claude SDK. The platform is positioned as an AI agent runtime, though architecturally it is a well-engineered background job system applied to agentic workloads.
Key Features
- No-timeout execution: Container-based tasks run for seconds to hours without platform-imposed limits; warm starts at 100–300ms, cold starts in the seconds range
- Durable Waitpoints: Pause execution pending a token redemption, HTTP callback, or datetime — enabling human-in-the-loop approval workflows
- Cron scheduling: Native support for scheduled tasks without managing a separate scheduler; 10 schedules on free tier, 100 on Hobby, 1000+ on Pro
- Concurrency and queue control: Per-task concurrency limits, queue priorities, and bulk run management from the dashboard
- AI agent integration:
schemaTaskexposes tasks as type-safe tools for Vercel AI SDK and Anthropic SDK; supports parallelization, prompt chaining, and evaluator-optimizer patterns - Realtime frontend integration: WebSocket-based Realtime API with React hooks for streaming task status to the UI
- Build extensions: Native integrations for Prisma, Puppeteer, Playwright, FFmpeg, Python execution, and custom esbuild plugins
- OpenTelemetry exporters: Trace correlation with external observability platforms
- Multi-environment support: Dev, Preview (Hobby+), and Prod environments with version-safe deployments — old runs continue on v3 engine while new runs use v4 during migration
- Self-hostable: Apache 2.0; Docker-based self-hosting available but explicitly documented as not production-ready
Use Cases
- AI workflow automation: Orchestrating multi-step AI pipelines (PDF extraction, embedding, summarization) that exceed serverless timeout windows
- Media processing: FFmpeg video transcoding, image generation, or audio processing that requires sustained CPU for minutes
- Batch operations: Processing millions of records (emails, interactions, exports) with built-in parallelism and retry logic
- Human-in-the-loop AI agents: Workflows that pause for human approval, content review, or data correction before continuing
- Scheduled data pipelines: Replacing ad-hoc cron jobs or Vercel cron with observable, retriable, versioned task execution
- Browser automation: Running Puppeteer/Playwright scraping or screenshot generation tasks at scale
Adoption Level Analysis
Small teams (<20 engineers): Good fit for teams already on the JavaScript/TypeScript stack who need reliable background processing without standing up Bull/BullMQ + Redis + workers. The free tier (20 concurrent runs, $5 monthly compute credit) covers modest workloads. Managed cloud removes infrastructure ops overhead entirely. Self-hosting is not recommended at this scale due to the productionization gap.
Medium orgs (20–200 engineers): Solid fit. The Pro tier ($50/month base + compute usage) is cost-effective for teams running thousands of AI pipeline tasks or media processing jobs daily. Dedicated Slack support, 200+ concurrent runs, and 30-day log retention address production monitoring needs. Teams requiring strict data residency or VPC isolation will find self-hosting under-documented.
Enterprise (200+ engineers): Limited fit. Enterprise tier adds SOC 2, SSO, and RBAC, but pricing is custom and the platform lacks the battle-tested operational depth of Temporal for mission-critical workflows. Self-hosting for enterprise on-prem use is explicitly non-production-ready. Teams needing guaranteed exactly-once semantics, deterministic replay, or complex saga patterns should evaluate Temporal instead.
Alternatives
| Alternative | Key Difference | Prefer when… |
|---|---|---|
| Inngest | Event-driven, calls your serverless endpoints; no dedicated compute workers | You’re fully serverless (Vercel/Cloudflare) and need event fan-out; no tolerance for worker management |
| Temporal | Industrial-strength durable execution with event-sourcing replay; exactly-once semantics | You need multi-language SDKs, complex saga patterns, or mission-critical workflow durability at enterprise scale |
| Bull/BullMQ + Redis | Self-managed, no managed cloud, fully portable | You want maximum control, no vendor dependency, and are comfortable operating Redis and worker infrastructure |
| AWS Step Functions | JSON-based state machines, serverless, native AWS integration | Your stack is AWS-native and you prefer declarative workflow definitions over code |
| Modal | Serverless GPU compute, Python-first | You need GPU access for ML workloads; Python ecosystem, not TypeScript |
Evidence & Sources
- Trigger.dev GitHub (14.6k+ stars)
- Trigger.dev v4 GA announcement
- TypeScript orchestration comparison: Temporal vs Trigger.dev vs Inngest
- Trigger.dev vs Inngest vs Temporal 2026
- Self-hosting limitations — official docs
- Product Hunt reviews
Notes & Caveats
- Self-hosting gap is material: Official documentation states the self-hosting guide “won’t result in a production-ready deployment.” No resource limits are enforced on the Docker provider — runaway tasks can consume all machine resources. No ARM worker support as of April 2026.
- Vendor lock-in on durability: Task state persistence, checkpoint-resume, and queue reliability are tightly coupled to Trigger.dev’s platform (cloud or self-hosted stack). Migrating to a different orchestration system requires rewriting task definitions and losing run history.
- MicroVM cold starts still pending: The migration to Firecracker MicroVMs for sub-500ms cold starts was announced on the feedback board but not yet delivered as of April 2026. Cold starts on new deployments currently take seconds.
- API churn during v3 to v4 migration: The upgrade from v3 to v4 involves a period where both run engines execute concurrently, potentially doubling concurrency usage and costs.
- TypeScript-only: No Python, Go, or Java SDKs. Teams running polyglot backends must use HTTP callbacks or API calls for non-TypeScript tasks — a meaningful constraint vs. Temporal’s multi-language SDK support.
- Pricing model: Compute pricing ($0.0000169–$0.00068/sec) is pay-per-execution, which is cost-effective for bursty workloads but can become expensive for sustained CPU-heavy tasks running continuously.