n8n vs trigger.dev: When a Workflow Needs Real Code

They solve differently shaped problems

We wrote about choosing between n8n, Make and Zapier previously. That comparison stops exactly where this one starts, because all three are visual builders and the real question here is when none of them is the right shape.

The distinction that matters is whether the work is integration-shaped or code-shaped.

Integration-shaped work is mostly plumbing. A form is submitted, so create a CRM record, notify a channel, add a row, send an email. The logic is thin and the value is in the connections. A visual canvas is genuinely the best representation of that, because the picture is the documentation and a non-developer can look at it and understand what happens.

Code-shaped work has thin plumbing and thick logic. It loops, it branches on conditions that are awkward to draw, it runs long enough that failure mid-way matters, and it needs to be tested before it touches real data. Drawing that on a canvas produces a diagram nobody can read and nobody can test.

Where n8n is the right answer

n8n is the default for most business automation, and that is not a compromise.

It wins on self-hosting, which matters when data cannot leave your infrastructure for regulatory or contractual reasons, and it removes per-task pricing entirely: unlimited executions on hardware you already pay for. For a workflow that fires thousands of times a day, that difference is the whole business case.

It wins on team visibility. A canvas your operations lead can open, follow and edit is worth more than elegance. Automation that only one developer understands becomes a liability the moment that developer is on holiday.

And it wins on breadth. Hundreds of integrations already exist, with authentication handled. Writing that glue yourself is work that produces no differentiated value.

Four signals that a workflow has outgrown the canvas

You do not migrate a whole automation estate. You notice a specific workflow straining, and one of these four signals is usually enough.

Duration. The workflow runs long enough that a timeout or a mid-run failure is a business problem rather than an annoyance. Anything waiting on a slow external system, processing a large batch, or resuming after a restart lands here.

Version control. You need code review, a diff of what changed and why, and the ability to roll back. Visual builders can export JSON, but reviewing a workflow diff as JSON is not code review, it is archaeology.

Testability. You need to run the workflow against test data before it touches production. If your only test environment is production with a flag, this signal is already firing.

Observability. You need to know which step failed, on which input, how many times it retried, and how long each step took. "The workflow errored" is not enough to operate on.

Where trigger.dev takes over

trigger.dev is a framework for writing background jobs in TypeScript, and what it buys is exactly the four things above.

Durable execution is the headline. A job checkpoints its progress, so a restart resumes where it stopped instead of replaying completed steps. For anything long-running or expensive, that is the difference between a retry being safe and a retry being a second charge on a customer's card.

The rest follows from it being code. It lives in your repository, goes through pull requests, gets tested in CI, and produces structured logs per step. Prompt versioning and evaluation harnesses for AI steps are ordinary code concerns rather than things you bolt on.

The cost is honest and worth stating: it is code, so it needs a developer. Your operations lead can no longer open a canvas and see what happens. You trade visibility for durability, which is a good trade for the workflows that need it and a bad one for the workflows that do not.

The comparison, condensed

Running both is the normal answer

The framing that helps most clients is that these are layers, not alternatives.

n8n owns the integration surface: the triggers from forms, CRMs and webhooks, the routing between services, the notifications. It stays visible, and the operations team keeps a live map of the process without reading code.

trigger.dev owns the parts that must not be fragile. When n8n reaches a step that is long-running, expensive, or needs to be tested before it runs for real, it calls a trigger.dev job and waits for a result. The boundary is a single node on the canvas.

That split gives you both properties: the team can still see the process end to end, and the risky twenty percent lives in reviewed, tested, observable code.

How to decide in practice

Ask three questions about the specific workflow, not about your stack.

1. If this fails halfway through, is that expensive? Money, duplicated customer-facing actions, corrupted data. If yes, it needs durable execution.
2. Would I be comfortable if this shipped without review or tests? If no, it needs to live in a repository.
3. Does anyone outside engineering need to understand or change it? If yes, keep the visible parts visible and push only the risky step into code.

Most workflows answer no, yes, yes and stay in n8n. The ones that answer yes to the first question are the ones worth moving, and usually only in part.

If you want that assessment done on your actual processes rather than in the abstract, that is what the audit at the front of a workflow automation engagement is for. We map what you run today before recommending anything, because the tool is the last decision, not the first.