mech.app
Automation

Trigger.dev V2: TypeScript-Native Durable Execution Without Temporal's Stack

How Trigger.dev pivoted from event triggers to durable execution primitives, exposing state persistence, retry plumbing, and deployment trade-offs.

Source: trigger.dev
Trigger.dev V2: TypeScript-Native Durable Execution Without Temporal's Stack

Trigger.dev launched in February 2023 as a “developer-first Zapier alternative” and earned 745 points on Hacker News. Eight months later, the team shipped V2 with a hard pivot: durable execution for TypeScript developers who need Temporal’s guarantees without adopting Go or Java.

The shift exposes a real gap. Temporal solves workflow orchestration for distributed systems, but its stack (Go server, Java/Go SDKs, gRPC boundaries) creates friction for JavaScript teams building agent workflows, long-running API integrations, or multi-step automation. Trigger.dev V2 targets that friction by offering state persistence, retries, and versioning as TypeScript-native primitives.

What Changed Between V1 and V2

V1 focused on event-driven triggers: webhooks, schedules, and integrations that fired functions. The model worked for simple automation but broke down when developers needed:

  • Multi-hour tasks that survive process restarts
  • Partial failure recovery without re-running completed steps
  • Visibility into task state across retries and timeouts
  • Versioning for workflows that change while tasks are in flight

V2 reframes the product around durable execution. Instead of event triggers, you write tasks that Trigger.dev manages as long-running, retriable units. The platform handles state persistence, replay, and observability.

Core Primitives

Trigger.dev exposes four primitives that map to common workflow needs:

Tasks: Functions wrapped in task() that persist state across retries. Each task gets a unique run ID, execution context, and automatic retry logic.

Queues: Control concurrency and ordering. You can limit parallel execution, enforce FIFO, or partition work by key.

Scheduled Tasks: Cron-style triggers without timeout limits. A task can run for hours and still respect the schedule for the next invocation.

Realtime Connections: WebSocket-style hooks that let frontend apps subscribe to task progress, useful for agent UIs that need live updates.

The primitives are simpler than Temporal’s workflow/activity split. Trigger.dev treats everything as a task. If you need sub-steps, you call other tasks or use standard TypeScript functions. There’s no separate activity concept, which reduces abstraction layers but also limits some of Temporal’s advanced replay guarantees.

State Persistence and Replay

Trigger.dev persists task state to Postgres (self-hosted) or its managed cloud. When a task fails or times out, the platform retries from the last checkpoint. Checkpoints happen automatically at task boundaries, not within arbitrary code blocks.

This differs from Temporal’s event sourcing model. Temporal replays the entire workflow history to reconstruct state. Trigger.dev checkpoints state snapshots, which means faster retries but less granular replay control. If your task mutates external state (writes to a database, sends an email), you need idempotency keys. Temporal’s replay model can avoid some of those issues by re-executing deterministic code without side effects.

Retry behavior:

  • Exponential backoff with configurable max attempts
  • Retry filters based on error type
  • Manual retry triggers from the dashboard
  • No automatic compensation logic (you write rollback code yourself)

Deployment Shape

Trigger.dev runs in two modes:

Managed Cloud: You write tasks, deploy via CLI, and Trigger.dev handles execution infrastructure. Tasks run in isolated containers with configurable memory and CPU. Logs, traces, and metrics flow to the dashboard.

Self-Hosted: You run the Trigger.dev server (Node.js app) and worker processes. State lives in your Postgres instance. You manage scaling, observability, and secrets.

The managed cloud model works for most agent workflows. You get elastic scaling, automatic retries, and built-in observability without operating infrastructure. The trade-off is vendor lock-in and less control over execution boundaries.

Self-hosted mode gives you full control but requires you to handle:

  • Worker scaling (horizontal or vertical)
  • Database backups and migrations
  • Secret rotation and access control
  • Monitoring and alerting

Comparison to Temporal

DimensionTrigger.dev V2Temporal
Language SupportTypeScript onlyGo, Java, Python, PHP, .NET
State ModelSnapshot checkpointsEvent sourcing with replay
DeploymentManaged cloud or self-hosted Node.jsSelf-hosted Go server + workers
Learning CurveLow (standard async TypeScript)High (workflow/activity split, determinism rules)
Replay GuaranteesTask-level retriesFull workflow replay with side-effect isolation
ObservabilityBuilt-in dashboard, logs, tracesTemporal UI + external APM integration
VersioningTask-level versioning with migration hooksWorkflow versioning with backward compatibility

