While n8n is amazing for the odd office automation and giving semi-technical people an enormously powerful tool to get things done, it seems it can’t really replace a real backend, and mostly because of the n8n team choices than any technology.
We were trailing it and wanted to essentially switch our entire backend to it - and technically it seemed to be able to do the job, but their licensing turned out to not be a fit.
For a moderately used app we very quickly burned through their “executions” that were allotted by our license - and that’s where we host it ourselves, configuring and paying for the servers, load balancers, key value store and database, with its failovers and backups.
So the license was to use it on top of all that, and even their highest enterprise license was cutting it close, and if you “run out” of these executions, the service just stops working …
And all of that would have been fair if it was hosted, but sounds ludicrous to me for something we self host.
I think it is an incredible piece of tech, but just not suited for a dynamic startup, and once we spent the time to code up the alternative paths for our use cases, it no longer made sense to use n8n at all, as we mostly solved all the problems it was helping us with.
It seems crazy to me that they impose imaginary limits on the self-hosted version, you can have a server that can handle more executions, but the license won't allow it.
People continue to use these limitations. A long time ago when multicore CPUs were new or even systems with multiple CPUs saw vendors charge higher fees to allow their software to run on more than one core/cpu. My first run in with this was transcoding software with the license running ~$5k per core. To them, it was a whole second computer since everything was single threaded, so they felt it was worth twice as much. All it took was for someone else to not charge per core and took away business for that sales model to go the way of the dodo.
I can see an argument of "well it typically bogs down and stops being performant at X, and we don't want to get a bad rep because people abuse it, so we don't allow anything over X", but that should still be negotiable if you can show you have plenty of horsepower.
It's an orchestration tool. Backends are a lot more than just orchestration.
There are alternatives to n8n depending on your stack of what is being orchestrated. Node-red, and others have quietly existed for a very long time, similar to how n8n existed for a good while before being discovered by the AI world.
I guess the bigger question is why use two tools when you can use one? Full disclosure I work at Node-RED/FlowFuse, so take that into consideration, but the point remains - if you need to use both an orchestration tool and a flow management/backend management tool, why not use one solution that does both excellently?
I think that's a critical argument that n8n and others will have to overcome - why should users decide to over-specialise one aspect of their stack when they can do so much more and have so much more control elsewhere?
Facing similar issue with monitoring part of executions. What is your solution if I may as - have you taken smth of the shelf and extended to your needs or did you built from the ground up everything?
Honestly we were looking at hatchet / pickaxe - similar vein of a project but more dev focused, but in the end realised our use cases were not all that complex so just built everything in a bespoke manner.
We used n8n for two things mostly - AI agents and process automation.
For AI we just built own MCP servers, and then the agents are quite easy to use as the major frameworks kinda help you with it. N8N’s AI is kinda just a UI layer for langchain - though we just used google’s adk.
For process automation - well there is so much options it’s not even funny.
You could, but then you start getting into additional costs, controlling how much of your metrics are surfaced vs. kept internal, etc. At that point, why not just go for another solution?
Like you could make a car like a truck, but why not just buy a truck in the first place?
Kudos to the n8n team! Seems like the focus is increasingly shifting to AI.
Question to folks who’ve used n8n extensively, I’m curious, what are your experiences with n8n, and how much does it end up being a web of verbose “visual python” in practice?
I’m very much biased here and have a vested interest, because I’ve been working on a new product not far from this space, but much more oriented at technical users (platform engineers, primarily, see [0] and [1] for a shameless plug, not released yet), but really, I’m curious about what experiences folks have had here, and what your main issues with it were, esp. if you used it in a platform/devops engineering role, or maybe why you decided not to use it.
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
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?
Building close to this space[0] too but starting with low code instead of no code. Still wondering in node-based GUI is the way to go, another alternative is something like Lovable where it is entirely chat based.
what's lame about it? I read the comments specifically for alternative tools. Often times, commenters provide links to other tools and nobody has ever complained...until you came along
This comment got me digging, n8n actually has a pretty good post-open source license[1] - I'm glad to see more successful examples of this sort of licensing in the wild
It's great and all that their business strategy is working out, but anyone looking to use a FOSS solution isn't going to care at all.
This is basically just allowing self-hosting of a third-party's cloud, which is an improvement over traditional SaaS, but shouldn't dilute the FOSS label.
Full disclosure, I'm incredibly biased here as I'm a DevRel at FlowFuse, but there's a reason I joined them instead of n8n. On the surface they're comparable, but I think Node-RED (and FlowFuse) is a better solution for a lot of reasons:
First off, Node-RED handles real-time event data much, much better in my experience. Because of where Node-RED came from, there's much better support for IoT, MQTT, Modbus, OPC UA, edge protocols, etc. n8n is much more limited in this regard, and the fact that the Node-RED and FlowFuse community has literally thousands of custom nodes makes the calculus pretty clear.
I also think that FlowFuse/Node-RED has better integration of AI workloads. In theory n8n is designed around AI, but it treats it the same way OpenAI's AgentKit does - as sort of opaque connections. FlowFuse/Node-RED instead treats it as an actual message payload (both in terms of how you connect to the APIs and how you interact with what's generated), so instead of throwing your request into the void and hoping for the best, you can control every minute part of the flow.
That also makes for much more transparent debugging and visual data flow - the whole idea of these low-code environments is to give you the same control as high-code without the headache. Abstracting that away too much gives you less control, which is sort of the antithesis of this approach.
If you clone the Windmill source from GitHub and build it, that’s AGPL.
If you enable the enterprise feature flag or use the Docker image, the result is source available.
I think it’s fair to call Windmill open source. It’s using the open core model for commercialisation. Just because you publish open source it doesn’t obligate you to make all the code you write open source.
Once you hit product-market fit for a SaaS, engineering becomes a smaller proportion of your spending and you start hiring and spending a lot more on sales and marketing. If you know you can earn more than a dollar for every dollar you spend on customer acquisition, you throw as much money as you can at acquiring customers.
5000 n8n workflows that made me millions. 1 n8n workflow that made me 5k per hour...
It's an okay product I appreciate that it's selfhosted with good documentation but they absolutely destroyed their brand with excessive affiliate marketing and now nothing of substance is left if you search for it anywhere.
When I think of n8n I think of the n8n subreddit of people posting about how their workflow is broken and they lost all their customers and don't know how to make it work and the obvious solution is that if they had written actual software with tests, fallbacks, etc. this wouldn't have happened.
I have written some stuff with n8n and I think it's is better than most no code platforms because it's debuggable. For example, it keeps all the historical executions so you can see what happened when the workflows failed and what all the data going in and out of each component in the system was during the failed run. It also has real detailed error messages instead of just vague "An Error Occurred" popup boxes that don't provide any information. Also, it's different from most nocode platforms in that it is self-hostable and you can easily export and import programs from it and share them with other people.
That subreddit is the new r/dropshipping. I joined to see what fun tooling people were building, and I found it mostly populated with people attempting to setup a "business" with a single feature solution.
I like n8n. It feels a little less rough around the edges for visual coding than something like huggin or nodered. The documentation is good, but finding examples and things like that offsite is impossible.
The documentation leaves a lot to be desired. Especially regarding custom node development. But also on the user side, for example the kaka trigger node has zero info on its doc page.
One thing I don't get fully is people that say "it's easier to write code" - we use n8n for workflow orchestration - a junior developer can put together some nodes to e.g. get data from an API, transform it (by writing code), prepare a CSV, send an email. In about an hour. You then have a workflow that you set to run every night at 2am, and that you can open, understand visually at a glance, modify, and continue running without any other actions required. All self-hosted on a small VM.
Alternative would be writing custom code, deploying it somewhere, setting it to run automatically on schedule somehow, and modifying it and redeploying through a dozen steps every time.
Of course there is docker and cron and deployment scripts - but all of that is not needed with n8n for these kinds of use-cases.
For me, that's the primary value of n8n - nodes themselves are nice-to-have shortcuts, some of the time. Maybe I'm not familiar with tools that make it easy to "just write code" and have everything else (deployment, orchestration etc) covered?
Question for n8n and other orchestration tool users: Why not use an LLM to vibe code the orchestration? Is it still hard to host or not mature enough?
I tried n8n but found it easier and cheaper to have Claude code something and then throw it in docker as API that I could interact with. Tool integrations were also easy to vibe code. I am maybe more technical than the average n8n user? Not sure
We were trailing it and wanted to essentially switch our entire backend to it - and technically it seemed to be able to do the job, but their licensing turned out to not be a fit.
For a moderately used app we very quickly burned through their “executions” that were allotted by our license - and that’s where we host it ourselves, configuring and paying for the servers, load balancers, key value store and database, with its failovers and backups.
So the license was to use it on top of all that, and even their highest enterprise license was cutting it close, and if you “run out” of these executions, the service just stops working …
And all of that would have been fair if it was hosted, but sounds ludicrous to me for something we self host.
I think it is an incredible piece of tech, but just not suited for a dynamic startup, and once we spent the time to code up the alternative paths for our use cases, it no longer made sense to use n8n at all, as we mostly solved all the problems it was helping us with.
I wrote a post on it here: https://news.ycombinator.com/item?id=45558489
There are alternatives to n8n depending on your stack of what is being orchestrated. Node-red, and others have quietly existed for a very long time, similar to how n8n existed for a good while before being discovered by the AI world.
I think that's a critical argument that n8n and others will have to overcome - why should users decide to over-specialise one aspect of their stack when they can do so much more and have so much more control elsewhere?
We used n8n for two things mostly - AI agents and process automation.
For AI we just built own MCP servers, and then the agents are quite easy to use as the major frameworks kinda help you with it. N8N’s AI is kinda just a UI layer for langchain - though we just used google’s adk.
For process automation - well there is so much options it’s not even funny.
Dead Comment
Like you could make a car like a truck, but why not just buy a truck in the first place?
Deleted Comment
https://www.activepieces.com/
They are open core I think (MIT+enterprise features model)
Dead Comment
Question to folks who’ve used n8n extensively, I’m curious, what are your experiences with n8n, and how much does it end up being a web of verbose “visual python” in practice?
I’m very much biased here and have a vested interest, because I’ve been working on a new product not far from this space, but much more oriented at technical users (platform engineers, primarily, see [0] and [1] for a shameless plug, not released yet), but really, I’m curious about what experiences folks have had here, and what your main issues with it were, esp. if you used it in a platform/devops engineering role, or maybe why you decided not to use it.
[0]: https://spacelift.io/flows
[1]: https://www.youtube.com/watch?v=vZHGg1QIAQk
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.
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
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?
[0]: https://github.com/aperoc/toolkami
Deleted Comment
[1]: https://docs.n8n.io/sustainable-use-license/
That's a terrible reimagining, subtlying implying that open-source is old and past it.
It's a pre-open source license. They've not quite made the bar.
This is basically just allowing self-hosting of a third-party's cloud, which is an improvement over traditional SaaS, but shouldn't dilute the FOSS label.
Are these projects comparable?
First off, Node-RED handles real-time event data much, much better in my experience. Because of where Node-RED came from, there's much better support for IoT, MQTT, Modbus, OPC UA, edge protocols, etc. n8n is much more limited in this regard, and the fact that the Node-RED and FlowFuse community has literally thousands of custom nodes makes the calculus pretty clear.
I also think that FlowFuse/Node-RED has better integration of AI workloads. In theory n8n is designed around AI, but it treats it the same way OpenAI's AgentKit does - as sort of opaque connections. FlowFuse/Node-RED instead treats it as an actual message payload (both in terms of how you connect to the APIs and how you interact with what's generated), so instead of throwing your request into the void and hoping for the best, you can control every minute part of the flow.
That also makes for much more transparent debugging and visual data flow - the whole idea of these low-code environments is to give you the same control as high-code without the headache. Abstracting that away too much gives you less control, which is sort of the antithesis of this approach.
Like I said though, SUPER biased here.
https://flows.nodered.org/
https://n8n.io/workflows/
With extra restrictions, n8n is at most "source available".
This is not an argument in favor of n8n.
If you enable the enterprise feature flag or use the Docker image, the result is source available.
I think it’s fair to call Windmill open source. It’s using the open core model for commercialisation. Just because you publish open source it doesn’t obligate you to make all the code you write open source.
Hiring 50 fairly well paid developers is roughly $15M/year, maybe more if one insists on SV compensation which always seem a bit absurd.
$240M total funding is a lot of money. They’ve only been around for about 5 years and probably didn’t start out fully staffed.
So they’re basically covered for the next 10-15 years even if they had zero sales ?
Having 500 employees won’t speed things up and would actually slow down development - so why so much funding?
Or who actually waits that long? The first version of Windows 10 was released about 10 years ago and soon will be EOL.
I feel software investment is like some oil ETFs — there is more investment money than the thing to invest in…
Of course that valuation makes sense if you've seen the insane prices they charge.
Specially if they go the PaaS/SaaS AI route.
For their Business (self-hosted) plan, they have essentially 0 cost per customer.
> The focus for the fresh funding will be on expanding its engineering capabilities and hiring.
https://pitchbook.com/news/articles/ai-agent-startup-n8n-lan...
It's an okay product I appreciate that it's selfhosted with good documentation but they absolutely destroyed their brand with excessive affiliate marketing and now nothing of substance is left if you search for it anywhere.
I like n8n. It feels a little less rough around the edges for visual coding than something like huggin or nodered. The documentation is good, but finding examples and things like that offsite is impossible.
Dead Comment
Deleted Comment
Alternative would be writing custom code, deploying it somewhere, setting it to run automatically on schedule somehow, and modifying it and redeploying through a dozen steps every time.
Of course there is docker and cron and deployment scripts - but all of that is not needed with n8n for these kinds of use-cases.
For me, that's the primary value of n8n - nodes themselves are nice-to-have shortcuts, some of the time. Maybe I'm not familiar with tools that make it easy to "just write code" and have everything else (deployment, orchestration etc) covered?
Dead Comment