Trigger.dev
Trigger.dev · Trigger.dev: Open-Source Durable Runtime for TypeScript AI Agents and Background Workflows, with Webhook Triggers and Slack and Linear Agents
Trigger.dev is an open-source (Apache 2.0) platform for running AI agents and long-running background tasks written in TypeScript, adding retries, queues, human-approval waits, realtime streaming and tracing, on a managed cloud or your own Docker or Kubernetes setup. It suits TypeScript teams whose agents run longer than a web request or wait on people and outside events, and who would rather not operate their own workers.
Best for
TypeScript teams putting AI agents and long-running background jobs into production who want retries, queues, human-approval waits, webhook triggers and tracing without running their own workers, and who may want to self-host later
Not ideal for
Python-first teams, teams looking for a framework that defines prompts, tools and agent handoffs for them, and self-hosters who depend on idle waits releasing compute
Who it's for
TypeScript and Node.js developers and platform teams running AI agents, LLM pipelines and other long-running background work in production
Capabilities
- Tasks are plain async TypeScript functions with any npm package, no workflow DSL and no determinism rules, deployed from the CLI alongside the rest of your codebase with atomic versioning and rollback
- No platform-imposed maximum run duration: you set a default maxDuration per project and override it per task or run, or turn it off
- Durable execution with configurable retries, named queues, per-queue and per-tenant concurrency limits, idempotency keys and selectable machine sizes from 0.25 vCPU up to 8 vCPU and 16 GB RAM
- Checkpointed waits on Trigger.dev Cloud: timers, child tasks and human-approval tokens snapshot the process and release the machine, and paused time is not billed
- chat.agent: each AI SDK conversation runs as one durable task that survives refreshes, deploys and crashes, with sub-agents, stop and steering, human-in-the-loop tool approvals and a useChat transport with no API route
- Hosted webhook endpoints declared in code that verify, deduplicate and record events from 40+ named providers plus Standard Webhooks, Svix and custom HMAC or key schemes, then route them to up to 25 subscribers with typed filters (public beta)
- Slack and Linear channel packages that turn a chat.agent into a native Slack or Linear agent, with replies in the thread or issue and approvals as Approve and Deny buttons
- Realtime run status, metadata and LLM token streams to React hooks or backend subscribers, plus input streams for sending approvals or cancel signals into running tasks
- Observability with per-run traces and logs, OpenTelemetry export, LLM spans showing model, tokens, cost and latency per AI SDK call, custom dashboards, a query language and alerts
- Build extensions that add system packages to deployed tasks, such as Playwright or Puppeteer browsers, FFmpeg, Prisma or a Python runtime for scripts
- Managed cron schedules, including per-tenant dynamic schedules, and a REST Management API for triggering and managing runs
- AI Prompts: prompt templates defined in code with typed variables, versioned on each deploy, overridable from the dashboard without redeploying, and tracked for token usage, cost and latency
- MCP server that lets Claude Code, Cursor, Windsurf and other AI editors search the docs, trigger and inspect runs, and deploy projects
Limitations
- TypeScript only: there is no Python SDK, and Python code runs as scripts called from a TypeScript task through the Python build extension
- When an attempt fails, the retry runs the task again from the top; there is no step-level replay, so durability comes from splitting work into child tasks and using idempotency keys
- Self-hosted instances lack checkpoints, warm starts and autoscaling, which the docs list as cloud-only, so waits on a self-hosted instance hold worker capacity instead of releasing it
- Self-hosting means running the webapp (with Postgres and Redis) and workers yourself; the Docker Compose guide asks for at least 3 vCPU and 6 GB RAM for the webapp and 4 vCPU and 8 GB RAM for a worker, with community support only
- Cloud cost is usage-based (per-second compute by machine size plus a per-run fee on top of the plan's included credits), so heavy or long-running agent workloads need estimating; the Free plan stops running tasks once its $5 of monthly credit is used
- Hosted webhooks are a public beta, and each plan caps webhook ingest per endpoint (100 requests every 10 seconds on Free, 1,000 on Pro)
- It does not supply the agent loop: tools, model calls and orchestration come from the AI SDK, another framework or your own code, and AI Prompts only manages prompt templates
- SSO, role-based access control and the SOC 2 report are reserved for the Enterprise plan, and a HIPAA BAA is a $500/month add-on
Use cases
- Running a multi-step AI agent or research job that takes minutes to hours, beyond what a serverless function allows
- Pausing an agent for a human approval that may take days, without paying for the idle machine on the cloud
- Shipping a chat agent in a Next.js app whose conversations survive page refreshes, deploys and crashes
- Starting an agent from a Stripe, GitHub, Shopify or Resend webhook, or putting it in Slack threads and Linear issues
- Wrapping the Claude Agent SDK or OpenAI Agents SDK in a task to get retries, queues, machine sizing and tracing in production
- Moving non-AI background work such as video processing, document conversion and scheduled jobs onto the same platform
Our take
Trigger.dev is best understood as durable infrastructure that happens to be very good at hosting agents, not as an agent builder. Its strongest argument is that agents stay ordinary TypeScript: you keep your AI SDK, Claude Agent SDK or Mastra code and gain retries, queues, approvals that can wait for days, and traces, without adopting a deterministic workflow model. The new webhook layer and Slack and Linear channels move it closer to an agent platform, letting events from other services start agents directly, but that part is a public beta. Two details matter when choosing. Retries restart a task from the top, so long agents should be broken into child tasks. And the cost-saving checkpointed waits exist only on the cloud; a self-hosted instance runs the same code but keeps waiting runs on a worker. For TypeScript teams that want managed durable execution with an open-source exit, it is a strong default; Python teams and anyone wanting the platform to design the agent for them should look elsewhere.
Who should use it
TypeScript teams that already write agents with the AI SDK, Claude Agent SDK, OpenAI Agents SDK or Mastra and need them to run for a long time, survive deploys and crashes, wait on humans or external events, or start from webhooks, Slack or Linear, without building their own job queue and workers.
Who should skip it
Python-first teams, teams that want a framework or no-code builder to define the agent's prompts and tools, and organizations that must self-host and depend on idle waits releasing compute, which only the cloud provides.
Strengths
- Agents stay ordinary TypeScript with any npm package, so adopting it means moving code rather than rewriting it in a workflow DSL
- No maximum run duration, and on the cloud waits for approvals, timers or child tasks are checkpointed and not billed
- Works with the agent tooling you already use, including the AI SDK, OpenAI Agents SDK, Claude Agent SDK and Mastra
- Apache 2.0 with the full stack self-hostable via Docker Compose or a Helm chart, so there is a path off the managed cloud
- Webhook triggers, Slack and Linear agents, realtime streaming and LLM cost tracing come built in rather than as separate services
- Free cloud plan with $5 of monthly usage and no credit card, with paid plans from $10/month
- Trigger.dev Cloud is SOC 2 Type II and GDPR compliant, and a HIPAA BAA is available as an add-on on paid plans
Weaknesses
- TypeScript only, with Python limited to scripts run from TypeScript tasks
- Retries rerun the whole task, so long tasks need to be split into child tasks to avoid redoing work
- Self-hosted instances lose checkpointing, warm starts and autoscaling
- Usage-based compute billing makes costs for heavy agent workloads harder to predict than a flat fee
- Webhooks, the newest agent-facing feature, are still in public beta
Trigger.dev pricing
Free
$0/month
Billed monthly
- $5 of usage credit per month, no credit card
- 20 concurrent runs, 5 team members, 10 schedules
- 1-day log retention, community support
Hobby
$10/month
Billed monthly
- $10 of usage credit included
- 50 concurrent runs, 100 schedules, 5 preview branches
- 7-day log retention, HIPAA BAA add-on available
Pro
$50/month
Billed monthly
- $50 of usage credit included
- 200+ concurrent runs ($10/month per extra 50), 25+ team members ($20/month per extra seat)
- 30-day log retention, dedicated Slack support, AWS PrivateLink
Enterprise
Custom
- Custom discounts and log retention
- SSO, role-based access control, priority support
- SOC 2 and penetration test reports
Self-hosted
Free (Apache 2.0)
- Docker Compose or Kubernetes Helm chart
- No checkpoints, warm starts or autoscaling
- Community support
Free tier limits: The Free plan includes $5 of usage credit per month, 20 concurrent runs, 10 schedules and 1-day log retention; once the credit is used you need to upgrade to keep running tasks.
Note: Compute is billed per second while tasks execute, by machine size: from $0.0000169/second (Micro, 0.25 vCPU, 0.25 GB) through $0.0000338/second (default Small 1x, 0.5 vCPU, 0.5 GB) to $0.00068/second (Large 2x, 8 vCPU, 16 GB), plus $0.000025 per run ($0.25 per 10,000 runs). DEV environment runs are free, and checkpointed waits on child tasks or long timers are not billed. On paid plans, usage beyond the included credits is billed at these rates; billing alerts and spike alerts can be configured. Receiving webhooks has no separate charge. A HIPAA BAA is a $500/month add-on. API requests are limited to 1,500 per minute on all plans.
Technical specs
API pricing
Usage-based on Trigger.dev Cloud: per-second compute by machine size plus $0.000025 per run, drawn against each plan's included monthly credits; no license fee when self-hosted
Where Trigger.dev excels
Approval-gated agent actions
An agent can prepare an action, wait on a human-approval token for hours or days, and resume on the same line of code; on the cloud the run is checkpointed while it waits, so the idle time is not billed.
Event-driven support or ops agents
Hosted webhook endpoints verify and deduplicate events from Slack, Stripe, GitHub or Linear and route each one to the right agent, with every delivery logged and replayable.
Durable chat inside a web app
chat.agent keeps each AI SDK conversation in one long-lived task, so a refresh, redeploy or crash does not lose the conversation state or the stream.
Production hosting for Claude Agent SDK tasks
Wrapping the Claude Agent SDK in a task gives it a chosen machine size, retries, cancellation and a full trace in the dashboard without managing servers.
Trigger.dev vs. competitors
Trigger.dev vs. Opengeni
Opengeni is also an Apache 2.0 runtime for long-running agents, built around a replayable Postgres event log per session, approvals before risky tool calls and sandboxes or enrolled machines for tool execution. Trigger.dev is a general durable task runtime: you bring the agent loop as TypeScript code, and it adds queues, machine sizing, webhooks and realtime streaming that also serve non-agent background jobs.
Trigger.dev vs. Omnara
Omnara is an open-source managed agent platform where you define an agent in a YAML config and Omnara runs the agent loop on the model you pick, with tools on cloud sandboxes or your own machines. Trigger.dev does not run an agent loop for you; you write it in TypeScript with the SDK of your choice and Trigger.dev executes it durably.
Trigger.dev vs. DigitalOcean Managed Agents
DigitalOcean Managed Agents hosts existing harnesses such as Claude Code, Codex or LangGraph apps in Firecracker microVMs with a tool gateway. Trigger.dev runs your own TypeScript code on its machines or yours, which suits agents built into a product rather than off-the-shelf coding harnesses.
Frequently asked questions
What is Trigger.dev?
Trigger.dev is an open-source platform for running background tasks and AI agents written in TypeScript. You write tasks as normal async functions in your codebase, deploy them with the CLI, and Trigger.dev runs them with retries, queues, concurrency limits, human-approval waits, realtime streaming and tracing, either on Trigger.dev Cloud or on your own infrastructure.
Is Trigger.dev an agent framework?
Not in the usual sense. Trigger.dev describes itself as the execution layer underneath agent frameworks: it does not run an agent loop for you and has no tool registry or handoff model. You write the agent loop with the Vercel AI SDK, OpenAI Agents SDK, Claude Agent SDK, Mastra or your own code, and Trigger.dev keeps the run alive, retries it, pauses it for approvals and records what happened. Its chat.agent helper adds durable multi-turn conversations on top of the AI SDK.
Is Trigger.dev open source and can it be self-hosted?
Yes. The repository is Apache 2.0 licensed, and the full stack (dashboard, orchestration and workers) can be self-hosted with Docker Compose or the official Helm chart on Kubernetes. The self-hosted version lacks some cloud features: checkpoints for non-blocking waits, warm starts and autoscaling are cloud-only, and support is through the community Discord.
How much does Trigger.dev cost?
Trigger.dev Cloud has a Free plan ($0, with $5 of usage credit a month and 20 concurrent runs), Hobby at $10/month with $10 of credit included, Pro at $50/month with $50 of credit included, and custom Enterprise pricing. Usage is billed per second of compute, from $0.0000169 per second on the smallest machine to $0.00068 per second on the largest, plus $0.25 per 10,000 runs. Runs in the DEV environment are free, and checkpointed waits are not billed. Self-hosting the open-source version has no license fee.
How long can a Trigger.dev task run?
There is no platform maximum. You set a default maxDuration for the project, override it per task or per run, or disable it. Trigger.dev says it has seen customer runs last more than six months.
Does Trigger.dev work with the Claude Agent SDK or the Vercel AI SDK?
Yes. The docs include a Claude Agent SDK setup guide that runs the SDK inside a Trigger.dev task, and chat.agent is built directly on the Vercel AI SDK's streamText and useChat. There are also examples for the OpenAI Agents SDK in TypeScript and Python and for Mastra agents.
Can Trigger.dev agents be triggered by webhooks or run in Slack?
Yes, as a public beta announced on October 26, 2026. You declare a webhook endpoint in code, register its URL with the provider, and Trigger.dev verifies, deduplicates and records each event before routing it to matching tasks, agent sessions or runs waiting for it. More than 40 providers are supported by name, and the Slack and Linear packages turn a chat.agent into an agent that answers in Slack threads or Linear issues. Receiving webhooks has no separate charge; the runs they start are billed as usual.
How does Trigger.dev compare with Temporal and Inngest?
According to Trigger.dev's own comparison pages, Temporal makes code durable by replaying deterministic workflow code and offers SDKs in many languages, while Trigger.dev checkpoints and restores the real process, so tasks are ordinary TypeScript with no determinism rules but TypeScript is the only SDK. Inngest orchestrates durable steps inside your existing app and supports TypeScript, Python and Go, so how long a step can run depends on where your app is hosted; Trigger.dev runs your code on its own managed compute (or your self-hosted workers) with no platform timeout.
Trigger.dev vs Mastra: what is the difference?
Mastra is a TypeScript agent framework: it defines agents, workflows, memory, tools and evals. Trigger.dev is the runtime that executes TypeScript code durably, with retries, queues, long waits and tracing. They are often combined: Trigger.dev publishes an example of Mastra agents running inside Trigger.dev tasks, and its own comparison recommends writing the agent with a framework such as Mastra or the AI SDK and running it on Trigger.dev.
Integrations & fit
Alternatives to consider
Cloudgeni
Product and platform teams building agent features into their own TypeScript/React product, or running agents for their organization, who want durable sessions, approvals, credential handling, and the choice to self-host under Apache-2.0 or start on a hosted cloud with the same API
Freemium
Omnara
Product and platform teams that want hosted, long-running agents behind an API, in Slack, or on GitHub, with the freedom to pick any model, run tools on their own machines or third-party sandboxes, and self-host under Apache 2.0 or keep agent history in their own Postgres
FreemiumAbout Trigger.dev
Trigger.dev is not an agent and not an agent framework in the usual sense. It does not run an agent loop for you and has no tool registry or handoff model; you write the agent with the Vercel AI SDK, the OpenAI Agents SDK, the Claude Agent SDK, Mastra or plain code, and Trigger.dev is where that code runs. (Its AI Prompts feature versions prompt templates on deploy, but does not define how an agent behaves.) You define tasks as ordinary async TypeScript functions in a trigger folder of your app, develop them locally with the CLI and hot reload, and deploy them with one command to Trigger.dev Cloud or a self-hosted instance. Each run gets a retry policy, a queue with concurrency limits (including per-tenant keys), a configurable machine size, and a trace in the dashboard, and there is no platform-imposed maximum duration. On the cloud, waits are checkpointed: when a task waits on a timer, a child task or a human-approval token, the process is snapshotted and the machine released, so idle time is not billed. For chat-shaped agents, chat.agent runs each conversation as one durable task built on the AI SDK's streamText and useChat, with resume across refreshes, deploys and crashes, sub-agents, stop and steering, and tool approvals. Version 4.8.0 (October 23, 2026) added hosted webhook endpoints declared in code, which verify, deduplicate and record events from 40+ named providers such as Stripe, GitHub, Clerk and Shopify (plus Standard Webhooks, Svix and custom schemes) and route them to tasks, agent sessions or waiting runs, together with packages that turn a chat.agent into a native Slack or Linear agent. Webhooks were announced as a public beta on October 26, 2026, on both the cloud and the open-source project. Pricing on the cloud is a plan fee with included usage credits plus per-second compute and a small per-run fee, which suits bursty agent workloads but needs estimating for heavy ones. The main tradeoffs: it is TypeScript only (Python runs as scripts called from TypeScript tasks), a failed attempt reruns the task from the top rather than replaying steps, and self-hosted instances lack the cloud's checkpointing, warm starts and autoscaling, so waits there hold worker capacity.
Updates from Trigger.dev
Inbound webhooks launched in public beta on Trigger.dev Cloud and in the open-source project. Endpoints declared in code verify signatures, drop duplicates, store each event and route it to every matching agent or task, with support for 40+ named providers, Standard Webhooks and Svix, custom verification, and a delivery log with replay.
Version 4.8.0 introduced hosted webhook endpoints with typed filters and waiters that pause a run until a matching event arrives, plus @trigger.dev/slack and @trigger.dev/linear, which turn a chat.agent into a native Slack or Linear agent with approvals as Approve and Deny buttons.
Are you the founder? Claim this listing →