Files
James Ritchie fade22015f Docs – v4 GA updates (#2298)
* Adds new features table to top of v4 upgrade guide

* Adds wait idempotency to wait-until, wait-for, and wait-for-token pages

* Adds new priority docs page and updates the v4 upgrade guide

* Adds new task lifecycle hooks

* Removes the message about requiring tasks to be exported

* Adds new global lifecycle hooks section

* Moves sections from upgrade guide into the table

* Adds hidden task page

* Improves the global lifecycle hooks section

* Updates middleware and locals section

* Adds new useWaitToken page to the react hooks section

* Adds a new ai.tool section

* Moves Docker (legacy) page into self-hosting section

* Removes known issues from v4 upgrade guide

* Replace “toolTask” with “ai.tool” in the Streams page example

* Renames guide to “Migrating from v3” and adds redirect

* Remove references to v4

* Removes changelog from migration guide

* The installation guide now references `@latest update`

* Changes all references from `/sdk/v3` to `/sdk`

* Updates @v4-beta to @latest

* Fixed broken link

* Fixes broken link

* Adds an upgrade to v4 using AI section

* Fixes 2 broken links

* Adds an entry for targetting preview branches

* Updates the run statuses

* Adds boolean helpers section to the runs and realtime pages

* Updates the concurrency page

* Updates the test page to include the new options

* Adds SDK and curl options for the preview branch targeting

* Updates new bulk actions page

* Remove the releasing concurrency section

* Got rid of some more @v4-beta mentions

* Improved rate limit docs

* Improved migrating docs

* Removed commented sections of the docs

* useWaitToken hook

* Fixed the description

* Fix for missing test image

---------

Co-authored-by: Matt Aitken <matt@mattaitken.com>
Co-authored-by: Dan <8297864+D-K-P@users.noreply.github.com>
2025-08-18 12:34:55 +01:00

141 lines
4.5 KiB
Plaintext
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
---
title: "Migrating from Mergent"
description: "A guide for migrating from Mergent to Trigger.dev"
sidebarTitle: "Migrating from Mergent"
---
Mergent is being absorbed into Resend, so if youre running background jobs or scheduled tasks on Mergent, now is a good time to migrate. Trigger.dev is a modern, developer-friendly platform for background jobs, workflows, and scheduling.
### Why Trigger.dev?
- **Long-running, reliable tasks:** Write typical async code, no unfamiliar syntax to learn.
- **Automatic retries, concurrency, and scheduling:** Configure your tasks in your `trigger.config.ts` file.
- **Local dev that matches prod:** Run and debug jobs locally and view everything in the dashboard.
- **Scales with you:** Deploy your tasks to Trigger.dev Cloud with no infrastructure to manage. Or self-host.
## How to migrate to Trigger.dev
### Step 1: Set up Trigger.dev
1. **Create an account** at [Trigger.dev Cloud](https://cloud.trigger.dev).
2. **Create an organization and a project.**
3. **Install the CLI** and run the local dev server:
```bash
npx trigger.dev@latest init
npx trigger.dev@latest dev
```
Youll get a local server that behaves just like production, and youll see your runs in the dashboard.
### Step 2: Convert your Mergent task to a Trigger.dev task
#### Example: Basic Mergent Task
Heres a simple Mergent task that processes an image:
```ts processVideo.ts
export async function processVideoTask(req: { body: { videoUrl: string } }) {
const { videoUrl } = req.body;
// Do some video processing
const result = await processVideo(videoUrl);
return { success: true, processedUrl: result.url };
}
```
This is typically called by Mergent via HTTP POST, and youd register the endpoint in the Mergent dashboard.
#### The same task in Trigger.dev
```ts trigger/processVideo.ts
import { task } from "@trigger.dev/sdk";
export const processVideoTask = task({
id: "process-video",
run: async (payload: { videoUrl: string }) => {
const result = await processVideo(payload.videoUrl);
return { success: true, processedUrl: result.url };
},
});
```
**Key differences:**
- In Mergent, your task is an HTTP handler; in Trigger.dev, its a `task()` function that gets deployed on a managed worker for you.
- Trigger.dev gives you a typed payload, not a raw HTTP request.
- No need to handle HTTP status codes or errors—Trigger.dev handles retries and failures for you.
- You can export multiple tasks from a single file.
---
#### Scheduled task example
**Mergent scheduled task:**
Youd set up a schedule in the Mergent dashboard to hit your HTTP endpoint on a cron.
```ts dailyReport.ts
export async function dailyReportTask(req) {
await sendDailyReport();
}
```
**Trigger.dev scheduled task:**
```ts trigger/dailyReport.ts
import { schedules } from "@trigger.dev/sdk";
export const dailyReportTask = schedules.task({
id: "daily-report",
cron: "0 0 * * *", // every day at midnight UTC
run: async () => {
await sendDailyReport();
},
});
```
- In Trigger.dev, you can define the schedule right in your code (or attach it in the dashboard).
- No need to set up HTTP endpoints for each scheduled job.
## Triggering your tasks
**Mergent:** Youd trigger a task by calling the Mergent API, specifying the URL and payload.
```ts
const Mergent = require("mergent");
const mergent = new Mergent("API_KEY");
mergent.tasks.create({
request: {
url: "https://your-app.com/api/processImage",
body: JSON.stringify({ imageUrl: "...", filters: ["blur"] }),
headers: { "Content-Type": "application/json" },
},
delay: { minutes: 5 },
});
```
**Trigger.dev:** You trigger a task directly from your codebase, no HTTP endpoint needed.
```ts
import { processImageTask } from "@/trigger/processImage";
await processImageTask.trigger({
imageUrl: "...",
filters: ["blur"],
}, {
delay: "5m",
});
```
- You can trigger tasks immediately, or add logic inside the task to delay execution (using `wait.for` or `wait.until`).
- No need to expose HTTP endpoints for every task.
**Summary:**
- Mergent tasks are HTTP handlers; Trigger.dev tasks are functions that get deployed on a managed worker for you.
- Scheduling and retries are built-in and configured in code.
- Trigger.dev tasks are type-safe, and easy to debug.
- You dont need to manage endpoints or handle HTTP manually.
Thats it. Youre ready to migrate. If you need more advanced features such as concurrency, retries, metadata, chaining tasks, and more, check out the [Trigger.dev docs](https://trigger.dev/docs).