Trigger.dev

Last reviewed Aug 26, 2026 · 840 words

Trigger.dev is for developers who are tired of cron, hand-rolled queues and the 30-second timeouts on serverless functions, and it is not a Zapier replacement despite the catalogue listing it as one. If you want click-together automations that a non-programmer can maintain, n8n is the right download. If you write TypeScript and want to await a 3-hour job with retries, checkpoints and a trace view, Trigger.dev is the best-designed option I have used, and self-hosting it is officially supported but heavier than the "Postgres and Redis" summary suggests.

Tasks are functions, not flowcharts

A task is an exported TypeScript function with an id, and the framework handles queueing, retries, concurrency limits and logs:

import { task } from "@trigger.dev/sdk";

export const rebuildThumbnails = task({
  id: "rebuild-thumbnails",
  retry: { maxAttempts: 3 },
  run: async (payload: { albumId: string }) => {
    // hours-long work is fine; there is no execution timeout
  },
});

You trigger it from your app with rebuildThumbnails.trigger({ albumId }), schedule it with a cron expression, or fire it from a webhook. Long waits are cheap because a task can pause for hours or days without holding a process open. This is the feature that separates it from n8n or a plain worker: the code is ordinary code, and the reliability layer is someone else's problem.

The self-host stack is bigger than the summary

The listed minimum is 1 GB of RAM, and that is the floor, not a comfortable number. The reference Docker Compose in the project repository runs the web app plus Postgres and Redis, and the current generation adds a supervisor process that launches your task workers as containers, a container registry to hold the images those workers run from, object storage for large payloads, and ClickHouse for run analytics. On a single box that lands at 5 to 7 containers idling around 2 GB before you run a task. The supervisor needs access to the Docker socket to spawn workers, which is the piece to read carefully before putting this on a shared host. If your homelab is a 2 GB VPS, the hosted service is genuinely the cheaper path; if you have a 16 GB box already running Postgres for everything, it slots in fine.

Deploys build images, so you need a registry

Trigger.dev tasks do not run inside your app. npx trigger.dev@latest dev runs them locally against the server for development, and npx trigger.dev@latest deploy builds a container image of your task code and pushes it to the registry the server knows about. Self-hosted, that registry is the one in your compose stack, and the CLI needs to be pointed at your instance with an API URL and a project access token rather than the cloud. This is a one-time setup, but it is the step where most self-host reports go wrong: a registry that is reachable from your laptop but not from the supervisor, or vice versa, gives you a successful deploy and a task that never starts.

Where it beats the alternatives

Temporal is the closest technical relative and is more mature, but its programming model (workflows, activities, determinism rules) costs a week to learn, and its self-host footprint is comparable. Trigger.dev trades some of that generality for an API you can read in an afternoon. Windmill sits between them and is worth a look if your jobs are not all TypeScript.

What the cloud version keeps

The Apache-2.0 code is complete for running tasks, but the hosted product is where the company's attention goes. The free tier at last check covers hobby use, and the paid plans start at about 10 dollars a month, which is less than the electricity cost of a box big enough to self-host it comfortably. Self-hosting gets you data locality, no per-run pricing and no vendor risk, at the cost of being the person who upgrades ClickHouse. The upgrade notes between major versions have been substantial, so pin image tags and read them.

What I'd do

If I were building a product with background work in TypeScript, I would develop against the hosted free tier first and only self-host once the run volume or the data-residency requirement justified a dedicated 4 GB box. When it does, take the repository's compose file as-is, keep Postgres and Redis on their own volumes, put the web app behind Caddy, and treat the registry and supervisor as one unit that lives on the same host. For anything that needs to be maintained by people who do not write code, stop here and install n8n instead; the two tools are not competing for the same user.