# Trigger.dev: Long-Running TypeScript Tasks Without Timeouts

> Trigger.dev is an open-source platform for running TypeScript background tasks and AI agent workflows that need more time than serverless platforms allow. It handles retries, queues, observability, and elastic scaling without requiring infrastructure to manage, and can be self-hosted.

**triggerdotdev/trigger.dev** — Project brief: Trigger.dev, build and deploy fully managed AI agents and workflows.

- Repository: https://github.com/triggerdotdev/trigger.dev
- Website: https://trigger.dev/changelog
- Stars: 16,424 · Forks: 1,476
- Language: TypeScript
- License: Apache-2.0
- Published: 2026-08-04 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/triggerdotdev-trigger-dev

## The Problem Trigger.dev Solves

Serverless platforms like AWS Lambda and Vercel impose strict execution time limits, typically a few minutes at most. AI agent workflows, video processing tasks, and long-running data pipelines routinely exceed those limits. The standard workaround is to split a task into smaller steps and chain them, which requires managing state between calls and adds engineering complexity.

Trigger.dev eliminates the timeout constraint entirely. The README describes its core capability as executing tasks with no timeouts. Beyond that, it adds automatic retries on failure, durable queues for controlling concurrency, and a full trace view of every task run so engineers can inspect exactly what happened at each step.

The platform also handles elastic scaling: deployed tasks scale to match load without server provisioning. The README notes that this applies to both the hosted cloud and self-hosted deployments.

## Writing and Deploying a Task

A Trigger.dev task is written in TypeScript inside the application codebase. The README gives the minimal task structure:

```ts
import { task } from "@trigger.dev/sdk";

export const helloWorld = task({
  id: "hello-world",
  run: async (payload: { message: string }) => {
    console.log(payload.message);
  },
});
```

Each task requires a unique `id` string and a `run` function. The `run` function can execute for any duration because there is no timeout constraint. Any code that works in Node.js works inside a task.

Trigger.dev uses the `@trigger.dev/sdk` npm package for the TypeScript SDK. After writing tasks, deployment sends them to the Trigger.dev cloud or a self-hosted instance. The platform supports Development, Staging, Preview, and Production environments, which allows testing tasks before they reach production traffic.

## Durability, Retries, and Checkpointing

The README describes Trigger.dev as inherently durable through a checkpointing system. Tasks that are paused, such as while waiting for a human approval step, do not consume CPU or memory during the wait. The checkpoint-resume system stores the task state so execution can continue from the same point after the wait ends.

Automatic retries kick in when a task throws an uncaught error. The platform attempts to run the task again according to configurable retry settings. Idempotency support prevents double execution when retries are used.

Queues control how many tasks run concurrently. The README lists concurrency and queues as a key feature, with rules settable per queue. This matters for tasks that call external APIs with rate limits: a queue with a concurrency limit of one ensures those calls stay within bounds without custom rate-limiting logic in the task code.

## Human-in-the-Loop Waitpoints and Realtime Updates

Trigger.dev supports pausing task execution at a decision point and waiting for human input before continuing. The README calls this feature Waitpoints and describes it as programmatically pausing tasks until a human can approve, reject, or give feedback. The task holds its state during the pause.

Realtime subscriptions let a frontend application receive updates as a task progresses. The README describes this as moving background jobs to the foreground: a client subscribes to a run and receives state changes in real time, including LLM streaming responses. This is implemented through React hooks in the @trigger.dev/react-hooks package.

Batch triggering allows starting multiple runs of a task in a single call with `batchTrigger()`, each with different payloads. Scheduled tasks support cron expressions for recurring work, with schedules of up to a year.

## Build Extensions and Runtime Flexibility

Trigger.dev tasks are not limited to Node.js packages. The README describes build extensions as hooks into the build system that customize what gets deployed alongside the task code. Through these extensions, a task can run Python scripts, use FFmpeg for video processing, launch a headless browser, or execute any system package.

