Trigger.dev

Trigger.dev is an open-source background jobs and AI workflow platform built by Matt Aitken and Eric Allam, a Dublin-based team backed by Y Combinator and Series A investors including Standard Capital. It solves a specific and persistent problem: serverless functions like AWS Lambda and Vercel have hard timeout limits of seconds or minutes, but AI pipelines, document processing jobs, and multi-step agent workflows routinely need to run for minutes or hours. Trigger.dev lets developers define tasks as ordinary async TypeScript functions and run them without that constraint, on managed cloud infrastructure or on their own servers via Docker or Kubernetes.

The platform ships as a TypeScript SDK that integrates with Node.js, Bun, Next.js, NestJS, and most other TypeScript server environments. Core capabilities include durable execution with checkpoint-resume (tasks pause at await points and resume without losing state), automatic retries with configurable backoff, concurrent queuing with priority controls, cron scheduling, and a Realtime API that streams live task progress to frontend React apps. It integrates with Vercel AI SDK, OpenAI Agents SDK, LangChain, LangGraph, LlamaIndex, and direct model APIs from Anthropic, OpenAI, Google, Cohere, and Mistral. For AI-specific use cases, Trigger.dev also supports human-in-the-loop waitpoints, where tasks pause for human approval or input and resume exactly where they left off without consuming idle compute time. The current stable release is v4, with 14,800+ GitHub stars and Apache 2.0 licensing.

What Trigger.dev actually does in May 2026

Trigger.dev's core mechanism is checkpoint-restore execution. When a task reaches an await point (waiting for another task, an external event, a timer, or a human), the platform serializes the task's state using CRIU (Checkpoint/Restore In Userspace) and suspends the container. The task is not billed during this pause. When the awaited condition resolves, the task resumes exactly from the serialized state. This is fundamentally different from traditional serverless, where a function either finishes within its timeout or fails.

Tasks run in Bun-based workers (long-lived containers, not ephemeral Lambda-style invocations). Each task can specify its own machine configuration: CPU count, RAM, and optional system-level packages like FFmpeg, Puppeteer, or custom Python environments via build extensions. This means a video transcoding task and a lightweight email task can share the same project while running on appropriately-sized machines.

The Realtime API, released as GA in December 2024 and built on Electric SQL (an open-source PostgreSQL sync engine), enables React hooks like useRealtimeRun and useRealtimeBatch to stream live task state to browser UIs. A document processing pipeline can show users real-time progress: "Extracting text.. Summarizing chapter 3 of 8.." without polling. Sixty-plus organizations adopted the Realtime API within days of GA, including Midday.ai and Papermark.io.

Scheduling is handled natively via cron expressions or interval-based triggers, and tasks support fan-out patterns: a parent task can spawn hundreds of subtasks concurrently, all tracked in a single run tree with unified observability. The OpenTelemetry-powered dashboard shows full trace trees, logs, retry history, and performance metrics for every run.

"We decided to use Trigger.dev over Inngest or setting up our own dedicated solution.. [for] workflow automation, scalability, developer speed, cost efficiency, future-proofing." - Sohrab Fadai, Product Hunt, 2024

Where Trigger.dev sits versus Inngest and Temporal

The three most commonly compared tools in developer-first durable execution are Trigger.dev, Inngest, and Temporal. Each takes a fundamentally different architectural approach.

Inngest is the closest functional overlap with Trigger.dev, but the architecture differs in one critical way: Inngest does not run your compute. It is an API-only orchestration layer that calls your serverless endpoints via HTTP and delivers events. Developers must divide work into discrete step.run() functions, each independently retried and checkpointed at the step boundary. This means Inngest jobs are still constrained by serverless execution limits per step (roughly 15 minutes per step function call). Trigger.dev runs your code directly on its managed infrastructure (or self-hosted workers) in long-lived containers, with no step-division requirement. One continuous async function can run for hours. Trigger.dev's Hobby paid tier starts at $10/mo; Inngest's paid tier starts at $75/mo. Trigger.dev is Apache 2.0 and can be fully self-hosted with no feature restrictions. Inngest's self-hosting terms are more limited. On npm weekly download volume, Inngest draws roughly 85,000 weekly downloads versus Trigger.dev's 45,000, reflecting Inngest's longer market presence, though Trigger is growing faster by GitHub star trajectory.

Temporal sits in a different tier entirely: enterprise-grade durable execution for extremely complex, long-lived, polyglot workflows. Temporal uses event-sourced deterministic replay. Every workflow action is recorded to an append-only history log; on recovery, the workflow replays from the beginning, re-executing all activities up to the current point. This requires deterministic workflow code: no Date.now(), no random numbers, no direct I/O inside workflow functions. The learning curve is substantially steeper, requiring developers to understand Workflows, Activities, Workers, Task Queues, Namespaces, and Signals before shipping their first job. Temporal is polyglot (Go, Java, Python, TypeScript, PHP, .NET); Trigger.dev is TypeScript-first, with Python support only as an extension workaround. For enterprises needing multi-year workflow histories, complete audit trails, or Java/Go worker fleets, Temporal is the correct choice. For a TypeScript AI app team that needs reliable background jobs with minimal infrastructure overhead, Trigger.dev is faster and cheaper to operate. As one developer summarized on the Trigger.dev vs Temporal comparison page: "Moving to Trigger for background jobs was more reliable, cheaper, and easier."

