n8n vs Trigger.dev: which I ship to clients

The short answer

I prototype in n8n and ship client production workflows in Trigger.dev. Both are solid. They solve different problems. n8n wins on visual whiteboarding and integration library depth. Trigger.dev wins on version control, observability, and what happens the day a client hires their own engineer.

The context nobody else writes about

The Nest Content pipeline I built end-to-end runs on Trigger.dev. Every research pull, every article draft, every publish step is a TypeScript task with retries declared inline and a dashboard I can watch live. Before I wrote it that way, I prototyped chunks of it in n8n, including the part that decides which keyword the system attacks next. n8n got me to a working flow inside a day. It also gave me a flow I would have struggled to hand to anyone else.

Both tools automate things. They don't automate the same things for the same buyers, and the comparison guides I read before writing this one don't really address that.

Two quick data points to ground what follows. As of 20 April 2026, n8n has 184,853 GitHub stars against 14,611 for Trigger.dev. n8n's Cloud Starter tier is $20/month billed annually; Trigger.dev's Hobby tier is $10/month with $10 of usage included. The star count isn't the story. The pricing shape is.

What each one actually is

n8n

n8n is an open-source workflow automation platform with a visual node editor. You drag blocks onto a canvas, connect them, and a run executes left to right. It ships with several hundred integrations, a UI anyone vaguely technical can read, and a self-hosted community edition that is free forever provided you run it yourself.

Revenue model: managed cloud tiers ($20, $50, $800/month on annual billing as of April 2026), plus an enterprise tier for larger companies that want SSO, audit logs, and support.

The value proposition is "Zapier, but open source, and with logic."

Trigger.dev

Trigger.dev is a developer-first background job platform. You write tasks in TypeScript, deploy them to Trigger's infrastructure (or self-host), and the platform handles scheduling, retries, distributed execution, and observability. Their dashboard is the centrepiece: you watch runs live, inspect every step, see durations, inputs, outputs, and exceptions without bolting on extra logging.

Revenue model: usage-based, with a free tier ($5 included monthly), a $10 Hobby tier, and a $50 Pro tier at the time of writing. Compute pricing starts at $0.0000169 per task for the smallest machine size.

The value proposition is "Vercel, but for background jobs instead of web pages."

How I actually use them

Most comparison posts frame n8n vs Trigger.dev as an either/or decision. In practice I use both, on different stages of the same build.

Stage 1: Prototype in n8n. When a client describes a workflow during a scoping call - pull leads from X, enrich with Y, score with Z, push to Slack - I build the first version in n8n while we're still talking about it. The visual feedback loop is fast, and the client can see the data flowing through the canvas on a screen share. It's a whiteboard with live data, and nothing else on the market does that as well.

Stage 2: Ship in Trigger.dev. Once the logic is stable and the client is ready to sign off, I rebuild the same workflow as a TypeScript task in Trigger.dev. The rewrite takes a few hours at most for workflows that took an afternoon in n8n. The gain is everything downstream: code-reviewed diffs in git, retry policies that match the failure modes we actually saw in testing, and a dashboard the client's ops team can reference without fear of breaking anything.

The Nest Content pipeline I built end-to-end (143 indexed pages, ~70,000 monthly impressions at peak, zero manual writing) runs entirely on Trigger.dev in production. Every research pull, every article draft, every publish step is a task with its own retry policy and observable run history. I couldn't have scaled it in n8n. I also couldn't have prototyped it fast enough without something like n8n sitting alongside.

Where n8n wins

Visual thinking for non-engineers

If the person owning the automation isn't an engineer - an ops manager, a marketing lead, a founder with Zapier fluency and no more - n8n gives them a canvas they can read, audit, and sometimes modify. Trigger.dev gives them a dashboard they can watch but not change.

For an agency owner who wants to see what an automation is doing, the n8n view is more intuitive by a wide margin.

Integration library depth

n8n ships with a long-established catalogue of pre-built nodes for Slack, HubSpot, Notion, Airtable, Google Workspace, every major database, and the full collection of AI model providers. If I need to pipe something out of Freshdesk into Linear with a Claude enrichment step, the shortest path in n8n is three nodes and a prompt.

Trigger.dev is an SDK, not a directory. You write the integration yourself using the vendor's SDK. Usually that's a few lines of TypeScript, but "a few lines" is still more than "drag two nodes."

Self-hosting for zero dollars

If you run your own infrastructure, the n8n community edition is free. Spin up a Docker container on any VPS, hook up a Postgres instance, and you can run unbounded workflows for the cost of the compute underneath. I've self-hosted n8n on a £6/month Hetzner box that's been up for 14 months and cleared six-figure run counts.

Trigger.dev is open-source too, but self-hosting it is a harder ask: more moving parts, separate services for the dashboard, workers, and scheduler. Feasible, not trivial.

Where Trigger.dev wins

Version control and diffs

n8n workflows are JSON blobs. You can export and import them, but reading a diff against a changed n8n JSON is painful, and resolving a merge conflict is worse. In Trigger.dev, every workflow is a TypeScript file. You diff it in your pull request. You comment on specific lines. You roll back with git revert.

For a client who will eventually hire their first engineer, this is the line that matters. The day they bring someone on, that engineer sees a git repository full of tasks they can read, understand, and extend. They don't see a screenshot of a canvas.

Observability that doesn't need bolting on

Trigger.dev's run viewer shows the full execution of a task: every subtask, every retry, every input and output, with wall-clock timing. If a run failed at step four, you see step four highlighted red, you see the thrown exception, and you see the inputs that produced it.

