Trigger Dev

Trigger Dev: What It Replaces

Trigger.dev combines a task runner, queues, scheduling, deployment, and a run dashboard. You write an asynchronous function, send it a payload, and let a separate worker execute it while your app returns a response to the user. It can replace the infrastructure you would otherwise assemble around background jobs; it does not replace your application database, business rules, or the model that makes an AI agent's decisions.

Verified against live documentation, pricing, changelog, and the GitHub repository on 11 November 2026. This is a documentation-based evaluation, with no signed-in test or performance benchmark. The recommendation turns on runtime ownership, recovery boundaries, operator usability, and production limits.

The v4 launch changelog, dated 18 August 2025, added warm starts, waitpoints for approvals and callbacks, priority queuing, dashboard changes, and lifecycle hooks. The latest listed release at verification, v4.8.4 on 10 November 2026, adds workload identity and trusted deployment publishing. Those identity features let supported services and deployment systems authenticate with short-lived identity tokens instead of stored long-lived credentials.

For a founder, the practical change is that “generate the report after upload” can become a managed background task instead of a web endpoint held open until the report finishes. Your app still needs to record which report belongs to which customer and decide what happens if generation fails.

Who Should Pick It, and Who Should Skip It?

Trigger.dev suits an engineering-owned product whose background logic belongs beside the rest of its TypeScript code. The closer your requirement is to “run this function reliably, with its dependencies,” the stronger the fit.

The shortlist below compares where you express the workflow and what you must own. These are architecture choices, not a ranking of which vendor has the longest feature list.

n8n: When the Workflow Owner Is an Operator

n8n makes more sense for a sales-operations owner connecting lead intake, enrichment, and follow-up. Its visual workflow approach keeps the process inspectable without requiring every change to become an application-code change. It supports AI and business automation, so “we need an agent” alone is not a reason to rule it out.

The tradeoff is ownership. If the hard part is custom application logic with libraries and deployment dependencies, a TypeScript task may be easier to maintain than a growing visual flow. If the hard part is letting an operator change business steps, Trigger.dev hands that operator an engineering dependency. See the broader n8n alternatives comparison for that buying decision.

Inngest vs Trigger Dev

Inngest is the close comparison for developers who want durable functions. Its current documentation describes saving step results and retrying from the failed step, with TypeScript, Python, and Go SDKs. That makes it worth shortlisting when the application naturally decomposes into named steps or a Python team wants to write workflows in Python.

Trigger.dev's attraction is bringing the task runtime and its dependencies with the orchestration. Inngest's explicit step model makes the recovery boundary visible in your code. Neither choice removes the need to make an external write safe to repeat. Pick by how you want to deploy the workload and reason about failure, not by assuming only one supports waits or agents.

Temporal: When This Is a Platform Decision

Temporal deserves a place on the shortlist when a business process crosses services and its lifecycle matters more than getting a background function deployed quickly. Its documentation covers multiple SDK languages and deployment of your application alongside a self-hosted or managed Temporal service.

The cost here is an architectural commitment: your engineers own the workflow application and its operational design. For a small TypeScript product trying to move a report generator off the request path, that can be more system than the problem needs. For a platform team standardizing long-lived business processes, it can be the point.

Write, Deploy, and Retry a Background Task

Trigger.dev moves the slow part of a request into a task that you can observe independently. Consider a document-import feature: the app accepts the upload, records an import, triggers processing, and returns control to the customer. Extraction and classification can continue in the background.

The following is the task documentation's hello-world example, with comments removed and an export added so the task can be discovered and imported:

import { task } from "@trigger.dev/sdk";

export const helloWorld = task({
  id: "hello-world",
  run: async (payload: { message: string }) => {
    console.log(payload.message);
  },
});

The important boundary is the payload: pass the information needed to locate and process the import, then keep the customer-facing request independent of the task's completion.

The retry documentation distinguishes task retries from retrying a smaller block with retry.onThrow or an HTTP request with retry.fetch. A task retry can repeat the whole task. If import processing succeeds but a later notification throws, blindly rerunning everything can repeat earlier writes.

