n8n in my experience using it for 2 years now, and compared to similar solutions as there are many doing quite the same thing: it is just a very good product. It's stable. It has a gazillion integrations out of the box and is architectured as a module system so it's easy to create your own. It is very community centric, with community workflows and also integration modules people kindly publish on GitHub.
Oh, it's open (core) source. And while certain (just a couple of) enterprise features should have been made open to qualify as being called open source, it's very close to that. Most powerful features are open, ready to self host, modify and make your own.
Does it end up driving webs of python partials forming apps. Absolutely. Does it scale ? It does. Do complex flow remain maintainable? As a coder I prefer to maintain a repo of code than visual elements made of snippets. But, the critical advantage is productivity, for simple flows the community intelligence solves everything so you can get an operational set of valuable solutions within hours, even minutes once proficient with the interface. Another factor is, you can deploy pilot flow acting as applications, test them with production data, and make that live with the press of a button once pilot testing is done. With a code project you would need a robust and well polished cicd pipeline to get that.
The limit or cons to me is a logic and compute heavy solution just isn't a fit to run on an n8n platform, scaling n8n just isn't as intuitive as scaling pure application component that do one thing.
An example you may have a cpu heavy node, and a memory heavy node. It makes scaling the whole instance very inefficient. Scaling memory of a dedicated memory intensive application and scaling compute for the compute intensive component simply is far more optimal.
If resource cost is not significant relative to the value of your flows then just scale a self hosted n8n and you only need to digest having to maintain, following your analogy, a "nest of pythons".
Note: n8n sadly only supports python or JavaScript for custom code nodes, would have been nicer had they built a polyglot runtime instead. That's however more than what every other flow platforms let users do.
> Oh, it's open (core) source. And while certain (just a couple of) enterprise features should have been made open to qualify as being called open source, it's very close to that.
It is absolutely not open source.
The "Fair Source" license that n8n invented has two related qualifications that make it not open source:
> You may use or modify the software only for your own internal business purposes or for non-commercial or personal use.
It's not open source if you can't use it professionally or sell work derived from it [ed: comments have correctly called out that this is not the deal, thank you]. There's no chance this license or anything like it is ever going to be an OSI approved open source license. https://opensource.org/licenses
Source Available would be a better descriptor, and with its prevalence in game dev I’m surprised it’s not more commonly used in the broader tech community.
I also find it weird how little use it gets. Possibly a side-effect of true open source having been more popular to the point of source available being historically unknown.
"Internal business purposes" can be professional right? Not saying its an open source license as defined by OSI, just that this license permits the most likely professional use (internal automation).
> It's not open source if you can't use it professionally or sell work derived from it.
Does anyone _really_ use these low/no-code platforms to create products? I was always under the impression that you'd primarily use something like this for "internal business purposes" i.e. little internal utilities that you can't justify spending serious development time on. Which the license lets you do.
This reminds me of a wonderful definition of ownership: You only own something if you can buy and sell it. See: Kindle books/movies "bought" on Apple TV/etc.
As a software engineer I find it cumbersome and frustrating to use. When something doesn't work it can be difficult to see the true cause of the error. That said, those who are slightly less technical like analysts or PMs are able to put together reasonable POC solutions relatively quickly. (Though it remains to be seen how well this holds up when those POCs become business critical)
Further nitpick: Their Python implementation is based on WSAM so libraries that require C compilation won't work.
However if this funding let's them integrate a Claude-Code like tool, they'll have an amazing product.
I've been evaluating n8n as a way to build things quickly for clients, but I do wonder about what happens when they want to turn the automation into a full app. I wish there was a first-party way to export an n8n workflow as a plain Python script or set of scripts.
Have you ever had to migrate a project from n8n to code?
Yes I migrated workflows which I felt should be promoted as critical/production. Also because I wanted to scale that independently. https://applycreatures.com started as product backed by n8n. It enabled rapid backend tweaks to focus on the frontend. Once MVP was completed, it was time to migrate. I had the code in JavaScript so the core logic could simply be moved over, but a lot of boilerplate code had to be written to create a full fledged nodejs API. It confirmed that n8n was a good decision for early, prototyping the solution.
Most of my workflows remained in n8n, those that are unimportant or turned out unnecessary to the application. It saved me days for each, not having to build an app backend and cicd for those.
I defined it as open (core) source. Because that's what it is. Or source available. Both terms are precise.
But what I explained is that contrary to many open core projects, n8n public sources form a (generous) comprehensive solution, aside a couple of features that should have been public sources, the solution stands as a grea, with little to no limits, platform. Unlimited users, no cap on workflows, no cap on number of nodes etc etc.
Also, their licensing is good, you can pay and get the extra features and do what you want, including modifications if I'm not mistaken. That's free software without the free beer aspect, I never claimed it was free software or pure open source.
I'm also all for free software, but this is the sort of solution that doesn't fit well with the open source philosophy , making it rare to see open sourced. That's all.
Now that they raised significant money, the situation will slowly change to prioritize monetization, I guess.
Oh, it's open (core) source. And while certain (just a couple of) enterprise features should have been made open to qualify as being called open source, it's very close to that. Most powerful features are open, ready to self host, modify and make your own.
Does it end up driving webs of python partials forming apps. Absolutely. Does it scale ? It does. Do complex flow remain maintainable? As a coder I prefer to maintain a repo of code than visual elements made of snippets. But, the critical advantage is productivity, for simple flows the community intelligence solves everything so you can get an operational set of valuable solutions within hours, even minutes once proficient with the interface. Another factor is, you can deploy pilot flow acting as applications, test them with production data, and make that live with the press of a button once pilot testing is done. With a code project you would need a robust and well polished cicd pipeline to get that.
The limit or cons to me is a logic and compute heavy solution just isn't a fit to run on an n8n platform, scaling n8n just isn't as intuitive as scaling pure application component that do one thing.
An example you may have a cpu heavy node, and a memory heavy node. It makes scaling the whole instance very inefficient. Scaling memory of a dedicated memory intensive application and scaling compute for the compute intensive component simply is far more optimal.
If resource cost is not significant relative to the value of your flows then just scale a self hosted n8n and you only need to digest having to maintain, following your analogy, a "nest of pythons".
Note: n8n sadly only supports python or JavaScript for custom code nodes, would have been nicer had they built a polyglot runtime instead. That's however more than what every other flow platforms let users do.