Trigger.dev vs Inngest

What is Trigger.dev?

Trigger.dev is the open source platform for building durable AI agents and workflows in TypeScript. Your code runs on managed compute as normal TypeScript, with no determinism constraints and no platform-imposed execution timeout. It includes built-in retries, queues, and scheduling, plus OpenTelemetry observability with custom dashboards and an SQL-style query language. Tasks can stream data to your frontend and backend in real-time, receive typed input while running, and pause for hours, days, or weeks for human approval or external events. Thousands of engineering teams run production workloads on it, processing hundreds of millions of runs.

What is Inngest?

Inngest is a durable execution platform that orchestrates functions in your own app via HTTP callbacks or persistent outbound connections (connect()). It's often used with serverless platforms like Vercel, but it also works on regular servers and containers. It supports TypeScript, Python, and Go with adapters for 20+ frameworks including Next.js, Express, Remix, and Hono. Inngest's step-based memoization ensures that completed work is never repeated on retry. The event-driven model with step.waitForEvent(), built-in concurrency controls, rate limiting, and debouncing make it well-suited for event-driven architectures. AgentKit adds AI agent orchestration with MCP tool support and React hooks for streaming agent output.

How does the execution model differ?

Inngest orchestrates your code on your own infrastructure, subject to your host's limits. Trigger.dev runs your code on managed compute with no platform-imposed timeout.

Inngest's callback model means your functions stay on your infrastructure, and Inngest handles orchestration, retries, and scheduling via HTTP. This works well when each step completes within your platform's timeout. For longer tasks, Inngest's connect() mode provides a WebSocket alternative for long-running servers. Durable Endpoints (in beta) add step-based checkpointing to regular HTTP handlers in Next.js and Bun. Trigger.dev runs your code on its own compute instead, so a task that takes 30 seconds or 30 minutes runs the same way, without depending on your host's request timeout (you set a maxDuration per task, or turn it off).

How does developer experience compare?

Inngest provides a rich step-function API with event triggers, sleep, and fan-out primitives. Trigger.dev has a simpler model: tasks that run as plain TypeScript with built-in queues and scheduling.

Inngest's DX shines in event-driven architectures. Define a function, specify an event trigger, and Inngest calls your code when the event fires. The step primitives (step.run(), step.sleep(), step.waitForEvent()) are well-designed and intuitive for breaking work into durable units. Inngest supports Standard Schema validation for type-safe event payloads. Trigger.dev's model is different: define a task, trigger it from your code, and it runs on managed compute as plain TypeScript, close to a normal async function. Both platforms ship MCP servers and agent skills for AI editors. Inngest's plugins bundle skills, MCP config, and an eval harness for Claude Code and Codex. Trigger.dev's MCP server connects to the cloud platform for deploying, triggering tasks, and monitoring runs. Its skills (npx trigger.dev@latest skills) are version-pinned to your installed SDK, and a one-line setup prompt takes a coding agent from login to a first local run.

How does durability work in each platform?

Inngest memoizes each completed step and replays to resume. Trigger.dev continues from a snapshot after waits, and on failure retries, reusing subtasks with idempotency keys.

Inngest's memoization model: wrap each unit of work in step.run(), and if the function retries, completed steps return their cached result instead of re-executing. Inngest's TypeScript SDK enables checkpointing by default, executing sequential steps eagerly on your server without a round-trip per step, which lowers inter-step latency. Standard replay kicks in on failure or parallel steps. When a run resumes after a wait or a failure, it walks through previously completed steps, so a function with many steps carries more replay overhead at those points. Trigger.dev uses checkpoint-resume instead: the platform snapshots your entire process state at wait points and restores it later. Your code runs forward from the checkpoint rather than replaying from the start, so step count doesn't affect resume cost. When a run fails, Trigger.dev retries it from the start, and subtasks triggered with idempotency keys return their saved results instead of running again.

How do AI agent capabilities compare?

Inngest has AgentKit, a dedicated framework for multi-agent orchestration with MCP tools and React hooks. Trigger.dev runs any TypeScript AI framework with no platform-imposed timeout, real-time streaming, and human-in-the-loop primitives.

