n8n: When It Is the Wrong Tool

“Should this be n8n, or should this be code?” gets argued as ideology and answered badly. Engineers say a workflow tool is a toy. The person who built the workflow says it has run for a year without touching it. Both are describing something real and neither is describing the boundary.

The boundary is specific, and it is not complexity. It is whether the correctness of the thing depends on something the canvas stores as geometry, as in-memory data, or as a cursor saved out of band. Below that line a workflow tool is equivalent to code and far faster to change. Above it, you are relying on properties the tool never promised.

Why this exists

Nobody rewrites in month one. The cost of getting this wrong is paid in month nine, with the thing in production, a client depending on it, and no clean seam to cut along.

So answer it by symptom, early, while a rewrite is still a morning’s work rather than a project nobody will fund.

How to use it

Match the symptom, then make the move. These are the ones that recur:

• You are moving large files and hitting memory errors. The default binary data mode keeps binary data in memory. It is configurable — filesystem, S3, Azure, database — but if you never configured it, that is your answer. Change the mode deliberately, or move file handling out entirely.
• Duplicate or skipped records would be unacceptable. A polling trigger keeps a cursor in the workflow’s static data, saved separately from the execution it produced. If the instance crashes between those two saves, items get skipped or processed twice. If you are moving payments or clinical messages, do not ask the tool for exactly-once delivery. Put idempotency in the destination, keyed on something the source guarantees.
• Correctness depends on which branch runs first. Branch order comes from position on the canvas, topmost first. Ordering stored as geometry is ordering a colleague can change by tidying up.
• You cannot say what the tests are. Not “the tests are failing” — you cannot name them at all. That is a signal about the thing’s maturity, and it gets more expensive every month you leave it.
• Nested conditionals past two levels. A Switch whose branches all do nearly the same thing is a function with parameters, drawn.

The inverse matters just as much. Stay in n8n when the value is in the connection rather than the computation, when the logic changes monthly and somebody non-technical needs to see it, and when OAuth against three vendors is the actual work. Rewriting that as a service buys you nothing and costs you the visibility that made it useful.

Where it goes wrong

In a small shop the more common and more expensive error is rewriting too early. A workflow you can open and read on a Tuesday afternoon has real value that shows up in no architecture comparison. Moving it into a repository means a deploy path, somewhere to run it, monitoring, and dependency updates — all of which are now yours forever. Count that before you start.

“It isn’t real engineering” is not a symptom. Neither is a hiring plan, nor a conference talk. If you cannot name which of the failures above you are currently experiencing, you are not ready to move it.

The usual right answer is a hybrid, and people skip straight past it: keep n8n as the trigger, the glue and the visible sequence, and call out to one small service for the part that needs real code. You keep the thing a human can read, and you stop asking the canvas for guarantees it never offered. n8n’s own guidance on breaking workflows into smaller parts is the first step in that direction, and often enough on its own.

Last, be honest that the line moves with who maintains it. I work alone, so a workflow I can see is worth more to me than a service I have to keep alive. A team with an on-call rotation should draw this further toward code than I do — and should say why out loud, rather than inheriting somebody else’s boundary from a blog post.