Trigger Dev

Tasks are defined using the task() function from the SDK with a run handler. Triggers include: scheduled (cron), webhook, custom event, and manual. Tasks can call subtasks for workflow composition. The SDK provides trigger.tasks.trigger() to start tasks programmatically from application code. Batch triggering sends multiple task invocations in one call. The REST API at api.trigger.dev provides task triggering, run status, and management operations. Run results are retrievable by run ID. Environment variables are managed per-environment (dev, staging, production). The v3 architecture uses a deploy command to push task code to Trigger.dev's infrastructure — similar to deploying to a serverless platform. Task configuration includes retry policies, timeouts, and concurrency limits.

Task retries are automatic with configurable retry count and backoff strategy. Failed runs are visible in the dashboard with full error stack traces and execution logs. Run status transitions: pending → executing → completed/failed/cancelled. The managed infrastructure handles container lifecycle — agents don't manage container health. Timeout configuration prevents runaway tasks. Concurrency limits prevent resource exhaustion. The dashboard provides real-time logs during execution, which is valuable for debugging long-running tasks. Dead runs (infrastructure failures) are detected and retried. The main reliability consideration: dependency on Trigger.dev's infrastructure means platform outages affect all tasks. The self-hosted option mitigates this for critical workloads.

Trigger.dev v3 is a managed compute platform for background tasks — it runs your TypeScript code in isolated containers with automatic scaling, retries, and scheduling. For agents, the key differentiator from Inngest is execution model: Trigger.dev manages the compute infrastructure, while Inngest invokes your existing endpoints. This means Trigger.dev handles long-running tasks (hours, not just seconds) that serverless functions can't support. Use cases include: AI model inference pipelines, data processing jobs, scheduled reports, webhook-triggered workflows, and any task that might exceed serverless timeout limits. Tasks are defined in TypeScript with a decorator pattern. The platform provides a dashboard for monitoring runs, viewing logs, and debugging failures. Self-hosted deployment is available for teams requiring infrastructure control.

API keys (secret keys) authenticate task triggers and management API calls. Keys are per-environment (dev, staging, production). The deployment model pushes code to Trigger.dev's infrastructure — this means your task code runs on their managed containers, not your servers. Secret keys should only be used server-side. For agents, the deployment model requires trusting Trigger.dev's infrastructure with your code and environment variables. Self-hosted deployment eliminates this trust requirement. The dev CLI provides local development with tunneling for webhook testing. No OAuth for API integrations. Key rotation is supported in the dashboard. The auth model is straightforward but the deployment trust model is the key security consideration.

Documentation at trigger.dev/docs is focused and well-organized for the v3 architecture. Quickstart guides cover project setup, task creation, deployment, and triggering. The documentation is TypeScript-native — code examples use TypeScript throughout. Framework integration guides cover Next.js, Remix, Express, and others. The CLI documentation covers local development, deployment, and environment management. The v3 documentation is significantly better than v2 — the architectural simplification (managed compute vs. webhook invocation) made the docs clearer. Community Discord is responsive. The documentation's main gap: being TypeScript-only limits the audience — Python and other language support isn't available yet. For TypeScript-native agents, the developer experience is excellent.