Trigger.dev is a durable TypeScript runtime, not an agent framework
Trigger.dev does not decide how an AI agent reasons. It runs the code around that reasoning when the work can take minutes, pause for approval, retry after failure, or exceed a web platform's request limit. The README lists queues, schedules, idempotency, waits, concurrency controls, realtime subscriptions, logs, and versioned deployments. You can use familiar model SDKs inside a task while Trigger.dev owns execution state and the run record.
That boundary is useful for document processing, browser jobs, video generation, and multi-step agents. A task stays in the application's TypeScript repository and can call Python scripts, FFmpeg, or browsers through build extensions. Trigger.dev then supplies machines, deployment environments, traces, and retries. The repository had 16,128 stars and 425 open issues and pull requests when fetched, numbers that fit a visible platform with a large operating surface.
Cloud is the easy path; self-hosting is a platform job
The README's quickest start sends a developer to Trigger.dev Cloud, where account creation, a project, and CLI onboarding replace control-plane setup. This is the sensible trial. Write one task, run it in development, deploy it, and inspect its trace before deciding whether the execution model suits your application. The TypeScript API is close enough to ordinary application code that the first experiment does not require learning a separate workflow language.
The Docker self-hosting guide changes the workload. Docker Compose 2.20.0 or newer starts a web app, PostgreSQL, Redis, and related services, while workers execute jobs. The current stack also includes its own container registry and object storage. It ships without working default credentials, so an included script creates application secrets and datastore passwords. Split workers need a matching managed-worker secret and a worker token from the web host.
This is reasonable infrastructure for a shared execution platform, but excessive for one cron job. Worker counts depend on concurrency and task resources. Operators also own backups, upgrades, secret storage, domain and TLS setup, and capacity for job images. Kubernetes support exists for teams already running clusters. Everyone else should price the Cloud service against the engineering time needed to keep this collection healthy.
What happened when we ran it
Our sandbox installed the monorepo at commit cc69ff4 in 129 seconds. Pnpm added 2,536 packages and used 1,984 MB on disk in a fresh Node 22 container with 3 CPUs and 8 GB of RAM. The repository contained 5,939 files and about 898,664 lines of source. Dependency installation worked, but its size makes clear that we were assembling a platform rather than a compact SDK.
The build failed after 7 seconds with exit 2. Turbo reported @trigger.dev/database:build as the failed task; 0 of 4 tasks succeeded. The tail also showed dependent build failures in internal packages, but it did not include the original compiler message above that point. We cannot responsibly name the cause from this log. One relevant mismatch is factual: the current contribution guide pins Node.js 24.18.0, while our supplied lab image used Node 22.
Tests failed after 6 seconds with exit 2 because the same database build failed before the suite could proceed. Turbo reported 0 successful tasks out of 8 and ended with Test failed. See above for more details. This result does not say that Trigger.dev's assertions failed. It says our clean installation was unable to cross the monorepo's build prerequisite using that sandbox.
A local contribution needs six data services and exact tool versions
The contribution guide currently asks for Node.js 24.18.0, pnpm 10.33.2, Docker, and protobuf. Its development stack starts PostgreSQL, Redis, Electric, MinIO, ClickHouse, and s2-lite before database migration, building, seeding, and the web app on port 3030. Manual SDK testing also uses a separate references repository. This is good disclosure, though it means casual source changes carry real setup cost.
External contributors face a social gate too. A maintainer must vouch for a new contributor before their pull request is accepted, and the guide says unvouched submissions are closed automatically. That may keep drive-by noise down, but it is a real reason a capable developer might choose an easier project for a small fix. The repository's 35 CI workflow files suggest the maintainers invest heavily in automated review once code enters the process.
Retries require precise side-effect boundaries
Retries and idempotency are central to durable execution, and the difference between task deduplication and side-effect deduplication matters. Issue 4627 points out that Trigger.dev idempotency keys are consumed by task trigger calls, not by an arbitrary payment API call inside run(). If a later line throws and the task retries, the payment provider needs its own idempotency key or the payment should live in a keyed child task.
Documentation quality is generally high, but it can lag a fast SDK. Issue 4782 reports 3 prompt-related exports that no longer compile against @trigger.dev/sdk 4.5.12 among 267 checked TypeScript samples. The report is narrow and reproducible, not a claim that the whole documentation set is broken. It does justify type-checking copied examples in your own project.
Release 4.5.12 shows why versioning matters
Release 4.5.12 shipped on 2026-08-20, five days before the repository's latest fetched push. It added stable windows for scheduled tasks, deployment identifiers, runtime pinning, and fixes for leaked concurrency slots, queue stalls, paused environments, and deployment promotion races. Those are serious production concerns, and the active repair work is reassuring. It also means teams should pin versions and read operational release notes.
Trigger.dev is the best fit when TypeScript developers want durable jobs without adopting Temporal's full workflow model. Inngest is the closer comparison for event-driven functions, while Windmill makes more sense when scripts and internal apps belong in the same product. Our 1,984 MB install and blocked build argue for starting with the hosted path. Move to self-hosting only after the execution semantics have earned that infrastructure.