Trigger.dev wins on simplicity and TypeScript ergonomics. Temporal wins on replay precision, multi-language support, and battle-tested distributed systems guarantees.

Code Example: Multi-Step Agent Workflow

import { task } from "@trigger.dev/sdk/v3";
import { anthropic } from "@ai-sdk/anthropic";
import { generateText } from "ai";

export const researchAgent = task({
  id: "research-agent",
  retry: {
    maxAttempts: 3,
    factor: 2,
    minTimeout: 1000,
  },
  run: async ({ topic }: { topic: string }) => {
    const messages: CoreMessage[] = [
      { role: "user", content: `Research: ${topic}` },
    ];

    for (let i = 0; i < 10; i++) {
      const { text, toolCalls, steps } = await generateText({
        model: anthropic("claude-opus-4-20250514"),
        system: "You are a research assistant with web access.",
        messages,
        tools: { search, browse, analyze },
        maxSteps: 5,
      });

      if (!toolCalls.length) {
        return { summary: text, stepsUsed: steps.length };
      }

      for (const call of toolCalls) {
        const result = await executeTool(call);
        messages.push({ role: "tool", content: JSON.stringify(result) });
      }
    }

    throw new Error("Agent exceeded max iterations");
  },
});

This task runs for minutes or hours, survives restarts, and retries on failure. The generateText call is not checkpointed internally, so if it fails mid-stream, the entire iteration retries. You can split tool execution into separate tasks for finer-grained retries.

Observability and Debugging

Trigger.dev’s dashboard shows:

  • Live task execution with step-by-step logs
  • Retry history and failure reasons
  • Execution timelines with duration breakdowns
  • Queue depth and concurrency metrics

You can manually retry failed tasks, inspect state snapshots, and trace tool calls. The UI is cleaner than Temporal’s but lacks some advanced features like workflow search by custom attributes or cross-workflow dependency graphs.

For production debugging, you need to instrument your tasks with structured logging. Trigger.dev captures stdout/stderr, but complex agent workflows benefit from explicit trace IDs and correlation keys.

Failure Modes

Checkpoint Gaps: If your task mutates state between checkpoints, a retry can cause duplicate writes. Use idempotency keys or database transactions.

Long-Running Tool Calls: A single tool call that runs for 30 minutes blocks the entire task. If it fails, the task retries from the beginning. Split expensive operations into separate tasks.

Version Skew: Deploying a new task version while old runs are in flight can cause schema mismatches. Trigger.dev supports version pinning, but you need to plan migrations.

Queue Saturation: High concurrency limits can starve other tasks. Monitor queue depth and adjust limits based on resource availability.

Secrets Rotation: Trigger.dev injects secrets at runtime. If you rotate a secret while tasks are running, in-flight tasks fail. Use versioned secrets or graceful rotation windows.

When to Use Trigger.dev

Good fit:

  • TypeScript teams building agent workflows or long-running automation
  • Projects that need durable execution without operating Temporal infrastructure
  • Workflows with clear task boundaries and idempotent operations
  • Teams that value fast iteration over maximum replay precision

Poor fit:

  • Multi-language environments (Trigger.dev is TypeScript only)
  • Workflows that require sub-second latency or real-time coordination
  • Systems that need Temporal’s event sourcing guarantees for audit or compliance
  • Teams with existing Temporal expertise and infrastructure

Technical Verdict

Trigger.dev V2 solves the “I need Temporal but I write TypeScript” problem. It trades Temporal’s replay precision for simpler deployment and faster onboarding. If your agent workflows fit into task-level retries and you can handle idempotency at the application layer, Trigger.dev removes significant infrastructure complexity.

The managed cloud model is the strongest value proposition. You get durable execution, observability, and elastic scaling without running a distributed system. Self-hosted mode is viable but requires you to operate the same infrastructure concerns that Temporal demands.

Avoid Trigger.dev if you need multi-language support, sub-task replay guarantees, or deep integration with existing Temporal workflows. The TypeScript-only constraint is a feature for some teams and a blocker for others.

For agent builders who live in the TypeScript ecosystem and need workflows that survive failures without adopting a new stack, Trigger.dev V2 is the most pragmatic option available today.