Trigger.dev V2: TypeScript Workflow Engine Without Go or gRPC

Trigger.dev V2 positions itself as a TypeScript-native workflow engine that competes with Temporal without requiring Go binaries, gRPC protocol knowledge, or separate worker infrastructure. The pivot from “Zapier alternative” to “Temporal alternative” reflects user demand for durable execution primitives that feel native to the JavaScript ecosystem.

The core question: can a hosted TypeScript runtime deliver the same guarantees as Temporal’s battle-tested Go engine while reducing operational overhead?

Architecture: Hosted Runtime vs. Self-Hosted Workers

Trigger.dev runs your task code in a managed execution environment. You define tasks as TypeScript functions, deploy them to Trigger.dev’s infrastructure, and the platform handles retries, state persistence, and concurrency limits.

Key architectural differences from Temporal:

Component	Temporal	Trigger.dev
Workflow engine	Go binary (self-hosted or Temporal Cloud)	Hosted TypeScript runtime
Worker deployment	You run workers in your infra	Platform runs your code
State persistence	Postgres/Cassandra event sourcing	Managed database (abstracted)
Protocol	gRPC between workers and server	HTTP/WebSocket to platform API
Local dev	Temporal CLI + local server	Trigger.dev CLI + dev tunnels
Type safety	SDK codegen from workflow definitions	Native TypeScript inference

Temporal requires you to operate worker processes that poll for tasks. Trigger.dev eliminates that: you push code to the platform and it handles execution. This trades operational control for deployment simplicity.

Durable Execution Model

Trigger.dev implements durable execution by checkpointing task state at await boundaries. When your task calls an external API or waits for a delay, the platform persists the execution context. If the task crashes or times out, it resumes from the last checkpoint.

// from @ai-sdk/anthropic
import { anthropic } from '@ai-sdk/anthropic';
import { generateText } from 'ai';

export const researchAgent = task({
  id: "research-agent",
  run: async ({ topic }: { topic: string }) => {
    // Each await is a checkpoint boundary
    const searchResults = await search(topic);
    
    // If this fails, retry from here
    const analysis = await generateText({
      model: anthropic("claude-opus-4-20250514"),
      system: "You are a research assistant.",
      messages: [{ role: "user", content: `Analyze: ${topic}` }],
      tools: { search, browse, analyze },
      maxSteps: 5,
    });
    
    // State persisted across retries
    return { summary: analysis.text, sources: searchResults };
  },
});

How it differs from Temporal workflows:

• Temporal replays your entire workflow function from the start on each resume, using deterministic execution to rebuild state. You cannot use random numbers or Date.now() directly.
• Trigger.dev checkpoints state at await points, so your function does not replay. You can use non-deterministic code between checkpoints.

This makes Trigger.dev easier to reason about for developers unfamiliar with event sourcing, but it limits some of Temporal’s advanced patterns (like querying in-flight workflow state or building complex sagas).

Retry and Failure Handling

Trigger.dev provides declarative retry configuration at the task level:

export const flakyScraper = task({
  id: "scrape-with-retries",
  retry: {
    maxAttempts: 5,
    factor: 2,
    minTimeout: 1000,
    maxTimeout: 60000,
  },
  run: async ({ url }) => {
    // Automatic exponential backoff on throw
    const page = await browser.newPage();
    return await page.goto(url);
  },
});

Temporal handles retries through activity options and workflow retry policies. You configure retries per activity (the unit of work that can fail), and the workflow engine manages the schedule. Trigger.dev’s approach is simpler but less granular: you retry the entire task, not individual steps within it.

Failure mode comparison:

• Temporal: Activity failures are recorded in the event log. You can inspect why an activity failed, see the exact retry schedule, and manually retry or cancel from the UI.
• Trigger.dev: Task failures surface in the dashboard with logs. You can manually retry from the last checkpoint, but you lose fine-grained visibility into which specific await boundary failed.

Concurrency and Queue Management

Trigger.dev exposes concurrency controls as first-class configuration:

export const batchProcessor = task({
  id: "process-batch",
  queue: {
    name: "batch-jobs",
    concurrencyLimit: 10,
  },
  run: async ({ items }) => {
    // Only 10 instances of this task run concurrently
    return await Promise.all(items.map(processItem));
  },
});

Temporal achieves this through worker tuning (max concurrent activities, max concurrent workflows) and task queue configuration. You control concurrency at the worker level, not in code. Trigger.dev’s approach is more declarative but less flexible: you cannot dynamically adjust concurrency based on runtime conditions without redeploying.

Observability Surface

Trigger.dev provides a web dashboard with:

• Real-time task execution traces
• Logs streamed from your task code
• Retry history and failure reasons
• Latency histograms per task

Temporal offers similar observability through its Web UI, but it also exposes:

• Full event history for every workflow (every decision, timer, activity result)
• Ability to query workflow state while it is running
• Metrics exportable to Prometheus/Grafana

Trigger.dev’s observability is sufficient for debugging individual task failures but lacks the deep introspection Temporal provides for complex multi-step workflows.

Deployment Shape

Trigger.dev:

1. Write tasks in your codebase
2. Run trigger.dev deploy
3. Platform builds and hosts your code
4. Invoke tasks via SDK or HTTP API

Temporal:

1. Write workflows and activities
2. Deploy Temporal server (or use Temporal Cloud)
3. Run worker processes in your infrastructure
4. Workers poll Temporal server for tasks

Trigger.dev’s deployment is simpler but locks you into their hosting model. Temporal requires more operational work but gives you full control over where code runs.

When to Use Trigger.dev

Good fit:

• You are building in TypeScript and want durable execution without learning Go or gRPC.
• You prefer managed infrastructure over operating worker fleets.
• Your workflows are linear (fetch data, process, store) without complex branching or long-running sagas.
• You need quick iteration cycles and do not want to manage Temporal server upgrades.

Poor fit:

• You need to run workflows in your own VPC for compliance reasons.
• You require deep introspection into workflow state (querying running workflows, building dashboards from event history).
• You are orchestrating complex multi-service transactions that benefit from Temporal’s saga patterns.
• You already operate Temporal and have workflows in production.

Technical Verdict

Use Trigger.dev if you are shipping TypeScript agents or background jobs in under two weeks and accept vendor lock-in for the sake of zero infrastructure overhead. Use Temporal if you need to query running workflows, run workers in your own VPC, or build complex multi-step sagas with fine-grained retry control per activity.

Trigger.dev trades Temporal’s operational flexibility and deep observability for a simpler developer experience. The hosted model removes the need to manage workers, and the TypeScript-native API reduces cognitive load. You lose the ability to introspect workflow event history or run code in your own infrastructure, but you gain deployment speed and a lower learning curve.

For teams building agentic workflows that need retries and long-running tasks but do not require Temporal’s full feature set, Trigger.dev is a pragmatic alternative. For teams scaling complex orchestration across multiple services or needing compliance-driven deployment control, Temporal’s operational complexity pays off.

The decision hinges on whether you value time-to-first-deployment over operational control. If you can accept a managed runtime and do not need workflow introspection, Trigger.dev delivers durable execution without the infrastructure tax.

Source Links

• Trigger.dev
• Hacker News Discussion (V2 Launch)
• Original Show HN (V1)