Which strategy should I use for Trigger.dev v4?

Teams already on Trigger.dev need to decide whether to absorb the v4 SDK and runtime breaks now or keep v3 infrastructure in place for a short period longer.

Migrate to Trigger.dev v4 on Cloud now if you need production deploys past April 2026; hold v3 only when you can validate and cut over before the cutoff.

Blockers

Who this is for

Candidates

Migrate to Trigger.dev v4 now on Cloud

As of 2026-03-19, Trigger.dev says v4 is stable, fully supported, and recommended for all users, while v3 is being retired. New v3 deploys will stop working on 2026-04-01, and v3 will be fully shut down on 2026-07-01. The v4 migration requires updating `@trigger.dev/*` packages to `4.x`, moving imports from `@trigger.dev/sdk/v3` to `@trigger.dev/sdk`, and adapting breaking changes such as predeclared queues, lifecycle hook signatures, batch retrieval, and some `ctx` fields. Current Cloud pricing as of 2026-03-19 starts at Free `"$0/month"` with `"$5 free monthly usage"`, Hobby `"$10/month"` with `"$10 monthly usage included"`, and Pro `"$50/month"` with `"$50 monthly usage included"`, plus `"$0.000025"` per run and per-second compute charges.

When to choose

Use this when you are low-ops and need Trigger.dev Cloud to remain a supported part of production after April 2026. The decisive factor is the hard retirement schedule: if you need ongoing new deploys, staying on v3 is not a durable option.

Tradeoffs

You stay on the supported path and keep Cloud-only capabilities, but you must absorb code changes and perform a controlled cutover.

Cautions

During activation, old runs can continue on v3 while new runs use v4, so Trigger.dev warns you may temporarily see up to double concurrent execution. Trigger.dev also warns infrastructure IPs may change during migration, so IP allowlists may need updating. v4 runtime options differ from v3 and are explicitly `node`, `node-22`, or `bun` in `trigger.config.ts`.

Sources

Hold on existing v3 deploys only as a short bridge

As of 2026-03-19, this remains possible only as a temporary bridge, not a long-term strategy. Trigger.dev states that from 2026-04-01 new v3 deploys will no longer work, although existing v3 runs will continue to execute until the full shutdown on 2026-07-01. That means teams with a production freeze can defer the migration briefly, but only if they can tolerate no fresh v3 deploys after April 1. The practical blocker is schedule risk, not pricing: Cloud pricing is already usage-based and publicly listed, but the platform support window for v3 is closing.

When to choose

Use this only if you already have a working v3 deployment and need a very short buffer to test migration changes before 2026-04-01. The decisive factor is whether your org can complete validation and cutover before the deploy cutoff, not whether v3 remains a supported destination.

Tradeoffs

You avoid immediate migration churn for a short time, but you increase deadline pressure and compress testing near a hard service cutoff.

Cautions

This is not viable if you expect to keep shipping v3 task deploys after 2026-04-01. You should still rehearse the documented migration order, because Trigger.dev notes that backend and task deploy sequencing matters and mixed v3/v4 execution can temporarily affect concurrency.

Sources

Facts updated: 2026-03-19
Published: 2026-04-03

Related questions

Try with your AI agent

$ npm install -g pocketlantern
$ pocketlantern init
# Restart Claude Code, Cursor, or your MCP client, then ask:
# "Which strategy should I use for Trigger.dev v4?"
Missing something? Request coverage