Trigger.dev launched as a developer-first Zapier alternative and pivoted to a Temporal alternative for TypeScript within months. The shift reveals a fundamental architectural split in workflow orchestration: visual automation platforms optimize for non-technical users connecting SaaS apps, while code-first engines optimize for developers building durable background tasks that survive failures, retries, and long execution windows.
The difference matters when you build agents that need to trigger external tools, wait for webhooks, or retry API calls with exponential backoff. Visual platforms abstract away the plumbing: retry configuration, state checkpointing, and failure handling. Code-first engines expose it as primitives you control.
Event Handling and Task Dispatch
Trigger.dev runs tasks as TypeScript functions inside your application codebase. You define a task with an ID, a run function, and optional configuration for retries, timeouts, and concurrency limits. The platform handles event ingestion through webhooks, scheduled triggers, or direct invocations from your app.
export const processDocument = task({
id: "process-document",
retry: {
maxAttempts: 3,
factor: 2,
minTimeoutInMs: 1000,
maxTimeoutInMs: 10000,
},
run: async (payload: { documentId: string }) => {
const doc = await fetchDocument(payload.documentId);
const analysis = await analyzeWithLLM(doc.content);
await storeResults(payload.documentId, analysis);
return { status: "complete", tokens: analysis.usage };
},
});Visual platforms like Zapier use a webhook-to-action model. An external event hits a Zapier endpoint, triggers a pre-built integration, and passes data through a visual pipeline. You configure steps in a web UI. The platform manages execution opaquely.
Trigger.dev exposes the task queue as a first-class concept. Tasks enter a queue, workers pull from the queue, and the platform tracks execution state in a database. You can query task status, cancel in-flight tasks, or replay failed tasks from the dashboard or API.
Retry Logic and Failure Handling
Retry configuration in Trigger.dev lives in code. You specify max attempts, backoff strategy, and timeout boundaries per task. The platform persists task state between retries, so you can checkpoint progress and avoid redundant work.
export const fetchExternalData = task({
id: "fetch-external-data",
retry: {
maxAttempts: 5,
factor: 2,
randomize: true,
},
run: async (payload, { ctx }) => {
if (ctx.attempt.number > 1) {
logger.info(`Retry attempt ${ctx.attempt.number}`);
}
const response = await fetch(payload.url, { timeout: 30000 });
if (!response.ok) throw new Error(`HTTP ${response.status}`);
return response.json();
},
});Visual platforms offer retry toggles in the UI. Zapier retries failed steps automatically, but you cannot customize backoff intervals or add conditional retry logic based on error type. If a step fails after max retries, the entire workflow stops. You receive an email notification.
Code-first engines let you catch exceptions, inspect error types, and decide whether to retry, skip, or escalate. You can implement circuit breakers, fallback strategies, or manual approval gates. The trade-off is complexity. You write more code. You own more failure modes.
State Persistence and Long-Running Tasks
Trigger.dev persists task state in PostgreSQL. Each task execution gets a unique run ID. The platform stores input payloads, output results, logs, and execution metadata. Tasks can run for hours or days without timing out. The platform checkpoints progress at each await boundary, so if a worker crashes, the task resumes from the last checkpoint.
This matters for agents that need to wait for external events. An agent might trigger a document processing pipeline, wait for a human approval webhook, then continue with downstream steps. Visual platforms impose strict timeout limits. Code-first engines treat long waits as a normal execution pattern.
export const approvalWorkflow = task({
id: "approval-workflow",
run: async (payload: { requestId: string }) => {
const request = await createApprovalRequest(payload.requestId);
// Send approval request and get webhook URL
const webhookUrl = await registerApprovalWebhook(payload.requestId);
await sendApprovalEmail(request.approverEmail, webhookUrl);
// Wait for webhook event using Trigger.dev's waitForEvent
const approval = await waitForEvent("approval.received", {
filter: { requestId: payload.requestId },
timeoutInSeconds: 7 * 24 * 60 * 60, // 7 days
});
if (approval.status === "approved") {
await executeApprovedAction(payload.requestId);
}
return { approved: approval.status === "approved" };
},
});Visual platforms handle state implicitly. Zapier stores intermediate data between steps, but you cannot query or modify that state programmatically. If you need to inspect what happened during a failed run, you click through the UI to view execution logs.
Deployment Models and Integration Boundaries
Trigger.dev tasks live in your application repository. You deploy them alongside your main application code. The platform provides a CLI that bundles tasks, uploads them to the Trigger.dev cloud, and manages versioning. Tasks run in isolated workers managed by Trigger.dev, but they share your application’s dependencies, environment variables, and secrets.
This deployment model creates tight coupling between your app and your background tasks. You can call internal functions, access private APIs, and share type definitions. The trade-off is operational complexity. You manage two deployment pipelines: one for your app, one for your tasks.
Visual platforms decouple workflows from your application. Zapier workflows run in Zapier’s infrastructure. You connect to your app through public APIs or pre-built integrations. This separation simplifies deployment but limits what you can do. You cannot call internal functions or access private data without exposing an API endpoint.
Observability and Debugging
Trigger.dev provides a web dashboard that shows task runs, execution timelines, logs, and error traces. You can filter by task ID, status, or date range. Each run displays input payloads, output results, and step-by-step execution logs. The platform captures console logs, errors, and performance metrics automatically.
You can also query task state programmatically:
import { runs } from "@trigger.dev/sdk";
const recentRuns = await runs.list("process-document", {
status: ["FAILED"],
from: new Date(Date.now() - 24 * 60 * 60 * 1000),
});
for (const run of recentRuns.data) {
console.log(`Failed run ${run.id}: ${run.error}`);
}Visual platforms provide similar dashboards but with less programmatic access. Zapier shows execution history in the UI. You can view logs and replay failed runs. You cannot query execution data via API or build custom monitoring dashboards.
Concurrency and Queue Management
Trigger.dev lets you configure concurrency limits per task. You can set a global limit (max 10 concurrent runs) or per-key limits (max 1 run per user ID). The platform enforces these limits at the queue level. If a task exceeds its concurrency limit, new runs wait in the queue.
export const sendEmail = task({
id: "send-email",
queue: {
concurrencyLimit: 5,
},
run: async (payload: { to: string; subject: string; body: string }) => {
await emailService.send(payload);
},
});Visual platforms manage concurrency implicitly. Zapier runs workflows in parallel by default. You cannot control how many instances run simultaneously. If you need rate limiting, you implement it inside your API endpoints.
Architecture Comparison
| Dimension | Trigger.dev (Code-First) | Zapier (Visual) |
|---|---|---|
| Task Definition | TypeScript functions in app repo | Visual steps in web UI |
| Retry Logic | Configurable per task (attempts, backoff, jitter) | Fixed retry policy, UI toggle |
| State Persistence | PostgreSQL, queryable via API | Internal, UI-only access |
| Execution Timeout | Hours to days, checkpoint-based | Minutes per workflow (varies by plan) |
| Deployment | CLI bundles tasks to cloud workers | Workflows live in Zapier infrastructure |
| Observability | Dashboard + programmatic API | Dashboard only |
| Concurrency Control | Per-task or per-key limits | Implicit, no user control |
| Integration Boundary | Internal functions, shared types | Public APIs, pre-built connectors |
When Code-First Engines Fit
Code-first workflow engines make sense when you need long-running tasks that wait for external events or human input. If your agent workflow must pause for hours or days while waiting for a webhook callback, visual platforms will time out. Code-first engines treat this as a normal execution pattern, checkpointing state and resuming when the event arrives.
They also fit when you need custom retry logic based on error type, rate limits, or business rules. Visual platforms offer fixed retry policies. Code-first engines let you inspect exceptions, implement circuit breakers, and decide whether to retry, skip, or escalate based on the specific failure mode.
Tight integration with internal services, databases, or private APIs is another strong signal. If your tasks need to call internal functions or access private data, code-first engines let you share type definitions and avoid exposing public API endpoints. Visual platforms require you to build and maintain API wrappers for every internal service.
Programmatic observability matters when you need custom dashboards, alerts, or compliance logs. Code-first engines expose task state via API, so you can build monitoring systems that query execution data, track SLA violations, or generate audit trails. Visual platforms lock observability behind a web UI.
Concurrency control becomes critical when you need to avoid overwhelming downstream services. Code-first engines let you set per-task or per-key limits, ensuring that no more than N instances run simultaneously. Visual platforms manage concurrency implicitly, which works until it doesn’t.
For agent systems specifically, code-first engines provide the control needed to orchestrate multi-step tool calls, manage state across LLM interactions, and handle the unpredictable execution patterns that emerge when AI decides what to do next.
Code-first engines do not fit when non-technical users need to build workflows without writing code. They also struggle when you want to connect SaaS apps without maintaining API clients. Visual platforms offer pre-built integrations for hundreds of third-party services. Code-first engines require you to write and maintain those integrations yourself. Deployment complexity can also outweigh the benefits of code-level control, especially for small teams or simple workflows.
Technical Verdict
Trigger.dev exposes workflow orchestration primitives that visual platforms hide. You get explicit retry configuration, state persistence, and deployment control. The trade-off is operational overhead. You write more code, manage more infrastructure, and own more failure modes.
Use Trigger.dev when you build agents or background task systems that need durable execution, custom retry logic, or tight integration with internal services. Use visual platforms when you connect SaaS apps, need pre-built integrations, or want to hand workflow creation to non-technical users.
The v1-to-v2 pivot from Zapier alternative to Temporal alternative signals where the real demand lives. As agents become more complex and require longer execution windows, tighter integration with internal systems, and more sophisticated failure handling, the demand for code-first orchestration will continue to grow. Visual platforms remain the right choice for simple SaaS integrations and non-technical workflow builders, but production agent systems increasingly need the control that only code-level primitives can provide.
Source Links:
- Trigger.dev (primary platform)
- GitHub Repository (open source)
- Hacker News Discussion (745 points, 190 comments)