This contrasts with standard serverless platforms where the runtime environment is fixed. On Trigger.dev, the deployed task can include OS-level packages bundled during the build process, making it practical for tasks that need tools not available in a standard Node.js container.

The machine configuration feature lets individual tasks specify how many vCPUs and gigabytes of RAM they need. Different tasks in the same project can run on different machine sizes, so a lightweight polling task and a CPU-intensive processing task can coexist in the same deployment without over-provisioning for all of them.

## Self-Hosting and Deployment

Trigger.dev can be self-hosted. The repository includes Docker Compose files for running the full stack locally: the main compose file is at docker/docker-compose.yml and the .env.example documents the required environment variables including DATABASE_URL for PostgreSQL and APP_ORIGIN for the application URL.

The repository also includes Helm chart releases for Kubernetes deployments; the most recent Helm chart release is helm-v4.6.3, published on 2026-09-17.

The managed cloud at trigger.dev handles all infrastructure for teams that do not want to run their own instance. The README notes that free tier availability depends on the current pricing page, which is not reproduced in the repository documentation. The license is Apache-2.0.

The last push was on 2026-09-24 and the most recent application release is v4.6.4, published on 2026-09-22.

## How Trigger.dev Compares to Temporal

Temporal is a workflow orchestration platform that also targets durable execution of long-running processes. Both Trigger.dev and Temporal handle retries, state persistence across failures, and task coordination. The practical differences are in the developer experience and deployment model.

Temporal uses a workflow-as-code model with a SDK that handles state serialization explicitly, including deterministic replay of workflow history. It targets polyglot environments with SDKs for Go, Java, Python, TypeScript, and PHP. Trigger.dev is TypeScript-first and does not require developers to reason about workflow determinism; the checkpointing is handled by the platform rather than the developer.

For TypeScript-only teams building AI agents who want a simpler mental model, Trigger.dev's approach is more direct. For teams with existing Temporal infrastructure or workflows that span multiple languages, Temporal's polyglot model covers cases Trigger.dev does not.

## Conclusion

Trigger.dev is a strong fit for TypeScript teams building AI agents or background workflows that exceed the time limits of AWS Lambda, Vercel, or similar serverless platforms. The self-hosting option and the Apache-2.0 license mean teams with data residency requirements are not locked into the managed cloud. The tradeoff is operating a more complex infrastructure than a simple job queue. Teams whose tasks stay within standard serverless timeouts and do not need durable execution or human-in-the-loop approval steps will find the added overhead hard to justify.

## FAQ

### What is Trigger.dev for?

Trigger.dev runs TypeScript background tasks and AI agent workflows that need more execution time than serverless platforms allow. It handles automatic retries, queues, checkpointing, and observability without requiring infrastructure management.

### Is Trigger.dev free?

The Trigger.dev source code is Apache-2.0 licensed and can be self-hosted at no software cost. The managed cloud at trigger.dev has a free tier; the exact terms are on their pricing page. Self-hosting requires running the Docker Compose or Kubernetes stack documented in the repository.

### Is Trigger.dev open source?

Yes. The repository at triggerdotdev/trigger.dev is published under the Apache-2.0 license. The README links to self-hosting documentation and the repository includes Docker Compose files for running the full platform locally.

### How does Trigger.dev compare to n8n?

n8n is a visual workflow automation tool with a drag-and-drop interface that connects services via pre-built integrations. Trigger.dev is a code-first platform where tasks are written in TypeScript, making it suited for developers who need full programmatic control, custom logic, and long-running execution. The two tools target different primary users.

### How do I use Trigger.dev?

Install the @trigger.dev/sdk npm package, define tasks using the `task()` function with a unique id and a `run` function, then deploy to the Trigger.dev cloud or a self-hosted instance. The README's quick-start code example shows the minimal task structure.

## Sources

- [Official documentation](https://trigger.dev/changelog)
- [Official README](https://github.com/triggerdotdev/trigger.dev#readme)
- [Project repository](https://github.com/triggerdotdev/trigger.dev)
- [Release notes](https://github.com/triggerdotdev/trigger.dev/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/triggerdotdev-trigger-dev