Inngest's main approach is durable agents: you write the agent loop with any model SDK, and each LLM or tool call is a step. Inngest's AgentKit adds a structured framework on top: define tools, configure models (OpenAI, Anthropic, Gemini, Grok, and OpenAI-compatible models), and use routing to coordinate multiple agents. AgentKit's React hooks stream agent output to the frontend. AgentKit agents run within Inngest's step-based execution model, so each LLM call is a memoized step with automatic retry. step.ai.infer() proxies LLM requests through Inngest's gateway, reducing serverless compute costs while waiting for responses. Trigger.dev works with any TypeScript AI framework directly: AI SDK, Mastra, OpenAI Agents SDK, or others, with no wrappers. ai.toolExecute() exposes tasks as tools for the Vercel AI SDK. Realtime pushes run updates and streams data (AI tokens, progress) to your frontend or backend, input streams send typed data into running tasks (cancel signals, approvals, user messages), and long-running agent conversations aren't bound by a platform timeout. For chat specifically, chat.agent gives every conversation its own durable machine that you point the AI SDK's useChat at, with run tracing and an AI metrics dashboard (tokens, cost, and latency per model) built in. Because tasks run on managed compute you shape with build extensions, an agent can drive a real browser (Playwright), run Python, or use FFmpeg without bundling any of it into a serverless function.

What infrastructure do you need to manage?

Inngest adds durability to your existing infrastructure. Trigger.dev provides the compute for background work on Trigger.dev Cloud, or you self-host it.

If you already have an app deployed, Inngest's model is convenient: add the SDK, expose an endpoint, and Inngest orchestrates your existing infrastructure. You keep your current hosting, CI/CD, and deployment pipeline. The tradeoff is that background jobs then run under your web app's limits (on serverless, that means the same timeouts, cold starts, and runtime as your web requests). Trigger.dev provides its own compute, so background tasks are decoupled from your web app entirely. Run FFmpeg, Playwright, or long-running AI agents without worrying about serverless limits. Build extensions add system dependencies with a config line. The Vercel integration syncs environment variables and adds version skew protection, and preview branches create isolated environments per PR with their own runs, schedules, and branch-level env vars.

How does pricing compare at scale?

Inngest bills per execution, counting the run plus each step (a 5-step run is 6 executions). Trigger.dev bills per compute-second plus a per-run fee. The models favor different workload shapes.

Inngest's per-execution pricing scales with function complexity. Each run counts as the run itself plus every step, so a 5-step run is 6 executions and 100,000 runs of that function is 600,000 executions against your plan. This model works well for simple functions with few steps. Trigger.dev charges for compute time: a task that runs for 10 seconds costs the same whether it has 1 logical step or 50 internal operations. Which is cheaper depends on the workload. On Inngest, add your own hosting bill to the execution count. On Trigger.dev, cost depends on machine size and run time (including retries), plus a per-run fee for every task and subtask, so a workflow that splits work into subtasks, like the order example below, pays several run fees. Many-step work often favors Trigger.dev, while short functions with few steps can cost less on Inngest.

How does observability compare?

Inngest provides traces, Insights SQL queries with an AI assistant, and an AI cost dashboard. Trigger.dev adds user-built dashboards and Ask Trigger.

Inngest provides built-in function traces with step-level detail, an AI Overview dashboard for LLM cost and latency, and Insights, a SQL editor over events, runs, and spans with an AI assistant that writes queries. Trigger.dev ships OpenTelemetry tracing with span-level detail, plus TRQL , an SQL-style query language backed by ClickHouse. Build custom dashboards with charts, tables, and big number widgets, or describe what you want in plain English and the AI assistant generates the query. TRQL queries are also available via SDK and REST API for programmatic access.

How do self-hosting and licensing compare?

Inngest is source-available under the SSPL (not OSI-approved), converting to Apache 2.0 three years after each release. Trigger.dev is Apache 2.0, with every release open source immediately.

Inngest's self-hosting story starts simple: inngest start runs everything in one process with SQLite. Point it at Postgres and Redis for production, or use the Helm chart for multi-node Kubernetes deployments with KEDA autoscaling. The SSPL license allows internal use but prevents competing managed services, and enterprise SSO is a Cloud feature. Trigger.dev self-hosts on Docker Compose or Kubernetes under Apache 2.0 with the same core codebase as Cloud (checkpoints, warm starts, and auto-scaling are Cloud-only ).