n8n has an execution history, and it's decent for linear workflows. Once you've got branches, loops, and sub-workflows, the UI for debugging starts to strain. I've spent more time than I want to admit clicking through n8n executions trying to work out which branch actually ran.

Real retry policies

Trigger.dev lets you declare retry policy per task: maximum attempts, backoff strategy, which errors trigger a retry versus a permanent failure. You can tell a Claude API call to retry three times on rate limits but give up immediately on a schema error. That distinction ships a lot of reliability.

n8n has retry logic, but it's set at the node level with fewer dials. Production-grade retry logic, the kind where you've tuned the back-off to the third-party API's rate limiter, is friction in n8n. In Trigger.dev it's the default way to write a task.

Client handoff

The most underrated dimension. When the engagement ends, what do you leave behind?

With n8n, you leave the client a running instance and a canvas. If they don't have someone to own it, they don't really own it. Rule changes require either calling you back or hiring someone to learn n8n first.

With Trigger.dev, you leave a git repository, a CI pipeline, and a dashboard login. Any developer who joins can read the code, extend it, ship a new version. That's what "you own the system" actually looks like.

Cost reality at three usage levels

Pricing below is listed USD because both vendors publish in USD. UK buyers should add a rough 20% for exchange and local bank fees.

Low usage: a few scheduled jobs, one ingest per hour

• n8n Cloud Starter: $20/month. Fine.
• Trigger.dev Free tier: $0/month with $5 of included compute. Usually enough.
• Self-hosted n8n: £6-10/month for the VPS. Effectively free if you already run infrastructure.

Verdict: Trigger.dev free tier wins on sticker price. n8n self-hosted wins if you have the infrastructure anyway.

Medium usage: a production pipeline with enrichment, scoring, and a few thousand daily operations

• n8n Cloud Pro: $50/month.
• Trigger.dev Pro: $50/month with $50 included usage. Likely enough unless you're running heavy LLM inference per task.
• Self-hosted n8n: £15-30/month on a bigger VPS once the database grows.

Verdict: prices converge. The decision is made on the non-price axes (version control, observability, client ownership), not the bill.

Heavy usage: LLM-driven pipeline running every few minutes with fan-out

• n8n Cloud Business: $800/month annual, and you're probably bumping into workflow execution limits anyway.
• Trigger.dev Pro with usage spend: still $50/month subscription, but compute adds up fast. Budget £200-400/month depending on model size and execution time.
• Self-hosted n8n: works, but you're also paying a dev-ops tax at this scale.

Verdict: Trigger.dev's usage-based model wins on economics if you're running more compute than average. n8n's per-workflow limits start to hurt at this scale.

None of this is unique insight; it's just what the bills actually look like. Both vendors publish usage calculators on their pricing pages and both are honest about them.

What I'd change about both

Neither tool is finished, and being clear about the gaps is part of recommending them honestly.

What I'd change about n8n:

Native git integration is the missing piece. JSON exports work, but they're a band-aid for a problem version control solved 20 years ago. If n8n shipped a first-class git workflow (branch a workflow, diff it, merge with proper conflict resolution), the version-control argument for Trigger.dev shrinks by half overnight.

Sub-workflow debugging gets painful fast. Once a workflow calls another workflow that calls a third, the click-through to find which leaf actually ran is slower than reading a stack trace. A flat run-tree view would close this gap.

The AI integration story is bolt-on. Every comparable platform is racing to ship native LLM primitives (prompt versioning, eval harnesses, structured output validators) and n8n is more "wire up an HTTP node to an API" than "first-class AI building blocks." That'll change, but it hasn't yet.

What I'd change about Trigger.dev:

A Python SDK would bring the entire data-team adjacent market into play. TypeScript-only is a defensible focus for a small team, but it's also a wall in front of every analyst, ML engineer, and Django shop that wants in.

The dashboard is brilliant for engineers and intimidating for the ops person who just wants to see what ran last night. A simplified read-only view, the kind a non-engineer client could be handed without a tour, would meaningfully change the handoff story.

Compute pricing is honest but the calculator could be clearer at the £200+/month level. The current presentation makes it easy to underestimate spend on heavy LLM tasks until the first invoice lands.

The meta-question: when does a solo operator reach for either?

I use Trigger.dev as the default for every client build at Laires Labs because the system gets handed over, and handover is the whole product. Whether it's a PPC automation pipeline for an agency or a BD research workflow for a recruitment firm, the deliverable is meant to outlast the engagement. A canvas doesn't outlast an engagement. A git repository does.

<!-- TODO wave-link: once optmyzr-alternative-for-small-ppc-teams publishes, add cross-cluster link per blog-pillars.md -->

I use n8n when I'm scoping, prototyping, or building something internal that only I'll ever touch. The MVP for most of my internal tools (SERP checks, lead enrichment drafts, research dumps) started as an n8n canvas and either stayed there if I'll never hand it off, or got rewritten in Trigger.dev when it mattered.

The comparison frame I'd encourage anyone thinking about this to use isn't "which tool is better." It's "which tool survives the handoff I'm going to have to make in 18 months." The day you hire your first engineer, or change agencies, or decide to take the system in-house, the tool that survives is the one in version control.

Want someone to build it for you?

If you're evaluating this comparison because you're weighing whether to build an automation in-house or have someone build it for you and hand it over, that's what Laires Labs does. I build production workflows, in code, version-controlled, with the dashboard login handed to you on day one. No seats, no vendor lock-in, no SaaS tax.

Book a 20-minute walkthrough if you want to scope something concrete.