An open-source background-job platform that gives you durable runs, cron schedules, retries, and a real observability dashboard — without standing up Redis, BullMQ, and a worker fleet. Pricing and capabilities verified against trigger.dev/pricing and the public docs.
Background jobs are one of those areas every solo SaaS founder eventually hits and almost no one wants to spend a week on. You ship the product, then realize the welcome email needs to send a minute after signup, the AI image generation takes 90 seconds and can’t block the request, the daily-digest cron fires at 8am, and an OpenAI call occasionally fails so you need retries. Suddenly you’re looking at Redis, BullMQ, a worker process, a deployment story, and a way to actually see what’s running. Trigger.dev is one of the platforms trying to make that whole pile go away.
Methodology. This is a research-based overview. We have not personally built production apps with Trigger.dev; this article synthesizes the company’s documentation at trigger.dev/docs, public pricing at trigger.dev/pricing, the Trigger.dev v3 announcement, and third-party user reports from public discussions. Last reviewed: May 7, 2026.
Trigger.dev is an open-source background-job platform built specifically for TypeScript. The current generation, v3, shipped in 2024 and is a substantial rewrite of the original product — the v2 model relied on long-lived integrations and webhook delivery, while v3 centers on a simpler primitive: tasks, which are TypeScript functions you push to Trigger.dev’s runtime and invoke from anywhere in your app. The runtime takes care of executing them, retrying them, scheduling them, and showing you what happened.
The pitch is: write your background job as a regular TypeScript function, and Trigger.dev handles the rest of the queue infrastructure. No Redis, no worker process, no separate dashboard. Trigger.dev runs as a hosted Cloud product or as a self-hosted deployment, and the codebase is open source under a permissive license.
Five primitives do most of the work:
cron: "0 8 * * *" for an 8am daily run. No separate scheduler service, no Vercel Cron route file.Each of these maps onto something you’d otherwise build by gluing BullMQ, Bee-Queue, or a custom Postgres-as-a-queue setup together. The integration is the value, not any single feature in isolation.
A task in Trigger.dev v3 is a TypeScript file that exports a task definition. The shape, per the docs:
import { task } from "@trigger.dev/sdk/v3";
export const sendWelcomeEmail = task({
id: "send-welcome",
run: async (payload: { userId: string }) => {
const user = await db.users.findById(payload.userId);
await resend.emails.send({
to: user.email,
from: "hi@yoursaas.com",
subject: "Welcome",
html: renderWelcomeTemplate(user),
});
return { sent: true };
},
});Three things are worth noticing. First, the task is just a function. There’s no special class, no decorator, no separate worker file. Second, the id is the stable name Trigger.dev uses to address the task — you can rename the file and the variable, but changing the id detaches it from its run history. Third, the payload is fully typed, and the SDK uses that type to give you compile-time safety when you trigger the task elsewhere in the codebase.
Triggering looks like this from a Next.js server action, a webhook handler, or another task:
await sendWelcomeEmail.trigger({ userId: user.id });That call doesn’t execute the function in your app process. It enqueues the task with the Trigger.dev runtime, which executes it on its own infrastructure. Your server action returns immediately; the user gets a response in milliseconds; the email goes out asynchronously. The same pattern works for AI generation jobs that take 90 seconds, batch report generation that fans out across thousands of records, or webhook processing that needs reliable retries.
Most homegrown background-job setups die not because the queue fails but because nobody can tell what’s happening when it does. Trigger.dev’s built-in dashboard is a meaningful chunk of the value proposition:
logger.info() calls inside a task stream into the dashboard live, so you can watch a long-running job progress.Compared to a self-hosted BullMQ + Bull Board setup, the polish gap is large. Compared to “tail the Vercel logs and hope,” the gap is even larger. Observability is the thing founders most often skip when they roll their own queues, and Trigger.dev makes it the default rather than a bolt-on.
Trigger.dev publishes four plans on trigger.dev/pricing:
Self-hosting is free and fully open source. The trade-off is that you’re running the infrastructure: a Postgres database, a Redis instance, the Trigger.dev backend services, and however many worker containers your workload needs. For solo founders the math usually works out to “Cloud is cheaper than the time spent self-hosting,” but the option is real and not hobbled. Always reconcile current numbers against the public pricing page; cap structures shift periodically.
Three considerations matter when deciding between hosted Trigger.dev and a self-hosted deployment:
Most solo founders should start on Cloud and revisit the question only if they hit a clear cost or compliance trigger. Premature self-hosting is one of the easier ways to burn a weekend per month on infra you didn’t need to own.
Three product shapes where Trigger.dev is genuinely the right pick:
The common thread: jobs with logic, jobs with cost, and jobs you can’t afford to silently drop. The deeper your background work goes, the more value the platform extracts.
Two scenarios where Trigger.dev is overkill:
Most solo SaaS founders are comfortably between these two extremes. The middle is where Trigger.dev shines.
Inngest is the closest competitor — both are TypeScript-native background-job platforms with hosted and self-host options. Inngest emphasizes event-driven workflows and step functions; Trigger.dev emphasizes the durable-run primitive with queues and schedules layered on top. For event-fanout patterns and very high throughput, Inngest’s model often feels more natural. For long-running tasks with cost-sensitive retries (LLM jobs, video pipelines), Trigger.dev’s checkpoint model is a closer match. Both have generous free tiers; the right pick is shaped more by your workload than by raw feature count.
Vercel Cron is the lightweight option. It’s a built-in feature of Vercel that calls a route in your Next.js app on a cron schedule. There’s no separate SDK, no separate dashboard, no concurrency control, no retries beyond what your route does itself, and no observability beyond the Vercel logs. For a daily-digest cron or a weekly cleanup job, that’s genuinely enough. The moment your job needs retries, durable execution, or any concurrency story, Vercel Cron stops scaling and Trigger.dev becomes the right pick. We compare hosting platforms more broadly in Vercel vs Railway.
BullMQ is the “build it yourself” baseline. You provision Redis, write your worker process, deploy that worker somewhere, and add Bull Board for the dashboard. BullMQ is mature, free, and fully under your control. It’s also a project of its own — the operational tax of running stateful Redis with replication and the engineering tax of building observability that approaches what Trigger.dev ships out of the box are both real. For a solo founder optimizing for shipped features per week, the trade often goes against rolling your own.
Trigger.dev is the right pick when at least one of the following is true: your background work has more than five lines of logic, retries matter for cost or correctness reasons, or you need to be able to see what’s actually running in production. If none of those apply — if your background work is one route fired by Vercel Cron once a day — the platform is overkill and there’s no shame in the simpler tool.
The free tier is generous enough to validate fit without paying anything: 50 runs a day and 5 concurrent runs covers a real side project or pre-revenue beta. If the SDK and the dashboard feel right at that scale, the upgrade path to Hobby and Pro is gradual and the prices are in line with the rest of the modern dev-tool stack we cover in our best SaaS tools for developers roundup.
For AI-first SaaS specifically — the kind of product covered in our AI chatbot SaaS guide — the durable-run primitive is hard to give up once you’ve seen it work. LLM calls are slow, occasionally flaky, and expensive enough that “just retry the whole thing” is the wrong default. Trigger.dev’s checkpoint model treats this as the central case, not an edge.
Trigger.dev v3 is the strongest TypeScript-native background-job platform on the market for solo founders who’ve outgrown Vercel Cron but don’t want to babysit Redis. The free tier is generous, the dashboard is a real feature rather than an afterthought, the durable-run model maps cleanly onto AI-shaped workloads, and the open-source license keeps the lock-in story honest.
The honest caveats: you’re adopting another SDK and another dashboard, the run meter is something to model against your actual workload, and at the simplest end of the spectrum a single Vercel Cron route is still a perfectly reasonable answer. For anything past that floor, Trigger.dev deserves a serious look.
The stack, prompts, pricing, and mistakes to avoid — for solo founders building with AI.