The design rule: retry transient failures close to the failing operation, and make writes idempotent, meaning repeating the same operation does not create another business effect. A task platform provides recovery machinery; your database constraints and external API choices determine whether a retry duplicates an invoice, email, or record.

Trigger Dev Python

Trigger.dev can execute Python scripts inside TypeScript tasks through its Python build extension. That is useful when your web product is TypeScript but a document parser is Python. It is a bridge between runtimes, not the same developer experience as a native Python workflow SDK.

One deployment detail matters: the extension's requirementsFile installation is production-only; development dependencies must be installed locally. A parser that works on a laptop is not proof that its deployed dependencies are correct.

Pause an Agent for Approval or a Callback

Trigger.dev's waitpoints let a workflow stop until a person or external service supplies the missing result. For a refund agent, that means separating “recommend a refund” from “issue the refund.” The task can prepare the recommendation, wait for approval, and continue only after the approval result arrives.

The maker's waitpoint walkthrough uses wait.createToken, wait.forToken, and wait.completeToken for that handoff. It also shows callback URLs for external services. The application still decides who may approve and what an approval authorizes.

There are separate controls for time and cost. The current wait documentation says timed waits longer than 5 seconds do not count toward compute usage. But a timed wait releases its concurrency slot only after the machine is snapshotted and shut down, 60 seconds into the wait. A shorter wait can therefore be compute-free while still occupying a slot.

That distinction matters if many agent runs pause briefly at once. A sleeping task is not automatically spare capacity for another task. Design your concurrency budget around executing and short-waiting work, not just around CPU-heavy operations.

For the agent's reasoning layer, use the separate AI agent frameworks comparison. Trigger.dev's runtime can keep work moving, but the choice of prompts, tools, and approval rules still determines what the agent does.

Schedule Syncs Without Hiding Timing Assumptions

Trigger.dev supports recurring work through schedules.task, with schedules defined in code or attached through the dashboard and SDK. A customer-data sync is a good example: the schedule starts processing, the task handles the work, and the run history shows whether it completed.

The scheduled-task documentation contains a limitation that matters more than the word “cron”: new schedules default to a 60-minute spreading window. A daily job need not start at the exact nominal cron time. Where the plan permits it, window: "0m" disables spreading.

New schedules created on Free are restricted to no more than hourly and a minimum 60-minute window. Existing grandfathered schedules are an exception. Upgrading does not immediately rewrite a restricted schedule; save it again or redeploy it while on the paid plan.

For a daily digest, spreading may be acceptable. For a customer promise that a report appears at an exact time, the default is the wrong assumption. Treat cadence, timezone, and permitted delay as separate requirements before replacing an existing cron job.

Show Progress to Users and Failures to Developers

Trigger.dev Realtime helps turn a background job from an unexplained spinner into a visible workflow. For an import screen, show the run state and progress metadata; for generated text, stream the output while the task works. Those are different data paths.

The Realtime overview distinguishes useRealtimeRun, which follows status and metadata, from useRealtimeStream, which consumes data emitted through defined streams. All Realtime hooks and functions require authentication. A customer should see their import's progress, not gain access to everyone else's runs.

For developers, the dashboard and task logs answer a different question: where did execution stop? Keep user progress messages clear enough to be useful without copying internal error details into the product UI.

Trigger Dev MCP

Trigger.dev's MCP server gives a coding assistant tools to search documentation, initialize projects, trigger tasks, deploy, and inspect runs. MCP, the Model Context Protocol, is the interface through which the assistant calls those tools.

Use it to shorten the edit-and-debug loop, not as a substitute for reviewing the task's behavior. An assistant being able to deploy a workflow says nothing about whether a retry can safely repeat its external actions.

Trigger Dev Pricing: The Production Plan Boundary

Trigger.dev Hobby is the sensible starting point for a small production app whose workload fits its limits: $10/month with $10 of included usage credits, 50 concurrent runs, and 7-day log retention. Free is $0/month with $5 in credits, 20 concurrent runs, and 1-day logs; once those credits are exhausted, you must upgrade to keep tasks running. These are the live pricing page's figures, verified 11 November 2026.

