Trigger.dev

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build me the background job runner I actually need instead of a hosted Trigger.dev: long tasks with no timeout, retries, and a dashboard showing every step.

Read this first: Trigger.dev is open source and self-hosting it is a real answer — the fee buys the hosted instance. The deeper point is that people reach for this because serverless platforms impose a timeout, and the simplest fix is to run a worker process on an ordinary machine, where the timeout does not exist. That is what this builds.

STACK
- Node 20+ with Fastify for the API and the dashboard
- SQLite through better-sqlite3, WAL mode
- A worker process, or several, on the same machine or another
- Caddy in front

THE DATA MODEL
- tasks: id, key, version, config_json, is_active — a task is code in your repository, registered by key
- runs: id, task_key, task_version, idempotency_key, payload_json, status, attempt, queue, priority, scheduled_for, started_at, finished_at, output_json, error_json, parent_run_id
- steps: id, run_id, key, attempt, status, input_json, output_json, error, started_at, finished_at, ms — one row per checkpoint
- waits: id, run_id, kind, resume_at, token, resumed_at — a delay, or a wait for an external event
- schedules: id, task_key, cron, timezone, next_at, last_run_id, is_active
- queue: id, run_id, run_at, attempts, locked_by, lease_expires_at, priority
- Every step's input and output stored. When a job does the wrong thing at three in the morning, that record is the only thing that answers why

THE IDEA THAT MAKES IT WORK: CHECKPOINTED STEPS
- A task is ordinary code, but each meaningful operation is wrapped as a named step
- A step that has already succeeded in a previous attempt is not run again; its stored output is returned instead
- So a retry after a failure at step seven resumes at step seven, and steps one to six are not repeated. That is what makes long jobs safe to retry, and it is the whole design
- Step keys must be stable and deterministic — derived from the call order, or given explicitly. A step key that changes between attempts breaks resumption silently, so validate it and fail loudly instead
- A step that calls something non-idempotent must carry an idempotency key through to that service

WAITING WITHOUT HOLDING A PROCESS
- A delay is not a sleep. `wait for 3 days` records a resume time, releases the worker, and the run is picked up later
- A wait for an external event records a token; a callback with that token resumes the run
- A wait for a child run resumes when it finishes
- This is what lets one small worker run ten thousand jobs that are mostly waiting

RELIABILITY
- The queue is a table with a lease. A worker claims a run, extends the lease while working, and a crashed worker's run is reclaimed when the lease expires
- Retries with exponential backoff and jitter, per task and per step, with a maximum and a dead-letter state
- Idempotency keys on run creation, so a webhook delivered twice creates one run
- Concurrency limits per task and per queue, plus a per-key concurrency so one customer cannot starve the rest
- Rate limiting for tasks that call an external service with its own limits
- Cancellation that actually stops the run at the next step boundary, and marks it cancelled rather than failed

TRIGGERS
- Called from your application, directly
- On a schedule with a cron expression and a time zone, with both daylight-saving transitions tested
- By a signed webhook, answering immediately and enqueueing
- By another task, as a child run with the parent recorded

THE DASHBOARD
- Runs filterable by task, status, time and idempotency key, failures first
- A run view: every step with its input, output, duration and error, expandable, plus the waits and the retries in the timeline
- Replay a run with the same payload, and replay from a chosen step
- A queue view: depth, oldest item, expired leases, and what is currently running where
- Dark and light

WHAT NOT TO OVERBUILD
- No visual editor. These are jobs written by developers in the repository, and a canvas is a worse way to express them
- No separate deployment story: the tasks are your own code, running from your own build, so a deploy is your deploy

SECRETS AND LOGS
- Payloads and step outputs are stored, so redact secrets by key name and value match before writing, including encoded forms
- A retention policy for payloads, stated and enforced by a sweeper — they are the bulk of the data

OPERATIONS
- .env: DATABASE_PATH, BASE_URL, SESSION_SECRET, WEBHOOK_SECRET, MAX_CONCURRENCY
- Migrations on boot, each once
- Nightly backup off the machine, restore script
- Health endpoint reporting queue depth, oldest unlocked run and any expired lease

WHAT MATTERS MOST
The lease and the step cache. Build those two first, then kill a worker in the middle of a run and confirm it resumes at the right step, exactly once. Everything else here is a dashboard.

Give me the repository, the worker, the client library, migrations, .env.example, two example tasks including one with a three-day wait, and a README with deploy steps behind Caddy.