Trigger.dev v4 review (June 2026): hands-on with the open-source background-jobs starter for Next.js

Quick answer (June 29, 2026): Trigger.dev v4 is the open-source, Apache-2.0, TypeScript-native background-jobs platform you actually want behind a Next.js app in 2026. v4 went GA in August 2025; the v4 line is healthy in June 2026 with v4.4.6 as the latest stable on npm and the v4.5.0-rc series shipping weekly on GitHub. You write tasks as ordinary task() functions in your repo, the CLI deploys them to Trigger.dev Cloud or your own self-hosted instance, and Run Engine 2 handles retries, queues, concurrency, and warm starts for you. Pair it with a Next.js 15 storefront for the UI and you have a real workflow stack a solo founder can run on Trigger.dev's Free plan, ship to the $10 Hobby plan when traffic shows up, and stay on for the rest of the year without a finance conversation. The catches: Cloud is now the path of least resistance and self-hosting is genuinely more work than the website implies, the v3 to v4 upgrade still has sharp edges you should plan for, and "fully managed AI agents" in the homepage tagline is a positioning bet, not a feature gap to lord over plain background workers.

Is Trigger.dev v4 still being shipped in June 2026?

Yes, and the GitHub repo makes the case better than anything in the docs.

The triggerdotdev/trigger.dev GitHub repo sits at 15.5k stars, the default branch is main, the last commit landed on June 29, 2026, the license is Apache-2.0, and the release timeline reads like a healthy product: v4.5.0-rc.7 on June 17, rc.6 on June 12, rc.5 on June 5, rc.4 on June 2, rc.3 on June 1, the v4.4.6 stable on May 12. The @trigger.dev/sdk package on npm tracks the same line at v4.4.6 with the next tag wired up for the v4.5 candidates. v4 itself went GA on August 18, 2025; v4.5 is the next minor that brings the second-generation Run Engine 2 across the entire fleet, with the rc cadence the team uses to dogfood at scale before flipping the stable tag.

For a project where the dominant narrative in late-2025 was "did the AI-workflow pivot kill the original product," that release table is the answer. Trigger.dev did pivot the homepage tagline to "build and deploy fully-managed AI agents and workflows," but the underlying engine is still the same background-jobs primitive, and June 2026 is the quietest month it has had in a year. If you are evaluating Trigger.dev v4 today, the maintenance question is closed.

What does the v4 abstraction actually give you?

A task() function and a CLI. That is the whole product.

You define a task in your repo:

import { task } from "@trigger.dev/sdk";
export const sendWelcomeEmail = task({
  id: "send-welcome-email",
  run: async (payload: { userId: string }) => {
    // your code, with retries, queues and concurrency for free
  }
});

You trigger it from anywhere in your Next.js app with await sendWelcomeEmail.trigger({ userId }). The CLI handles bundling, deploying to Trigger.dev Cloud, and showing you the dashboard. v4 adds Run Engine 2 underneath: warm starts so cold-boot latency stops eating your p95, run prioritization so onboarding-flow tasks beat the nightly batch, idempotency keys that survive replays, input and output streams for bidirectional progress, and the new wait.for() primitive that lets a task pause for hours or days without burning a runtime slot.

Compared with rolling your own on Postgres + BullMQ, the practical win is that you stop owning the queue. You write code, the platform shows you exactly which run failed, where, and why; the retry rules live next to the task, not in three different cron files; the deployment story is npx trigger.dev@latest deploy and a green checkmark.

How long does the starter actually take to clone, run, and deploy?

We timed a clean clone on June 28, 2026 against a fresh Next.js 15 app on a 2024 MacBook Air. From an empty terminal to a triggered task in Trigger.dev Cloud:

1. npx create-next-app@latest my-app and pick the App Router defaults. ~45 seconds.
2. cd my-app && npm install @trigger.dev/sdk@latest and the dev CLI alongside it. ~25 seconds.
3. npx trigger.dev@latest init and sign in with GitHub. The wizard creates a project ref and writes trigger.config.ts for you. ~90 seconds end to end.
4. Drop a trigger/send-welcome-email.ts file with the snippet above. ~60 seconds.
5. npx trigger.dev@latest dev in one terminal, your Next.js dev server in another. The CLI streams a live run inspector at cloud.trigger.dev/orgs/.../projects/.../runs. ~30 seconds to first run.
6. Wire the trigger call into an App Router server action and fire it from a form. ~3 minutes of plumbing.
7. npx trigger.dev@latest deploy to push the task to the staging environment in Trigger.dev Cloud, promote to prod from the dashboard. ~2 minutes including the build.

Total: about nine minutes from npx create-next-app to a production task with retries, queues, observability and a dashboard. The slowest part is GitHub OAuth.

The five deploy paths for a Next.js app + Trigger.dev tasks

The honest matrix we ran on June 28, 2026 against Trigger.dev v4.4.6 + Next.js 15.4, with Postgres on Neon and Redis on Upstash where required:

Path A is the right default. It is the only path where you genuinely operate nothing, the free credits are enough to learn the product end to end, and you can move to path B without a code change. Path C is where most production apps end up: Pro gives you the higher concurrency limits and the longer task durations you will actually hit when an LLM call decides to take 90 seconds. Path D is honest work; the open-source self-hosting docs cover it but the operational surface is more than the marketing site implies. Path E is the bet that you do not want to own the Next.js shell either; Totalum's own breakdown of Builder.io against an AI app builder walks through the same managed-shell vs visual-builder decision from the other direction.

What does Trigger.dev actually cost at small, medium and large scale?

Published Cloud pricing on trigger.dev/pricing as of June 29, 2026 reads: Free at $0/mo with $5 of one-time credits, Hobby at $10/mo, Pro at $50/mo + usage, Enterprise custom. Compute is metered per second of CPU and memory; the page calls out 800ms runs at about $0.0000338 each, so a 10k-run month at that profile is roughly $0.34 in compute on top of the plan fee. The cost math that actually matters:

• Solo founder, 10k task runs/mo, mostly send-email and webhook-fan-out work: about $10/mo on the Hobby plan, dominated by the plan fee rather than usage.
• Funded startup, 250k task runs/mo, mix of LLM calls and integrations: about $50/mo plan fee + roughly $8 to $25 in usage depending on average run duration. The dominant cost is the LLM provider, not Trigger.dev.
• Agency operator running 12 client workspaces on one Pro plan: about $50/mo plan + per-client usage; the seat math (above 1 seat is $20/month per seat) is the variable to watch, not compute.
• Self-host on Railway for the same 250k-run profile: about $40 to $80/mo (Postgres + Redis + 2 web + 2 worker containers) and roughly four hours a quarter of operating time on top.

For comparison: the equivalent stack rolled by hand on Vercel Cron + BullMQ + a managed Postgres on Neon will run you about $20/mo at the same volumes once you include the Postgres tier you need for the queue tables. The premium for Trigger.dev Hobby is the dashboard, the retry framework, and not maintaining the queue worker.

Trigger.dev vs Inngest vs Convex, June 2026 honest read

The three projects look adjacent on a hosting-budget spreadsheet and very different in production:

• 

  Trigger.dev is a background-jobs platform. It models work as task() functions deployed alongside your app. Best when the job IS the unit ("send a welcome email, retry on failure, finish in seconds to hours").

• 

  Inngest is an event-driven workflow orchestrator. The

  

  inngest/inngest GitHub repo was at 5.5k stars and last shipped v1.33.0 on June 23, 2026; the v1.33.1-test series is in flight. Inngest's strength is event fan-out, multi-step state-machine workflows, and a TypeScript SDK that reads like a workflow library. Best when the work is "react to an event, run these five steps in this order, durable, observable."

• 

  Convex is a reactive backend + database, not a jobs platform. It has scheduled actions and cron, but the product center of gravity is "the database your frontend subscribes to." Best when the app you are building is mostly real-time CRUD with some background work, not the other way around.

If you are picking between Trigger.dev and Inngest specifically: pick Trigger.dev when your work is independent tasks with retries and a dashboard your support team needs to read; pick Inngest when the work is an event flowing through five steps and the durable-execution semantics are the product. Convex is a different question; do not buy it to run background jobs.

ShipGarden's June 2026 Medusa.js v2 commerce starter review covers the same deploy-paths shape from the commerce-backend side, and Builderdex's June 2026 comparison of AI app builders for building AI agents walks the platform-vs-DIY decision a level above the framework choice.

Where Trigger.dev v4 still loses

Three honest disadvantages, after a week with the stack:

1. Self-hosting is real work. The docker compose recipe will run on a laptop in minutes, but a production self-host needs Postgres + Redis + the webapp + worker containers + a tunnel for builds, and the docs lean on "you'll figure it out" in the operational sections. Plan a real afternoon.
2. The v3 to v4 upgrade has sharp edges. New project ref schema, new config file shape, a deploy-rebuild for every migrated task. If you have a busy v3 project, do it on a Friday and book Saturday morning for the rollback you probably won't need but will be glad you scheduled.
3. The "AI agents" framing on the homepage is a positioning bet. Trigger.dev v4 runs your code; if your code is "call an LLM, parse the response, write a row," then yes, you are running an AI agent. But there is no agent-runtime magic; you are still writing the prompt, the tool calls, and the retry policy. If you wanted that magic, you wanted

   

   Mastra or a different abstraction.

Should you ship with Trigger.dev v4 today?

Yes, with one caveat: ship on Cloud first.

For a solo founder or a small team building a real Next.js app in June 2026, Trigger.dev v4 on the Free plan is the highest-return choice on this shelf. You get retries, queues, concurrency, a dashboard, deploys-by-CLI, and a migration path up to Pro that does not require a finance review. The framework has compounded for two years, it shipped GA almost a year ago, the v4.5 line is in active rc, and the maintenance signal is the strongest of the three platforms in this gallery slot. Self-host only after the bill matters, not before. Trigger.dev's own quick-start docs cover the rest, and DevMoment's 30-day MCP-server-in-production field log is the field report you actually want to read before you put background tasks behind a customer.