The wall below Hobby is not simply usage. Free's schedule restrictions can disqualify it before compute becomes expensive. Realtime connections are another boundary: Free includes 10 concurrent connections, Hobby 150. Pro is $50/month with $50 of credits, 200 included concurrent runs and 30-day logs, making it relevant when concurrency or debugging history requires the upgrade.

For a concrete estimate, assume 10,000 successful jobs per month, each executing for 60 seconds on Small 1x, with no retries. At $0.0000338 per second plus $0.000025 per invocation, usage is:

10,000 × ((60 × $0.0000338) + $0.000025) = $20.53.

On Hobby, the $10 subscription includes $10 of that usage, leaving $10.53 extra: $20.53 total platform cost, or $0.002053 per completed job under these assumptions. This is arithmetic from the published rates, not a measured workload. Model API calls, storage, and other services remain separate bills; retries add execution work.

Buy the plan for the concurrency, scheduling, and history you need. Estimate usage from time spent executing, then include failure and retry headroom rather than treating a successful-run estimate as a spending ceiling.

Limitations That Can Change the Decision

Trigger.dev removes substantial worker infrastructure, but the remaining responsibilities are specific and consequential.

Self-Hosting Does Not Promise Cloud Parity

Trigger.dev's repository identifies the license as Apache-2.0 and links Docker Compose and Kubernetes deployment guides. Its GitHub repository is the source to check for the code and license.

The self-hosting comparison currently lists warm starts, autoscaling, checkpoints, and dedicated support as Cloud-only. Self-hosting also puts the webapp, Redis, Postgres, worker supervisors, updates, and reliability under your ownership.

For approval-heavy workflows, checkpoint behavior is a material reason to prefer Cloud. The latest release also mentions self-hosted microVM snapshot cleanup, so the documented comparison and release details do not establish simple parity. Confirm the supported behavior of your intended configuration and include infrastructure operation in the decision.

No Platform Timeout Does Not Mean No Failure Policy

Trigger.dev lets runs continue without a fixed platform duration ceiling, but your configuration can still impose maxDuration, a compute-time limit. The duration documentation supports overrides and timeout.None for indefinite execution.

It also says cleanup, onSuccess, and onFailure are not called when the maximum duration is exceeded. That is a sharp edge if your application expects a failure hook to release a reservation or mark an import as failed. Keep a way to reconcile unfinished application records rather than making a single hook your only recovery mechanism.

A Retry Cannot Decide Whether a Business Action Is Safe

Trigger.dev cannot infer whether a partially completed refund, email sequence, or data import should be repeated. Even when execution recovery works, the business result can be wrong if a repeated external action has another effect.

Before adopting it, identify the write that must not happen twice and the record that proves it happened. If your workflow has no such boundary, changing task platforms does not fix its correctness.

Cloud Credentials Need a Deliberate Trust Decision

Trigger.dev reported a security incident on 1 November 2026 involving unauthorized access to environment variables through compromised customer root API keys in some environments. Its incident report says affected customers were notified and impacted keys revoked; self-hosted deployments were not affected.

For a new buyer, that makes credential scope and the vendor's remediation part of the evaluation. It does not establish that every customer was affected, or that a self-hosted installation would automatically be safer. Review what credentials your worker would hold and whether the supported identity options fit your services.

Verdict: Pick It When You Want the Worker Managed

Trigger.dev is the strongest fit here for a TypeScript product team that wants background code, execution infrastructure, and a run dashboard delivered together. Start with one painful workload, such as an import or report generator, and define the retry boundary before migrating the rest.

Choose n8n when an operator needs to own and edit the integration flow. Shortlist Inngest for its explicit step model or native Python/Go workflow SDKs. Choose Temporal when a platform team deliberately wants to own durable business-process architecture across services.

If your requirement is mostly moving information between business apps, the Zapier alternatives guide is a better starting point than adopting task infrastructure.

Use the AI Business Workflow Audit Checklist to map the workload, owner, failure path, and handoff before moving it.

Frequently Asked Questions