Developers building Python-first ML pipelines should also evaluate Modal, which offers GPU-accelerated serverless compute and excellent Python tooling. For teams already using n8n or Activepieces for visual workflow automation, Trigger.dev is not a visual tool replacement but a code-layer complement for jobs that need durability and long-running execution.

What the agent loop reality looks like day-to-day

The development experience starts with installing the @trigger.dev/sdk package and adding a trigger.config.ts file to specify project settings. Tasks are exported functions decorated with task(). The Trigger.dev CLI runs a local dev server that connects to the Trigger.dev Cloud (or self-hosted) dashboard, where runs appear in real time during development. There is no separate queue infrastructure to configure or manage locally.

For AI agent workflows, the pattern is to define a root task that orchestrates subtasks. Each subtask can call LLM APIs, write to databases, send HTTP requests, and call wait.forEvent() to pause until an external signal arrives. Human-in-the-loop workflows add a waitpoint call that serializes the agent's state and sends a notification, then resumes when a human submits approval via the Trigger.dev dashboard or a custom API call.

Deploying to production is a single CLI command: npx trigger deploy. The CLI builds a Docker image, pushes it to Trigger.dev Cloud (or a self-hosted registry), and creates an immutable versioned deployment. Tasks that are already running continue on their deployed version; new tasks pick up the latest version. This atomic versioning prevents mid-flight runs from being broken by new code deploys, which is a common failure mode with queue-based systems.

"The ability to use TypeScript for defining workflows is brilliant." - Charlie, Product Hunt, 2024

Observability is built-in via OpenTelemetry. Every run produces a trace tree visible in the dashboard: each step, its duration, its inputs and outputs, and any nested subtask calls. Configurable error alerts can be routed to Slack or PagerDuty. Log retention ranges from 1 day on the Free tier to 30 days on Pro, with custom retention on Enterprise.

Who Trigger.dev is built for

Trigger.dev is purpose-built for TypeScript developers building AI-powered applications: Next.js apps with AI features, NestJS backends processing documents, any server-side code that calls LLM APIs and needs retry logic and observability. The tool is particularly valuable when AI pipelines consistently bump into serverless timeout limits or when developers find themselves writing brittle retry logic by hand.

Startups at the early stage will find the $10/mo Hobby plan sufficient for most production workloads, with compute billed separately at actual usage. Teams that process large volumes of AI inference jobs will find the Pro tier's 200+ concurrent runs and dedicated Slack support worth the $50/mo. Self-hosted deployments on Docker are documented and mature as of v4; Kubernetes self-hosting is available and described in a series of official blog posts.

Trigger.dev integrates naturally into stacks that already use Zapier or Make for no-code automation, serving a different layer. Where those platforms handle cross-app event routing without writing code, Trigger.dev handles what happens inside the code layer when jobs need to run for longer than a Lambda function permits.

Teams with significant open-source commitments appreciate the Apache 2.0 license. The entire platform can be self-hosted with no feature limitations, no run limits, and no vendor lock-in beyond the TypeScript SDK itself. The codebase has 14,800+ GitHub stars, active maintainers, and 617+ releases as of May 2026, indicating genuine staying power.

What Trigger.dev is not

It is not a Python tool. The SDK is TypeScript-only. Python scripts can be called as subprocesses inside tasks via build extensions, but there is no native Python SDK, no Python task definition, and no first-class support for Python package management inside tasks. Python-first ML teams running inference pipelines should use Modal, Prefect, or Temporal with Python workers instead.

It is not a no-code or low-code platform. There is no visual workflow builder, drag-and-drop nodes, or GUI for defining jobs. Everything is code. Business users or non-engineering teams cannot use Trigger.dev without developer involvement. For visual workflow automation, see n8n or Activepieces.

It is not a complete observability stack. While the built-in OpenTelemetry tracing is useful, teams with existing observability infrastructure (Datadog, Grafana, Honeycomb) will need to integrate Trigger.dev's traces into their existing tooling. The built-in dashboard is functional but not a replacement for purpose-built observability platforms.

It is not yet enterprise-hardened at Temporal's scale. The September 2025 production incident, in which a single customer's oversized error messages cascaded into three simultaneous cloud failures, revealed that the infrastructure was still being stabilized under rapid growth. The team published a thorough public incident report and shipped fixes within 48 hours, which is a positive signal. But teams for whom workflow failures are business-critical may want to wait for the MicroVM migration (planned to reduce Kubernetes dependency) before committing at enterprise scale.

Skip Trigger.dev if your team has Inngest already running well with step-based workflows and no timeout issues. The migration cost is real and the feature delta may not justify it. Skip it if you need battle-tested multi-year workflow audit trails: that is Temporal's domain, not Trigger's.