---
title: "Trigger.dev"
description: "Use Trigger.dev for MainSDK background jobs - a planned driver with setup, main.yaml, retries, local testing and swapping."
section: "integrations"
canonical: "https://mainsdk.dev/docs/integrations/trigger-dev"
updated: "2026-10-28"
---

# Trigger.dev

> Use Trigger.dev for MainSDK background jobs - a planned driver with setup, main.yaml, retries, local testing and swapping.

Canonical: https://mainsdk.dev/docs/integrations/trigger-dev · Updated: 2026-10-28

Trigger.dev is an open-source background jobs platform, hosted or self-hosted, and a planned driver behind [`events` and `jobs`](https://mainsdk.dev/docs/interfaces/jobs). Pick it when your team already runs long or heavy tasks on Trigger.dev and wants MainSDK's idempotency and dead letters on top.

> **Note:** The `trigger-dev` driver comes from the product requirements, and the webhooks-jobs spec defers it to the driver kit. It is a planned driver, not in the spec yet.

## Interfaces it serves

### Events and background jobs (`jobs`)

- Status: Building for 0.3 · ships as a stable API
- Driver: `trigger-dev` (Trigger.dev, planned driver). the spec defers it to the driver kit
- Docs: https://mainsdk.dev/docs/interfaces/jobs.md

```yaml
jobs:
  driver: trigger-dev
```

Swap to another provider: `db`, `local`, `inngest`, `vercel-queues`, `sqs`.

## Before you start

1. Create a Trigger.dev project, hosted or on your own instance.
2. Copy the secret key for each environment (development, staging, production) into your secrets manager.

## Configure

```yaml title="main.yaml"
jobs:
  driver: trigger-dev   # [TBD] key and project settings; suggested secret name TRIGGER_SECRET_KEY
  dead-letter: true
```

## Use it

```ts title="app/orders/ship.ts"
import { jobs } from "mainsdk";

export async function queueLabel(orderId: string) {
  await jobs.run("orders.print-label", { orderId }, { idempotencyKey: `label:${orderId}` });
}
```

## Local development and testing

Use the in-process local queue in development; `mainsdk check` refuses it in production. In tests, `createTestApp()` from `@mainsdk/testing` runs jobs on a fake, and `chaos.on("jobs", { outage: true })` simulates Trigger.dev being down.

## What MainSDK adds on top

- Retries with backoff and a dead-letter queue.
- A duplicate key never runs the side effect twice.
- CloudEvents envelope with versioned schemas for events.

See [Events and background jobs](https://mainsdk.dev/docs/interfaces/jobs).

## Limits and notes

- Planned driver, not in the spec yet: the spec defers it to the driver kit.
- Job inputs are stored by Trigger.dev or your own instance; choose a location that fits your region.

## Swap to or from it

```yaml title="main.yaml"
jobs:
  driver: trigger-dev   # was inngest
```

> **Warning:** What happens to jobs already queued or scheduled on the old driver is not specified yet [TBD]; let them drain before you switch.

## FAQ

**Can I use Trigger.dev today?** Not through MainSDK until the driver ships; check the drivers list for its status.

**Will my task code change?** No. You keep calling `jobs.run()` and `jobs.schedule()`.

## Next

- [Events and background jobs](https://mainsdk.dev/docs/interfaces/jobs)
- [Inngest](https://mainsdk.dev/docs/integrations/inngest) and [Amazon SQS](https://mainsdk.dev/docs/integrations/amazon-sqs)