Your honest thoughts on n8n from an experienced dev perspective?

Posted by tecken@reddit | ExperiencedDevs | View on Reddit | 23 comments

I've been self-hosting n8n for a while now (no experience with the cloud/enterprise tiers), and I'm starting to question whether it's viable as a long-term part of a mature development stack. I want to get some input from others, because lately it feels like we're just victims of automation FOMO.

A few of my pain points:

Doesn’t play well with version control. Since workflows are stored in SQLite by default, there’s no native way to track changes or use git meaningfully.
No global code search. Makes refactoring difficult. If you’re using expressions in a lot of nodes, good luck finding where you defined that variable or referenced a particular endpoint.
DRY and logic separation? Not really. Everything lives in a visually monolithic blob. Reuse and modularity is hard.
Credentials management is limited. Environment variables help, but actual credential reuse and secrets management (like parameterizing auth across workflows) seems locked behind enterprise. Maybe I'm missing something?
Debugging can be pretty rough. You get a single execution trace per run, but no real step-by-step breakpointing, rollback, or state introspection. You mostly end up adding manual log nodes everywhere or just jumping from one node to the next playing detective.

To be fair, there are some nice aspects:

Good for small tasks or proof-of-concepts. Easy to wire up a workflow to try out something.
Tons of integrations and predefined nodes out of the box.
Self-hosting works pretty well. Docker setup is painless.

But as a dev who's used to thinking in terms of maintainable codebases, automated testing, and refactoring… I’m starting to feel like n8n is more of a prototyping tool than something I’d trust for production-scale business logic.

Is anyone using n8n at scale in a real engineering org? Are there ways around these limitations I'm not seeing?

[-]

memo_mar@reddit

In 10yrs as an engineer I've yet to meet an engineer that likes these automation platforms. Not because they are bad but because it's hard to integrate them properly, their heavy reliance on webhooks, and the inability to reason and optimize your code when using them in a stack (this also propagates to your ability to test, mock, stub, etc.)

But integrating with a lot of 3rd party APIs is also a much harder problem than many developers like to admit. Getting observability, rate limit normalization, credit balances, provider downtime, changes, etc. right is hard. Really hard actually. Not implementing this yourself is an absolute win. But I'd look at tools like pipe0 for that. There you get automation that lives in your code as simple HTTP requests.

PSBigBig_OneStarDao@reddit

Yeah, these limitations line up with some well-known RAG/automation failure modes — especially debugging as a black box and orchestration deadlocks when you scale beyond toy workflows. Most devs hit the same wall eventually.

We’ve been mapping these patterns systematically. If you want the full index, let me know — it might save you some trial and error.

Repulsive-Hurry8172@reddit

We do not use n8n, but Boomi. We have a dedicated Boomi team that standardizes the workflow for us, we copy those template workflows and modify just one part of the node that we are allowed to. Anyone outside their team is just a users, be they devs or business

Workflow is reviewed, manually. They even have naming standards for it. Company deployment rules apply. Their standards apply InfoSec rules too, so we cannot just decide the structure of the endpoint URLs. Or modify other nodes.

Boomi has its "version control" where it remembers the xml workflow versions previously saved, and one can revert to a previous component / workflow version.

The issue we have with Boomi is the very manual process involved in testing it, even when it's just one node being modified. Quite similar to your n8n criticism.

We do not trust it at all for production processes that have tons of logic due to how hard it is to test. We only use it to connect 2-3 services from various isolated department APIs to make it seem like they function as one. Very very simple workflows.

temporal-tom@reddit

My team at a previous company used Boomi and it was a headache. It worked, but was unreliable and required a lot of babysitting.

monty9213@reddit

I was going to try something like inngest as a more code oriented version of something similar to n8n

bluetrust@reddit

I just came off a project that used inngest for background jobs and I would not use it again. There's limitations like each step can only pass 1MB of data to the next step, steps can only execute for a certain number of seconds, etc.

If I were to do it again, I'd have at least tried other tools first. On my list, for example, was trigger.dev.

It's weird looking at the Inngest homepage and seeing them now positioning themselves as the ai agent orchestration tool to rule them all. It doesn't have anything to do with agents, it's just a queue scheduler that when you post an event it calls a http endpoint it opens on your app. And steps are just further events with a cute name.

jedberg@reddit

Have you considered DBOS? A little more robust than Trigger but without all the limits you mentioned.

virtuzz@reddit

A few things here:

The step limit is 4MB (link)
Each step has a 2h timeout (link)

Not to be disingenuous... step functions do have limits, though this comment is a little off base with the limitations. For example, if you're messing around with > 4MB blobs you should probably be doing something on a blob store. And if code in a single step runs for longer than 2 hours, something is likely off.

Did you take a look at those limitations? What were you building?

It sounds like you need a much more robust ecosystem, something like DBOS Transact, that gives you the ability to define all your workflows in code (allowing you to track all the changes in source control) and then giving you all the observability you need for proper monitoring (such as traces per-step).

jscheel@reddit

I’m actually currently considering moving our entire pipeline from dagster to dbos. The simplicity of dbos is just so nice.

That’s fantastic, I’m glad you like it! If you need any help you can join our Discord or ping me here!

Thanks! I’m in the discord already, I’ll be sure to take advantage :)

tecken@reddit (OP)

Thanks for the suggestion, I might check it out. I take it that your suggestion is not to use N8N?

n8n is really designed for non-developers. For example my friend in HR who has no engineering background at all is using n8n and learned it in a day.

For the kind of control and observability you want, you really need a more robust platform.

dzofred@reddit

Really hard to figure out which of these types of posts are genuine and which are ads

yea I get it might seem like that, and I'm also really suspicious towards all content nowadays. I used an llm to make my draft better but i also edited it afterwards to remove parts that were not my own thoughts. At least im not trying to draw you anywhere..

Automate the step with n8n