Didn't their change their licensing or something and now folks are leaving? I've seen a few ex-N8n'ers coming over to the Node-RED forum, hence the question.
Yet more evidence that venture capital is basically incompatible with open source software. It's just a matter of time before any VC-backed open source company betrays its users.
n8n was never open source. They started out using Apache with a non-free clause added, but they called themselves open-source incorrectly. Then when this became more widely known, they stopped calling themselves open-source.
Why is it okay to just accept that the hyperscalers are 100% closed, but the minute a smaller player tries to play "open-ish" with "fair source" we crucify them?
Fair source is amazing. You get the code. You can modify the code. You can redistribute the code. You just can't take their business from them and compete with them head-to-head with their product. You can reformulate it into something else, but you can't take their labor and cut their knees off with it. You have literally every other freedom.
Why in the hell are so many people against that?
Fair source is sustainable and equitable. You get everything except for that one little right with which you could compete with them.
Everyone gushes over Obsidian - that's not even "source available" or "fair source". It's completely closed.
I bet if Obsidian went "fair source", and you could download the code and compile it yourself, there would be hundreds of voices crawling out of the woodwork to call them the devil for not being pure OSI-approved open. How dare they keep one little freedom to themselves for all the hard work they've done?
I'm half convinced the anti-"fair source" voices are deep industry folks who want big tech to own the OSI definition. Who can use it strategically as they sit atop hundreds of billions of dollars in cash flows. Open source to the FAANGMAGMA Gods is just a way of outsourcing labor and dangling trinkets in front of underpaid labor.
n8n isn't doing a "VC rug pull." They're trying to be sustainable. The only thing that's been "pulled" is the wool over the eyes of every engineer satisfied with FAANG OSI-approved serfdom. Some of the pieces are "open" all right, but they own pretty much everything the sunlight touches.
If n8n can't build a business then it just becomes some side project hobby. What exactly do we think every other company is doing?
Please be more pragmatic and realize that "fair source" is sustainable. It rewards the innovators and you get almost everything for free. You just can't shoot them with their own gun.
Do you not want the ability to download the source and potentially tweak the software? To have a copy you can hold onto forever? To be able to analyze it for telemetry. To be able to potentially submit patches (if you're feeling generous)?
Don't you want them to make money? Rather than beg for Github donation scraps?
Be especially mindful if you're typing a retort on a Macbook Pro or iPhone and deploying software to GKE or AWS.
I care that software I depend upon survives long term. In consequence, I care to some extent that the principal company or organization building that software also survives... But that finite concern is balanced against the simultaneous concern that the software itself can survive the organization's potential dissolution. I don't want to have to make a sudden, stressful, expensive migration because corporate buy-outs, bankruptcies, or mergers result in rug-pulls for software I use.
"Fair" source does absolutely nothing to allievate those concerns. The four software freedoms do.
It is true that for a quarter century software developers have naively licensed their projects under MIT and BSD style permissive licenses, and have then felt robbed when big companies come in and eat their lunch. Except it was never their lunch because they didn't actually use licenses that would have asserted their rights to that lunch.
Thankfully, that naivete is finally, slowly dying but, rather than use robust solutions that have been around for decades (e.g. GPL-or-AGPL/proprietary dual license), some developers have invented a new, largely untested concept and named it by dressing up their own sour grapes and spite as "fairness".
"Fair" source software is a non-solution in search of a problem.
Free software and strong copyleft licenses already exist. Dual-licensing already exists. Viable, profitable, healthy, ethical companies built on these strategies already exist.
I used to think Stallman was a crank and a fundamentalist, and he absolutely is, and thank goodness for that. I now think "open-source" is exactly as diluted as free software advocates initially pointed out, and the emergence of "fair" source is part of the damage it has done.
Authors using Fair want to share their code while getting protections for themselves. Strong copyleft doesn't care about authors and is all about protecting the end users.
So Fair fullfills an actual need or desire not covered elsewhere, thus is not a non-solution.
It might be not the appropriate or the best solution to solve the exact concerns of people using it, that's debatable and a different topic, akin to using the wrong tool for the job. Strong copyleft is the wrong tool, too; obviously competitors can just deploy without modifications and offer it as a service.
> Authors using Fair want to share their code while getting protections for themselves. Strong copyleft doesn't care about authors and is all about protecting the end users.
This is a one-sided assertion of fairness, and therefore an abuse of the concept. Free software offers the same rights to both authors and users. That is fairness.
If you want to reserve rights to yourself that are withheld from end-users, that's fine. Arguably even still within a broader conceptual realm of fairness. But naming your personally preferred arrangement of rights "fair" and in so doing implying most or all other arrangements are unfair is just plain arrogant.
Strong copyleft cares equally about authors and end-users. It doesn't disregard authors. Some authors just want to co-opt the general notion of fairness to mean their own licensing preferences.
You and sfRattan rightfully pointing to a disease (large cloud providers using true free software to make money without contributing back). But "fair source" cure is a new, unproven drug with serious side effects, all while ignoring the established, effective vaccine (strong copyleft GPL/AGPL and dual-licensing), that has been available for decades. The rise of "fair source" is both as sign of "market panic" and just "marketing". It does not seem to be necessary or good evolution for software freedom.
That was HIGHLY abstract... So much so that I am not sure it maps onto reality, but I at least think this is a valid concern.
(A)GPL + Dual licensing is totally insufficient to fullfill the needs, or at the very least the wants, of people using things like "Fair source" licenses (regardless of the naming): to share their code as a sign of goodwill, without that becoming a risk for their survival.
Amazon offers lots of AGPL software, and they fully respect the license in all cases. Ultimately the GPL is about protecting users' rights at the expense of developers' rights. So as long as AWS can offer a better/cheaper managed version of a software service, while still giving the users all details on how to run the same service if they chose to, then the AGPL is completely achieving its aims, even if the original company goes out of business.
> Ultimately the GPL is about protecting users' rights at the expense of developers' rights.
No. The GPL is about giving developers and users the same rights. Some developers want more rights than users, and engage in special pleading to call that "fairness".
> So as long as AWS can offer a better/cheaper managed version of a software service, while still giving the users all details on how to run the same service if they chose to, then the AGPL is completely achieving its aims, even if the original company goes out of business.
The truth many developers don't want to face is that, if you write a program or tool that can be easily deployed by the behemoths of tech on infrastructure and at scale you cannot match, then you do not have a licensing problem... You have an architecture problem.
A company big enough to take your code and deploy it at overmatched scale and efficiency is also big enough to study your publicly accessible code, however it is licensed, and write new code that achieves the same outcome, maybe even implements nearly the same API, and then deploy that at scale. Actually competing with them involves pursuing fundamentally different architectures and value propositions which they cannot imitate, not writing some new license and trying to pitch it to customers/clients as "fair".
The above reverse engineering and reimplementation already happen in the other direction (e.g. Docker vs. Podman). There's no reason to think a motivated behemoth couldn't do exactly the same to your "fair" source software. On the other hand, Google is constitutionally unable to ever make or deploy at scale something like, for example, Ente Photos, because Google desparately wants all the photos people upload to be legible to Google forever and for whatever new purposes Google's executives might dream up in the future.
> But "fair source" cure is a new, unproven drug with serious side effects, all while ignoring the established, effective vaccine (strong copyleft GPL/AGPL and dual-licensing)
Can you explain this a bit more? I don't understand how this is true.
AFAIK AGPL only prevents someone from modifying your AGPL codebase without sharing that in turn, but if they're content to offer exactly the service you're offering without modification it's not an issue.
See for example Grafana, which is distributed under the AGPL but still has to handle competition from AWS and Azure that have managed Grafana offerings.
> I care that software I depend upon survives long term.
> "Fair" source does absolutely nothing to allievate those concerns.
Of course it does !
Git clone, problem solved.
I'm all in favor of free software, but it sounds a bit disingenuous to pretend that the GPL or even, to a lesser extent, the Affero variant, are providing a safe haven for sustainable software. The reality is, sadly, that free software depends on the good will of very few idealistic people who manage to somehow make a living while spending a lot of time on working for free ; and i must know since I've been lucky to be able to do this most of my life. This is no guaranteed survival or innovation.
While I believe it's very useful to remind users of the freedom they should ask for, I don't think it's useful to oppose free software with fair source, exactly like in the past it was important to remind users of the differences between free software and open source, yet it was counter productive to oppose them.
What a myopic assumption. Availability of source code doesn't solve the legal problems that can arise in the wake corporate restructuring, as new owners work to impede forking and continuing a project outside their control.
Continuing a project in the wake of total organizational failure or capture means setting up legal entities to replace the broken/subverted ones. That's a problem separate from "is the code out there on the Internet for me to download?"
In comparison to the GPL and AGPL, "fair" source licenses are at best hastily drawn. They certainly do not have decades of accrued favorable legal precedent. They are often short and ambiguous because their authors have not imagined half the use cases they might potentially forbid in the name of "fairness". All these qualities are miasmal to long term project stability.
In practice, what matters is that indeed the code is available in a form that makes it modifiable and that machines are available to run it on. Oracle and its hordes of malignant lawyers tried, and almost succeeded, to make this illegal with Java but thanksfully failed.
Why would I need to set up "legal entities" to enjoy my freedom as a user of open source software, unless I'm trying to start a competing business? It's unclear to me what you have in mind. Please explain like I'm a myopic person.
The people promoting "fair" source are specifically doing so to set up legal entities---companies---in order to run a business. That's fine, but it means users of their software should include the potential endgames of those legal entities in their assessment of the software's long term viability. That frame was implicit in my original point.
Any sufficiently large and complex piece of software (free, nonfree, or proprietary) will eventually need some kind of inter-human organization and governance. It won't matter for a small program with complexity that can be managed inside the head of one person but, again, "fair" source as advocated by its own proponents is about software of sufficient complexity to justify legal entities owning, stewarding, guiding, and managing it.
And, IIRC, Oracle and its lawyers, when trying to digest Sun Microsystems, choked on the GPL specifically at least twice: with both MySQL and OpenOffice. The GPL's well thought out protections enabled independent institutions to form around successor forks to those projects. Would the same have been possible with a relatively new, less well thought out "fair" source license? I don't think so.
I don't know what exemple you have in mind, but we were discussing n8n, redis, elastic search... Probably you have much more complex projects in mind?
If I go tu use, say, redis, in a way that the license permit, I don't give a single dime about the legal entity behind it. I just `apt-get install redis`. If I want to modify it for my need, I can `apt-get source redis`. When the next version of redis comes with a more restrictive license, or if features are removed, I just stick to a previous one. Maybe I fork it myself if it's really important for me. Probably, we will be many doing so, we will regroup, share our modifications and improvements. I've experienced this kind of colaborative maintenance of some dead project a couple of times in the past, and all te governance that was ever needed was a mailing list.
Now, sure, some project are more complicated. If, god forbid, postgresql or gcc were to disapear I would not trust myself, or any single individual, to maintain a private fork for long withough the quality deteriorating. But again, people would regroup, cooperate, and we will be able to figure it out.
Compare this with proprietary software, were you truly have no recourse. I've seen wonderful pieces of software in the past, that I loved an used daily, disaprear entirely because the company that produced it went belly up, leaving no alternative than to desperately run the old versions on an emulator still years after because nobody ever managed to redo something as good. And now they are gone, for good, with few people ever remembering them.
So, these are the exemples I have in mind, this is why I don't understand how one could equate fair-source with proprietary -- assuming that the restrictions tainting the "fair" software just prevent the user from competing with the software producer. The user has a ton of power with fair source compared to proprietary.
> When the next version of redis comes with a more restrictive license, or if features are removed, I just stick to a previous one. Maybe I fork it myself if it's really important for me. Probably, we will be many doing so, we will regroup, share our modifications and improvements. I've experienced this kind of colaborative maintenance of some dead project a couple of times in the past, and all te governance that was ever needed was a mailing list.
This situation is a one kind of sudden, unplanned migration. You seem to assess it as less stressful than I would. I'd also be concerned about security generally, duplication of effort to maintain the private fork, and potential retaliation if total secrecy isn't kept by the fork's maintainers.
Your reasoning makes sense for choosing software to use as an individual, but not when choosing software as an organization or when choosing software to integrate into software you distribute for others to use.
Your reasoning also makes sense for maintaining software that has a relaxed threat model (i.e. typically runs or can be made to run in isolation from any network). But the examples you pick (n8n, redis, elastic search) are most often used on perpetually networked computers where security a larger concern and I don't know that I'd trust a private, ad hoc group to keep a secret fork (in potential violation of a "fair" source license) up to snuff.
Oh I see. Sure I trust individual maintainers at least as much as large organisations. Part of my first gig included running debian potato's postgresql on a PC with an oracle sticker on it...
Are you me? That was so scarily close to how I think about this that I could have thought I wrote it myself. Except you know a more about licenses :P
Well written. Thanks.
Edit: I would also add that, based on the specific software/business, the problem with "rug-pulling," as described by another user here, is a real thing. I think that the reason Obsidian doesn't get hate, while being closed source, is that they are at least predictable and honest about their strategy. Their pricing is fair, and development and business plans are openly communicated. It's silly to be angry at a firm for wanting to be closed source, but if they start out pretending to be fully open source and community-motivated, while receiving lots of coding contributions, then suddenly do a rug-pull by removing features from the community edition and paywalling all important features, that is something a lot of us are going to be annoyed by.
> It's silly to be angry at a firm for wanting to be closed source, but if they start out pretending to be fully open source and community-motivated, while receiving lots of coding contributions, then suddenly do a rug-pull by removing features from the community edition and paywalling all important features, that is something a lot of us are going to be annoyed by.
Indeed, and that is why assessing the long term viability of an open-source or free software project means looking at multiple variables. This thread has mostly been about licenses, but there's also literal distribution of ownership... Both ownership of copyright and of corporation.
Is the code's copyright owned by the company and does the company only accept contributions with a contributor license agreement that transfers copyright to itself? Potential red flag. They're keeping the door open for an attempt to rug-pull, but they also might just be trying to do business via dual licensing.
Is the code's copyright owned by too many people to ever feasibly relicense? Green flag, as long as a healthy foundation exists to keep things on track (e.g. Blender Foundation or The Document Foundation).
Is the company publicly traded or has it accepted large amounts of investment? Red flag. Those investors will demand a rug-pull the moment the lines on their sacred monthly and quarterly graphs stop going up.
Is the company closely held by a few people? Potential green flag, depending on the people.
I don't know/care about "fair source," but the "open source" label in particular has ALWAYS had a well-known and specific meaning in the software world. Attaching it to a proprietary product for the marketing and social media good feels is actively deceitful, no matter if the company is USA trillion-dollar Big Tech or a single developer from a marginalized demographic in a developing country.
Software authors have the right to choose whatever license they wish for the project/product, just don't try to lie to users about what it really is.
The person I was replying to seemed to be under the impression that n8n used to be open source and now is not. This is not the case, so I pointed that out.
Did you have anything to say about my actual comment, or are you just attaching your rant to a random part of the thread?
No, what I linked to does not show that they used to be open source. It shows that they used to call themselves open source, despite never having been so.
this is a solid argument against the open-source purists that I've never heard before and really appreciate. Many people would like to make money on the things they spend their time building. Some percentage of those people also love FOSS. Fair source is the middle ground where they can share their work, open it up for criticism, issues, and fixes, but ensure that their business is secure. It's a solid middle ground that shouldn't be demonized just because it isn't open source.
I think because providing commercial support for such a software is not allowed by the license, there is a strong vendor lock-in. That‘s a big drawback for users.
> Why is it okay to just accept that the hyperscalers are 100% closed, but the minute a smaller player tries to play "open-ish" with "fair source" we crucify them?
besides morale, from pure business point of view, hyperscalers will likely last, so that's Ok to rely on them, small OSS projects can be supported/modified by community or business itself, but when some small closed source service is gone, it is compete shutdown, you need to migrate to something else in a very big hurry.
that list is catchy, but if you dig into details, there are many caveats, for example many product were not killed, but replaced with low friction, for example hangout, many products were created at period of time when there was that google labs which launched many strange low quality products which never gained traction.
If you check some core business products (ads, cloud), google usually provides reasonable deprecation timeframe (years).
True that google never depleted us from messaging apps; at some point they had 3 different in operation, with contradictory statements about which one was made obsolete by some other.
Which also illustrate that a stable business does not imply a stable product.
> Which also illustrate that a stable business does not imply a stable product.
there is no absolutely stable product, some weird stuff can happen to everything, its question of probabilities, what the chance that some underfunded startup with negative cash flow will shut down some product, and what is the chance that google will shut down AdWords API?
What do people think about windmill.dev for such workloads? I've found their community tier quite generous and ability to script, access control, make frontends, approval flows quite helpful
I was in an org that used windmill. We eventually got off it mostly because the model encourages end users to install arbitrary python packages at runtime from the internet. That might be acceptable for some use cases but not ours
What makes it feel harder to you for non-technical users? I'm a huge fan - it's what brought me to them to do DevRel stuff - so I'm really invested in making sure that the onboarding/use pathway is really clean and well laid-out.
+1 for Node-RED. If we've learned anything from elasticsearch/redis/bitnami/and dozens of others, it should be "don't build important things on code that isn't enshittification-resistant"
Those guys did all the work and AWS and Google get to collect a cool hundred million each quarter for doing next to nothing. And the original authors can't compete with that.
Are we all gonna go sign up to "Enterprise Redis Cloud" to support them? I don't think so. They have nothing left. They got picked dry.
If they're preserved a "no managed offerings" freedom for themselves, they could collect a few hundred million from each hyperscaler each quarter and put that directly into product. And their engineers would be extra nicely compensated.
But that's not how this story plays out. Big tech just takes things and finds out how to monetize them in ways they don't have to give back.
And we've been trained (by big tech?) to yell at the little guys that try to carve out a space for themselves.
Both are billion dollar companies, we as individuals have nothing in common with them. Enshittification happens due to market conditions that apply to small and large companies alike. Redis and elasticsearch aren't underdogs fighting for the little guy, they are just a smaller scale version of the same shit.
I'd rather have a software commons and have tech be owned by the workers and not soul-sucking corporations, no matter the size.
It definitely can! Full disclosure, I'm a DevRel at FlowFuse, so I'm definitely biased here - but there's quite a lot of support for AI workflows, from lightweight automation to fairly complex pipelines.
For example, I'm currently building a flow that connects device monitoring data to a central reporting structure, compares the incoming values against internal spec docs, and uses OpenAI to summarise overall operational status and any drift/out-of-spec issues. The summaries (along with the raw JSON objects) are then sent over MQTT for multi-site compliance and operations. Once you map it out, it's surprisingly straightforward to build.
What makes Node-RED and FlowFuse stand out on this particular use case IMO is that AI flows get treated just like any other message payload. That means your AI output becomes a first-class data object in the system - you can remix, transform, mutate, or extract from it the same way you would any other JSON payload, making it pretty portable and easy to integrate.
Node-Red is probably a more hands on approach, than n8n, as someone who have 6-7 years of experience in node-red i find n8n really complicated for some reason.
A lot of windows and configurations. Started with node-red and quickly built great skills in backend development.
I would recommend Node-RED but that's a lot more work than a Zapier or N8n but you can do more with it - Node-RED abstraction level is closer to a programming language than a SaaS combinatorial tool.
Depends on what you want to achieve and how much effort you want to apply.
The other licensing shoe is going to drop.
And when it does, it will be same as always. Important features will be cut of from “community” edition, like admin for minio, and pricing will be predatory for full product, like Taipy. Seriously, screw
Taipy. Got quoted 200k for an open license if I wanted to self host it, with no limit on number users.
I got hit by the Minio admin change in the console when I upgraded my installation recently, and I found https://github.com/huncrys/minio-console which adds it all back in. It works as expected so far.
I find this kind of rug pull behavior so hostile I will be looking to replace Minio as soon as possible in my homelab. To be clear, I would pay for a license if the prices weren't impossible to afford as an invidual who uses Minio for non-business reasons.
Rug-pull is a good description of how I feel also.
And the most annoying thing for me is that I, like you, actually WOULD be happy to pay a REASONABLE price. But all the patterns nowadays are bi-modal. Stripped-down community edition to get open-source and community credit (and hopefully free coding contributions) on one end.And on the other end; enterprise pricing, with per-user or other complex pricing rules and restrictions. And only after "Let's talk" and "Contact sales" waste of time.
What about a reasonable, low recurring fee with no limits on what I can do with it if I self-host? Or a modest one time price for one version of the software? It doesn't cost the creator any more whether I have 2 users or 200 if I self-host.
I used to disagree a lot with Richard Stallman, but now when I ask AI to help search for software alternatives, I always specify "Only TRUE FOSS alternatives, with no enterprise option or paywalled features." Not because I don't want to pay a fair price, but to avoid being flogged AND the unnecessary complexity of setting up a damn equation to figure out how much it will cost.
When I set up n8n last year I was thoroughly confused at the lack of state management. I ended up storing as JSON in a remote blob “database”, a horrible hack.
Node-RED has three state access levels: global one across all flows, a flow based state which is only applicable to one flow and node-based state/storage that is linked to single node.
Any node can access global state, only nodes contained in the flow can access flow state and nodes that have their own state can solely access that storage.
All these platforms are kind of a non-starter at scale. The thing that would really stand out is something that has the user friendly workflow definition but then for production running, bakes it into a container that's orchestrated on k8s natively.
We got workflows, tables and case management. Focused on SecOps, ITOps, and prod eng / infra use cases.
Even if you’re on Jira or SNOW, having even a basic ticketing system built in turned out to be a very productive persistence layer for our users to prototype with.
It looks to me like n8n has suddenly taken over to the point where Automation is now almost synonymous with n8n for most people.
As someone who builds workflows using my own agent system which is based on checklists, subtasks and tool calling with new features or tools based on plugins in Python, it is harder and harder to find an "AI Automation" project where people haven't predetermined that I have to use n8n.
It's ridiculous.
I actually think that defaulting to creating workflows in raw code is not an ideal outcome though because it feels inaccessible to non-programmers.
But I think within X months there will be a lot of people who find out how bad the licensing issues are with n8n and migrate to something similar to my system where workflows are run by agents that have a delegate_subtask command or commands to manage checklists etc. Because most of the workflows can be managed easily by strong models and just described in natural language if the agents have the right tool commands and the system has a scheduling/trigger system.
But then give it another X months or a year or so later and many will start using general purpose computer use agents that they just treat quite similarly to human employees. Because one of the biggest gaps regardless of how you do it is with the inconvenience of setting up OAuth 2 and the operational and bottom line issue of running all of your API requests through some centralized service like n8n.
So we will see people who have agent systems like myself (mindroot on GitHub) start building in computer and browser use capabilities and recipes for accessing websites and creating API keys etc. for their users.
Also there inevitably is going to be something along the lines of OAuth or similar that will allow agents to sign up for services and create credentials on behalf of users to solve this type of problem.
But one of the big advantages n8n has with users right now is that they have OAuth set up with literally everything.
> Also there inevitably is going to be something along the lines of OAuth or similar that will allow agents to sign up for services and create credentials on behalf of users to solve this type of problem.
I agree with you, but the real solution to this is an API.
On the other hand LangGraph and LangChain are an absolute pain to use and you end up spending most of your effort in boilerplate hell if you want to stitch together anything useful
I recently had to build a production-ready workflow in N8N - it ended up being a spaghetti flow of custom code nodes and custom http requests (because none of the provided connectors did exactly what we needed) that I was left wondering if this wouldn't be easier to code up in Cursor.
You want to make an easy automation but doesn't want to write integration code for bunch of platforms.
n8n is good because of loads of easy to use and straightforward to configure with good documentation nodes. Like 'get message from whatsapp' trigger. I have a bot which gets messages from WhatsApp looks for URL in it, downloads a video and posts it to private video hosting, and then shares link in chat with friends.
All components are already there and you don't have to code really annoying infra around maintaining WhatsApp bot.
I self-host n8n along with about two dozen other services for personal use.
I make extensive use of the webhook triggers. Being able to spin up an endpoint with minimal effort is quite handy.
The data table feature looks useful. Similar to another poster, I've been using json blobs on disk instead, since I don't have concurrency, scaling, or performance concerns for my use cases.
I get some very weird vibes from the n8n subreddit. There's a bunch of 'get rich quick with AI workflows' posts which feel icky.
I already felt the need to persist data between different nodes and workflows, so I made a bespoke API with dedicated endpoints that perform CRUD tasks (Yes, it defeats the purpose of a no-code platform but I can code, so...).
I have to say I love N8n so far, it is a great productivity tool.
They fit different niches, IME; node-red is designed for IoT workloads, and so is a great fit for high volume messaging; n8n on the other hand is more workflow automation focused -like Zapier - and so has higher level abstractions and is less focused on performance efficiency.
Can they both fit some of the same use cases? Definitely.
What is the point of this... platform? Also you can't scroll down to the footer because some wonderfully experienced designer (or PM or even engineer) decided the infinite scroll list was a good idea.
it'll be interesting to see what happens with n8n over the next few years.
On one hand, a ton of people are using it to build AI workflows.
On the other, it's never been easier to build a similar workflow in Python with Claude Code or other tools where you get infinite flexibility, version control, and more flexibility on hosting.
We're betting on the later at https://www.definite.app/. Our agent writes pure Python with pre-built integrations into stuff like Hubspot, Salesforce, Attio, Stripe, Postgres, etc.
That pricing model is insane and confusing as hell. Your FAQ clears it up slightly but was hard pass from me almost instantly due to the conflicting information in the pricing section.
I also was shocked when I saw it initially, but it's really just a UI-veneer over an outsourced data team from what I can tell. Although it looks like another product/platform, it's really about outsourcing.
Didn't their change their licensing or something and now folks are leaving? I've seen a few ex-N8n'ers coming over to the Node-RED forum, hence the question.
You can also try https://github.com/autokitteh/autokitteh. Python based, completely open source. Got inter workflow storage as well
Not quite the same thing UX wise. UX is one of the main reasons people stick to n8n, alas.
Yes, we're built more for people who want to build using code, so the UI is different. That said, our road plan includes more UI features.
Yet more evidence that venture capital is basically incompatible with open source software. It's just a matter of time before any VC-backed open source company betrays its users.
n8n was never open source. They started out using Apache with a non-free clause added, but they called themselves open-source incorrectly. Then when this became more widely known, they stopped calling themselves open-source.
Why is it okay to just accept that the hyperscalers are 100% closed, but the minute a smaller player tries to play "open-ish" with "fair source" we crucify them?
Fair source is amazing. You get the code. You can modify the code. You can redistribute the code. You just can't take their business from them and compete with them head-to-head with their product. You can reformulate it into something else, but you can't take their labor and cut their knees off with it. You have literally every other freedom.
Why in the hell are so many people against that?
Fair source is sustainable and equitable. You get everything except for that one little right with which you could compete with them.
Everyone gushes over Obsidian - that's not even "source available" or "fair source". It's completely closed.
I bet if Obsidian went "fair source", and you could download the code and compile it yourself, there would be hundreds of voices crawling out of the woodwork to call them the devil for not being pure OSI-approved open. How dare they keep one little freedom to themselves for all the hard work they've done?
I'm half convinced the anti-"fair source" voices are deep industry folks who want big tech to own the OSI definition. Who can use it strategically as they sit atop hundreds of billions of dollars in cash flows. Open source to the FAANGMAGMA Gods is just a way of outsourcing labor and dangling trinkets in front of underpaid labor.
n8n isn't doing a "VC rug pull." They're trying to be sustainable. The only thing that's been "pulled" is the wool over the eyes of every engineer satisfied with FAANG OSI-approved serfdom. Some of the pieces are "open" all right, but they own pretty much everything the sunlight touches.
If n8n can't build a business then it just becomes some side project hobby. What exactly do we think every other company is doing?
Please be more pragmatic and realize that "fair source" is sustainable. It rewards the innovators and you get almost everything for free. You just can't shoot them with their own gun.
Do you not want the ability to download the source and potentially tweak the software? To have a copy you can hold onto forever? To be able to analyze it for telemetry. To be able to potentially submit patches (if you're feeling generous)?
Don't you want them to make money? Rather than beg for Github donation scraps?
Be especially mindful if you're typing a retort on a Macbook Pro or iPhone and deploying software to GKE or AWS.
---
https://faircode.io/
https://fair.io/
I care that software I depend upon survives long term. In consequence, I care to some extent that the principal company or organization building that software also survives... But that finite concern is balanced against the simultaneous concern that the software itself can survive the organization's potential dissolution. I don't want to have to make a sudden, stressful, expensive migration because corporate buy-outs, bankruptcies, or mergers result in rug-pulls for software I use.
"Fair" source does absolutely nothing to allievate those concerns. The four software freedoms do.
It is true that for a quarter century software developers have naively licensed their projects under MIT and BSD style permissive licenses, and have then felt robbed when big companies come in and eat their lunch. Except it was never their lunch because they didn't actually use licenses that would have asserted their rights to that lunch.
Thankfully, that naivete is finally, slowly dying but, rather than use robust solutions that have been around for decades (e.g. GPL-or-AGPL/proprietary dual license), some developers have invented a new, largely untested concept and named it by dressing up their own sour grapes and spite as "fairness".
"Fair" source software is a non-solution in search of a problem.
Free software and strong copyleft licenses already exist. Dual-licensing already exists. Viable, profitable, healthy, ethical companies built on these strategies already exist.
I used to think Stallman was a crank and a fundamentalist, and he absolutely is, and thank goodness for that. I now think "open-source" is exactly as diluted as free software advocates initially pointed out, and the emergence of "fair" source is part of the damage it has done.
Authors using Fair want to share their code while getting protections for themselves. Strong copyleft doesn't care about authors and is all about protecting the end users.
So Fair fullfills an actual need or desire not covered elsewhere, thus is not a non-solution.
It might be not the appropriate or the best solution to solve the exact concerns of people using it, that's debatable and a different topic, akin to using the wrong tool for the job. Strong copyleft is the wrong tool, too; obviously competitors can just deploy without modifications and offer it as a service.
> Authors using Fair want to share their code while getting protections for themselves. Strong copyleft doesn't care about authors and is all about protecting the end users.
This is a one-sided assertion of fairness, and therefore an abuse of the concept. Free software offers the same rights to both authors and users. That is fairness.
If you want to reserve rights to yourself that are withheld from end-users, that's fine. Arguably even still within a broader conceptual realm of fairness. But naming your personally preferred arrangement of rights "fair" and in so doing implying most or all other arrangements are unfair is just plain arrogant.
Strong copyleft cares equally about authors and end-users. It doesn't disregard authors. Some authors just want to co-opt the general notion of fairness to mean their own licensing preferences.
Call it a non-compete license and be forthright.
Allow me to try a analogy.
You and sfRattan rightfully pointing to a disease (large cloud providers using true free software to make money without contributing back). But "fair source" cure is a new, unproven drug with serious side effects, all while ignoring the established, effective vaccine (strong copyleft GPL/AGPL and dual-licensing), that has been available for decades. The rise of "fair source" is both as sign of "market panic" and just "marketing". It does not seem to be necessary or good evolution for software freedom.
That was HIGHLY abstract... So much so that I am not sure it maps onto reality, but I at least think this is a valid concern.
(A)GPL + Dual licensing is totally insufficient to fullfill the needs, or at the very least the wants, of people using things like "Fair source" licenses (regardless of the naming): to share their code as a sign of goodwill, without that becoming a risk for their survival.
Amazon offers lots of AGPL software, and they fully respect the license in all cases. Ultimately the GPL is about protecting users' rights at the expense of developers' rights. So as long as AWS can offer a better/cheaper managed version of a software service, while still giving the users all details on how to run the same service if they chose to, then the AGPL is completely achieving its aims, even if the original company goes out of business.
-- https://news.ycombinator.com/item?id=45095581
> Ultimately the GPL is about protecting users' rights at the expense of developers' rights.
No. The GPL is about giving developers and users the same rights. Some developers want more rights than users, and engage in special pleading to call that "fairness".
> So as long as AWS can offer a better/cheaper managed version of a software service, while still giving the users all details on how to run the same service if they chose to, then the AGPL is completely achieving its aims, even if the original company goes out of business.
The truth many developers don't want to face is that, if you write a program or tool that can be easily deployed by the behemoths of tech on infrastructure and at scale you cannot match, then you do not have a licensing problem... You have an architecture problem.
A company big enough to take your code and deploy it at overmatched scale and efficiency is also big enough to study your publicly accessible code, however it is licensed, and write new code that achieves the same outcome, maybe even implements nearly the same API, and then deploy that at scale. Actually competing with them involves pursuing fundamentally different architectures and value propositions which they cannot imitate, not writing some new license and trying to pitch it to customers/clients as "fair".
The above reverse engineering and reimplementation already happen in the other direction (e.g. Docker vs. Podman). There's no reason to think a motivated behemoth couldn't do exactly the same to your "fair" source software. On the other hand, Google is constitutionally unable to ever make or deploy at scale something like, for example, Ente Photos, because Google desparately wants all the photos people upload to be legible to Google forever and for whatever new purposes Google's executives might dream up in the future.
> But "fair source" cure is a new, unproven drug with serious side effects, all while ignoring the established, effective vaccine (strong copyleft GPL/AGPL and dual-licensing)
Can you explain this a bit more? I don't understand how this is true.
AFAIK AGPL only prevents someone from modifying your AGPL codebase without sharing that in turn, but if they're content to offer exactly the service you're offering without modification it's not an issue.
See for example Grafana, which is distributed under the AGPL but still has to handle competition from AWS and Azure that have managed Grafana offerings.
I'm all in favor of free software, but it sounds a bit disingenuous to pretend that the GPL or even, to a lesser extent, the Affero variant, are providing a safe haven for sustainable software. The reality is, sadly, that free software depends on the good will of very few idealistic people who manage to somehow make a living while spending a lot of time on working for free ; and i must know since I've been lucky to be able to do this most of my life. This is no guaranteed survival or innovation.
While I believe it's very useful to remind users of the freedom they should ask for, I don't think it's useful to oppose free software with fair source, exactly like in the past it was important to remind users of the differences between free software and open source, yet it was counter productive to oppose them.
> Git clone, problem solved.
What a myopic assumption. Availability of source code doesn't solve the legal problems that can arise in the wake corporate restructuring, as new owners work to impede forking and continuing a project outside their control.
Continuing a project in the wake of total organizational failure or capture means setting up legal entities to replace the broken/subverted ones. That's a problem separate from "is the code out there on the Internet for me to download?"
In comparison to the GPL and AGPL, "fair" source licenses are at best hastily drawn. They certainly do not have decades of accrued favorable legal precedent. They are often short and ambiguous because their authors have not imagined half the use cases they might potentially forbid in the name of "fairness". All these qualities are miasmal to long term project stability.
In practice, what matters is that indeed the code is available in a form that makes it modifiable and that machines are available to run it on. Oracle and its hordes of malignant lawyers tried, and almost succeeded, to make this illegal with Java but thanksfully failed.
Why would I need to set up "legal entities" to enjoy my freedom as a user of open source software, unless I'm trying to start a competing business? It's unclear to me what you have in mind. Please explain like I'm a myopic person.
The people promoting "fair" source are specifically doing so to set up legal entities---companies---in order to run a business. That's fine, but it means users of their software should include the potential endgames of those legal entities in their assessment of the software's long term viability. That frame was implicit in my original point.
Any sufficiently large and complex piece of software (free, nonfree, or proprietary) will eventually need some kind of inter-human organization and governance. It won't matter for a small program with complexity that can be managed inside the head of one person but, again, "fair" source as advocated by its own proponents is about software of sufficient complexity to justify legal entities owning, stewarding, guiding, and managing it.
And, IIRC, Oracle and its lawyers, when trying to digest Sun Microsystems, choked on the GPL specifically at least twice: with both MySQL and OpenOffice. The GPL's well thought out protections enabled independent institutions to form around successor forks to those projects. Would the same have been possible with a relatively new, less well thought out "fair" source license? I don't think so.
I don't know what exemple you have in mind, but we were discussing n8n, redis, elastic search... Probably you have much more complex projects in mind?
If I go tu use, say, redis, in a way that the license permit, I don't give a single dime about the legal entity behind it. I just `apt-get install redis`. If I want to modify it for my need, I can `apt-get source redis`. When the next version of redis comes with a more restrictive license, or if features are removed, I just stick to a previous one. Maybe I fork it myself if it's really important for me. Probably, we will be many doing so, we will regroup, share our modifications and improvements. I've experienced this kind of colaborative maintenance of some dead project a couple of times in the past, and all te governance that was ever needed was a mailing list.
Now, sure, some project are more complicated. If, god forbid, postgresql or gcc were to disapear I would not trust myself, or any single individual, to maintain a private fork for long withough the quality deteriorating. But again, people would regroup, cooperate, and we will be able to figure it out.
Compare this with proprietary software, were you truly have no recourse. I've seen wonderful pieces of software in the past, that I loved an used daily, disaprear entirely because the company that produced it went belly up, leaving no alternative than to desperately run the old versions on an emulator still years after because nobody ever managed to redo something as good. And now they are gone, for good, with few people ever remembering them.
So, these are the exemples I have in mind, this is why I don't understand how one could equate fair-source with proprietary -- assuming that the restrictions tainting the "fair" software just prevent the user from competing with the software producer. The user has a ton of power with fair source compared to proprietary.
> When the next version of redis comes with a more restrictive license, or if features are removed, I just stick to a previous one. Maybe I fork it myself if it's really important for me. Probably, we will be many doing so, we will regroup, share our modifications and improvements. I've experienced this kind of colaborative maintenance of some dead project a couple of times in the past, and all te governance that was ever needed was a mailing list.
This situation is a one kind of sudden, unplanned migration. You seem to assess it as less stressful than I would. I'd also be concerned about security generally, duplication of effort to maintain the private fork, and potential retaliation if total secrecy isn't kept by the fork's maintainers.
Your reasoning makes sense for choosing software to use as an individual, but not when choosing software as an organization or when choosing software to integrate into software you distribute for others to use.
Your reasoning also makes sense for maintaining software that has a relaxed threat model (i.e. typically runs or can be made to run in isolation from any network). But the examples you pick (n8n, redis, elastic search) are most often used on perpetually networked computers where security a larger concern and I don't know that I'd trust a private, ad hoc group to keep a secret fork (in potential violation of a "fair" source license) up to snuff.
Oh I see. Sure I trust individual maintainers at least as much as large organisations. Part of my first gig included running debian potato's postgresql on a PC with an oracle sticker on it...
Are you me? That was so scarily close to how I think about this that I could have thought I wrote it myself. Except you know a more about licenses :P Well written. Thanks.
Edit: I would also add that, based on the specific software/business, the problem with "rug-pulling," as described by another user here, is a real thing. I think that the reason Obsidian doesn't get hate, while being closed source, is that they are at least predictable and honest about their strategy. Their pricing is fair, and development and business plans are openly communicated. It's silly to be angry at a firm for wanting to be closed source, but if they start out pretending to be fully open source and community-motivated, while receiving lots of coding contributions, then suddenly do a rug-pull by removing features from the community edition and paywalling all important features, that is something a lot of us are going to be annoyed by.
You're welcome! :)
> It's silly to be angry at a firm for wanting to be closed source, but if they start out pretending to be fully open source and community-motivated, while receiving lots of coding contributions, then suddenly do a rug-pull by removing features from the community edition and paywalling all important features, that is something a lot of us are going to be annoyed by.
Indeed, and that is why assessing the long term viability of an open-source or free software project means looking at multiple variables. This thread has mostly been about licenses, but there's also literal distribution of ownership... Both ownership of copyright and of corporation.
Is the code's copyright owned by the company and does the company only accept contributions with a contributor license agreement that transfers copyright to itself? Potential red flag. They're keeping the door open for an attempt to rug-pull, but they also might just be trying to do business via dual licensing.
Is the code's copyright owned by too many people to ever feasibly relicense? Green flag, as long as a healthy foundation exists to keep things on track (e.g. Blender Foundation or The Document Foundation).
Is the company publicly traded or has it accepted large amounts of investment? Red flag. Those investors will demand a rug-pull the moment the lines on their sacred monthly and quarterly graphs stop going up.
Is the company closely held by a few people? Potential green flag, depending on the people.
I don't know/care about "fair source," but the "open source" label in particular has ALWAYS had a well-known and specific meaning in the software world. Attaching it to a proprietary product for the marketing and social media good feels is actively deceitful, no matter if the company is USA trillion-dollar Big Tech or a single developer from a marginalized demographic in a developing country.
Software authors have the right to choose whatever license they wish for the project/product, just don't try to lie to users about what it really is.
"Open" AI, "Open" Router, and the like typically get a pass.
n8n has never called themselves "open". Their first commit:
https://github.com/n8n-io/n8n/blob/9cb9804eeec1576d935817ecd...
There's so much misinformation and animosity about fair source licenses.
> n8n has never called themselves "open"
Trivially debunked by looking at their homepage in 2019: https://web.archive.org/web/20191009000026/https://n8n.io/
The person I was replying to seemed to be under the impression that n8n used to be open source and now is not. This is not the case, so I pointed that out.
Did you have anything to say about my actual comment, or are you just attaching your rant to a random part of the thread?
Quoting another poster (wavemode) here...
Trivially debunked by looking at their homepage in 2019:
https://web.archive.org/web/20191009000026/https://n8n.io/
That archived page doesn’t debunk what I am saying, it supports it.
> Open Source Alternative for Zapier/tray.io
They claimed to be open source…
> (Apache 2.0 with Commons Clause)
…but they were not. The Commons Clause means that it isn’t open source. It’s a commercial restriction.
The founder directly said this when discussing it here, the day before that archive was saved:
> > This is not open source - it is source available.
> Yes you are correct. Wrote an extra section about it here in the docs: https://docs.n8n.io/#/faq?id=license
— https://news.ycombinator.com/item?id=21192277
No, what I linked to does not show that they used to be open source. It shows that they used to call themselves open source, despite never having been so.
this is a solid argument against the open-source purists that I've never heard before and really appreciate. Many people would like to make money on the things they spend their time building. Some percentage of those people also love FOSS. Fair source is the middle ground where they can share their work, open it up for criticism, issues, and fixes, but ensure that their business is secure. It's a solid middle ground that shouldn't be demonized just because it isn't open source.
I think because providing commercial support for such a software is not allowed by the license, there is a strong vendor lock-in. That‘s a big drawback for users.
> Why is it okay to just accept that the hyperscalers are 100% closed, but the minute a smaller player tries to play "open-ish" with "fair source" we crucify them?
besides morale, from pure business point of view, hyperscalers will likely last, so that's Ok to rely on them, small OSS projects can be supported/modified by community or business itself, but when some small closed source service is gone, it is compete shutdown, you need to migrate to something else in a very big hurry.
May I remind you of https://killedbygoogle.com/ ?
that list is catchy, but if you dig into details, there are many caveats, for example many product were not killed, but replaced with low friction, for example hangout, many products were created at period of time when there was that google labs which launched many strange low quality products which never gained traction.
If you check some core business products (ads, cloud), google usually provides reasonable deprecation timeframe (years).
True that google never depleted us from messaging apps; at some point they had 3 different in operation, with contradictory statements about which one was made obsolete by some other.
Which also illustrate that a stable business does not imply a stable product.
> Which also illustrate that a stable business does not imply a stable product.
there is no absolutely stable product, some weird stuff can happen to everything, its question of probabilities, what the chance that some underfunded startup with negative cash flow will shut down some product, and what is the chance that google will shut down AdWords API?
Try activepieces, they never did any bait and switch.
https://www.activepieces.com/
Looks like they have tables too
Hadn't heard of Node-RED but this is really cool. Thanks for mentioning it.
What do people think about windmill.dev for such workloads? I've found their community tier quite generous and ability to script, access control, make frontends, approval flows quite helpful
I was in an org that used windmill. We eventually got off it mostly because the model encourages end users to install arbitrary python packages at runtime from the internet. That might be acceptable for some use cases but not ours
Node red is better (imo) but harder for non technical users to use
What makes it feel harder to you for non-technical users? I'm a huge fan - it's what brought me to them to do DevRel stuff - so I'm really invested in making sure that the onboarding/use pathway is really clean and well laid-out.
+1 for Node-RED. If we've learned anything from elasticsearch/redis/bitnami/and dozens of others, it should be "don't build important things on code that isn't enshittification-resistant"
What did elasticsearch/redis do so wrong?
AWS and Google stole their only revenue source.
Those guys did all the work and AWS and Google get to collect a cool hundred million each quarter for doing next to nothing. And the original authors can't compete with that.
Are we all gonna go sign up to "Enterprise Redis Cloud" to support them? I don't think so. They have nothing left. They got picked dry.
If they're preserved a "no managed offerings" freedom for themselves, they could collect a few hundred million from each hyperscaler each quarter and put that directly into product. And their engineers would be extra nicely compensated.
But that's not how this story plays out. Big tech just takes things and finds out how to monetize them in ways they don't have to give back.
And we've been trained (by big tech?) to yell at the little guys that try to carve out a space for themselves.
Both are billion dollar companies, we as individuals have nothing in common with them. Enshittification happens due to market conditions that apply to small and large companies alike. Redis and elasticsearch aren't underdogs fighting for the little guy, they are just a smaller scale version of the same shit.
I'd rather have a software commons and have tech be owned by the workers and not soul-sucking corporations, no matter the size.
Sure, so would I. I would also prefer to live in a world without borders. Meanwhile, I'm just a peace activist.
Life in this imperfect Earth makes you grumpy too early if you are not pragmatic.
Node-RED is cool but I didn't realise it could do the AI workflows that n8n is aiming for?
It definitely can! Full disclosure, I'm a DevRel at FlowFuse, so I'm definitely biased here - but there's quite a lot of support for AI workflows, from lightweight automation to fairly complex pipelines.
For example, I'm currently building a flow that connects device monitoring data to a central reporting structure, compares the incoming values against internal spec docs, and uses OpenAI to summarise overall operational status and any drift/out-of-spec issues. The summaries (along with the raw JSON objects) are then sent over MQTT for multi-site compliance and operations. Once you map it out, it's surprisingly straightforward to build.
What makes Node-RED and FlowFuse stand out on this particular use case IMO is that AI flows get treated just like any other message payload. That means your AI output becomes a first-class data object in the system - you can remix, transform, mutate, or extract from it the same way you would any other JSON payload, making it pretty portable and easy to integrate.
Node-Red is probably a more hands on approach, than n8n, as someone who have 6-7 years of experience in node-red i find n8n really complicated for some reason. A lot of windows and configurations. Started with node-red and quickly built great skills in backend development.
Also utilized Cursor to quickly spinup a OpenRouter nodes for node-red, install node-red and check them out :D https://www.npmjs.com/package/@lizzard-solutions/node-red-co...
Love to hear you love using Node-RED!
That package looks pretty cool! I'll check it out - I'm super in the weeds today with a flow so I'm in deep-dive mode.
For the AI workflows, we (windmill.dev) added AI Agent steps as first class primitives very recently.
It can, absolutely. I have been prototyping Agentic workflows on it for a long while now with my own custom nodes. Also, it runs great on bun now.
Keep to know how people are using it inspite of the licensing issues. Langflow seems good?
Langflow was more painful than a wisdom tooth extraction to use. This was back in early 2025 tho
I would recommend Node-RED but that's a lot more work than a Zapier or N8n but you can do more with it - Node-RED abstraction level is closer to a programming language than a SaaS combinatorial tool.
Depends on what you want to achieve and how much effort you want to apply.
There is also langflow.
unfortunately it can't do parallel tool call!
ActivePieces is also an option
The other licensing shoe is going to drop. And when it does, it will be same as always. Important features will be cut of from “community” edition, like admin for minio, and pricing will be predatory for full product, like Taipy. Seriously, screw Taipy. Got quoted 200k for an open license if I wanted to self host it, with no limit on number users.
I got hit by the Minio admin change in the console when I upgraded my installation recently, and I found https://github.com/huncrys/minio-console which adds it all back in. It works as expected so far.
I find this kind of rug pull behavior so hostile I will be looking to replace Minio as soon as possible in my homelab. To be clear, I would pay for a license if the prices weren't impossible to afford as an invidual who uses Minio for non-business reasons.
Rug-pull is a good description of how I feel also.
And the most annoying thing for me is that I, like you, actually WOULD be happy to pay a REASONABLE price. But all the patterns nowadays are bi-modal. Stripped-down community edition to get open-source and community credit (and hopefully free coding contributions) on one end.And on the other end; enterprise pricing, with per-user or other complex pricing rules and restrictions. And only after "Let's talk" and "Contact sales" waste of time.
What about a reasonable, low recurring fee with no limits on what I can do with it if I self-host? Or a modest one time price for one version of the software? It doesn't cost the creator any more whether I have 2 users or 200 if I self-host.
I used to disagree a lot with Richard Stallman, but now when I ask AI to help search for software alternatives, I always specify "Only TRUE FOSS alternatives, with no enterprise option or paywalled features." Not because I don't want to pay a fair price, but to avoid being flogged AND the unnecessary complexity of setting up a damn equation to figure out how much it will cost.
Great to see this land.
When I set up n8n last year I was thoroughly confused at the lack of state management. I ended up storing as JSON in a remote blob “database”, a horrible hack.
Node-RED has three state access levels: global one across all flows, a flow based state which is only applicable to one flow and node-based state/storage that is linked to single node.
Any node can access global state, only nodes contained in the flow can access flow state and nodes that have their own state can solely access that storage.
All these platforms are kind of a non-starter at scale. The thing that would really stand out is something that has the user friendly workflow definition but then for production running, bakes it into a container that's orchestrated on k8s natively.
Hi HN, has anyone tried: https://github.com/TracecatHQ/tracecat
We got workflows, tables and case management. Focused on SecOps, ITOps, and prod eng / infra use cases.
Even if you’re on Jira or SNOW, having even a basic ticketing system built in turned out to be a very productive persistence layer for our users to prototype with.
Copy left AGPL 3.0 license.
What percent of agent devs are using tools like this versus writing code to define their systems?
Seems like a lot, and I find it surprising that people would build real world workflows on platforms like this.
It looks to me like n8n has suddenly taken over to the point where Automation is now almost synonymous with n8n for most people.
As someone who builds workflows using my own agent system which is based on checklists, subtasks and tool calling with new features or tools based on plugins in Python, it is harder and harder to find an "AI Automation" project where people haven't predetermined that I have to use n8n.
It's ridiculous.
I actually think that defaulting to creating workflows in raw code is not an ideal outcome though because it feels inaccessible to non-programmers.
But I think within X months there will be a lot of people who find out how bad the licensing issues are with n8n and migrate to something similar to my system where workflows are run by agents that have a delegate_subtask command or commands to manage checklists etc. Because most of the workflows can be managed easily by strong models and just described in natural language if the agents have the right tool commands and the system has a scheduling/trigger system.
But then give it another X months or a year or so later and many will start using general purpose computer use agents that they just treat quite similarly to human employees. Because one of the biggest gaps regardless of how you do it is with the inconvenience of setting up OAuth 2 and the operational and bottom line issue of running all of your API requests through some centralized service like n8n.
So we will see people who have agent systems like myself (mindroot on GitHub) start building in computer and browser use capabilities and recipes for accessing websites and creating API keys etc. for their users.
Also there inevitably is going to be something along the lines of OAuth or similar that will allow agents to sign up for services and create credentials on behalf of users to solve this type of problem.
But one of the big advantages n8n has with users right now is that they have OAuth set up with literally everything.
> Also there inevitably is going to be something along the lines of OAuth or similar that will allow agents to sign up for services and create credentials on behalf of users to solve this type of problem.
I agree with you, but the real solution to this is an API.
When did this happen?
I’ve been using n8n for two or so years. Just feels like I woke up one day and everyone else was using it too.
it didn't help that its competitor "make" was hard to find on google :/ naming matters folks!
On the other hand LangGraph and LangChain are an absolute pain to use and you end up spending most of your effort in boilerplate hell if you want to stitch together anything useful
I recently had to build a production-ready workflow in N8N - it ended up being a spaghetti flow of custom code nodes and custom http requests (because none of the provided connectors did exactly what we needed) that I was left wondering if this wouldn't be easier to code up in Cursor.
Who says they're not writing code? I imagine a declarative DSL with a typescript SDK for the primitives is appealing to some devs. There's an API too.
It's a bit too simplistic for complex workflows, its model assumes a workflow is executed entirely by a single worker...
I don’t get all the n8n hype
You want to make an easy automation but doesn't want to write integration code for bunch of platforms.
n8n is good because of loads of easy to use and straightforward to configure with good documentation nodes. Like 'get message from whatsapp' trigger. I have a bot which gets messages from WhatsApp looks for URL in it, downloads a video and posts it to private video hosting, and then shares link in chat with friends.
All components are already there and you don't have to code really annoying infra around maintaining WhatsApp bot.
I self-host n8n along with about two dozen other services for personal use.
I make extensive use of the webhook triggers. Being able to spin up an endpoint with minimal effort is quite handy.
The data table feature looks useful. Similar to another poster, I've been using json blobs on disk instead, since I don't have concurrency, scaling, or performance concerns for my use cases.
I get some very weird vibes from the n8n subreddit. There's a bunch of 'get rich quick with AI workflows' posts which feel icky.
Does the name n8n have a longer version like k8s does? Is it a similar naming convention or n8n is the full name?
its full name is nodemation. Ye I think it's the same naming convention
I already felt the need to persist data between different nodes and workflows, so I made a bespoke API with dedicated endpoints that perform CRUD tasks (Yes, it defeats the purpose of a no-code platform but I can code, so...). I have to say I love N8n so far, it is a great productivity tool.
I love Node-RED instead of n8n. But it's biggest problem is that does not have the concept of an "execution". Which sucks.
They fit different niches, IME; node-red is designed for IoT workloads, and so is a great fit for high volume messaging; n8n on the other hand is more workflow automation focused -like Zapier - and so has higher level abstractions and is less focused on performance efficiency.
Can they both fit some of the same use cases? Definitely.
Slightly off topic question , but do you pronounce it n eight n, or Nathan ? I got blank stares when saying Nathan from my colleagues :')
Nodemation
It's awesome for quick projects, but that 50MB limit makes me think I'll just end up migrating to Supabase or Airtable down the line anyway.
For self hosting you can raise the limit.
Also, take a look at windmill.dev. It’s a beast
I think windmill got the entities right (script, flow, app). The last I tried it was a bit more complex to setup than n8n.
We also had to abandon it, due to setup complexity coupled with capacity constraints.
We’ve similarly had a lot of success with self-hosting Windmill.
What is the point of this... platform? Also you can't scroll down to the footer because some wonderfully experienced designer (or PM or even engineer) decided the infinite scroll list was a good idea.
Classic.
You're looking at the community forum, which uses Discourse (https://www.discourse.org/).
Check out the n8n home page (https://n8n.io/), which is actually great at clearly communicating the point of the platform.
Has only 17 Microsoft integrations, covering only 10 products.
The Silicon Valley startup bubble world always amuses me.
"You can integrate with anything! Well, except the enormously popular suite of applications used by everyone, everywhere else!"
You can do arbitrary REST API calls from n8n, which greatly increases the integrability surface.
[dead]
[dead]
[dead]
The n8n space has been crowded for a long time - Tray io, Zapier Enterprise, Workato, Make, UIPath, and many others
N8n seems to be standing out thanks to their open source roots (and not deliberately hampering the OSS variant too much).
DataTables will make a big difference again - being able to store some level of "state" has been a need in almost every workflow I've built.
n8n doesn’t have open-source roots. It’s never been open-source and doesn’t have an OSS variant.
It’s smart for N8N to add DataTables. Had to of been the biggest dev need.
it'll be interesting to see what happens with n8n over the next few years.
On one hand, a ton of people are using it to build AI workflows.
On the other, it's never been easier to build a similar workflow in Python with Claude Code or other tools where you get infinite flexibility, version control, and more flexibility on hosting.
We're betting on the later at https://www.definite.app/. Our agent writes pure Python with pre-built integrations into stuff like Hubspot, Salesforce, Attio, Stripe, Postgres, etc.
Might be easy to build, but impossible to maintain.
That pricing model is insane and confusing as hell. Your FAQ clears it up slightly but was hard pass from me almost instantly due to the conflicting information in the pricing section.
I also was shocked when I saw it initially, but it's really just a UI-veneer over an outsourced data team from what I can tell. Although it looks like another product/platform, it's really about outsourcing.
Yeah, we're working on it. I'd prefer to by compute hours, but it's hard for people to know how many hours they'll need.