Trigger.dev Job Creator

Trigger.dev is an open-source background job platform with self-hosting support. Like Inngest, it provides durable execution with step-level retries and event triggers. Key differences: Trigger.dev v3 uses dedicated machines (configurable CPU/RAM per job), supports longer runs (up to 1 hour on free tier), offers Bun runtime support, and has a strong self-hosted story via Docker. Inngest focuses more on event-driven architecture with tight fan-in/fan-out patterns.

task.run wraps a block of code in a named, durable step. If your job crashes mid-execution, Trigger.dev replays it from the last completed step — not from the beginning. Each step result is cached, so retries skip successfully-completed steps. This makes long-running jobs with external API calls safe to retry without causing duplicate side effects in completed steps.

Machine type determines CPU and RAM allocated to your job run. Use 'micro' (0.25 vCPU, 256MB) for lightweight jobs like sending a single email or webhooks. Use 'small-1x' to 'small-2x' for moderate workloads like data transformation or image processing. Use 'medium-1x' or 'large-1x' for CPU-intensive work like video processing, ML inference, or large database operations. Higher tiers cost more credits per second.

wait.forEvent pauses a running job until a matching event arrives or a timeout expires. This enables human-in-the-loop workflows: start a job on 'user.signup', send a confirmation email, then pause with wait.forEvent for 'user.email.confirmed' with a 24h timeout. If the user clicks within 24 hours, the job resumes with the event payload. If the timeout expires, you get a null result and can handle the unconfirmed case.

Use subtasks (triggerAndWait or batchTriggerAndWait) when work can be parallelized across multiple independent job runs — for example, processing 1000 user records by splitting into 10 subtasks of 100 each. Each subtask gets its own machine and retry count. Use sequential task.run steps when work is inherently linear or when passing data between steps — the output of step 1 feeds into step 2.

No. All code generation runs entirely in your browser using JavaScript. Your job IDs, event names, and step configurations never leave your machine.