N8n.io – Workflow automation alternative to Zapier
n8n.io
n8n.io
n8n is a free node-based "Open Source" (Apache 2.0 with Commons Clause) Workflow Automation Tool. It can be self-hosted, easily extended, and so also used with internal tools. Currently, there is no hosted version yet but you can sign up on the website if you are interested to get informed once it is ready.
I created it initially because I realized that every time I wrote a script to automate a small task it took me a very long time. Depending on the task it normally involved: reading documentation, writing code, committing to Github, deploying on a server, error reporting, SSL, make sure it restarts on a crash, and so on. So even very small tasks took at least half a day or day till everything was up and running properly. Existing Open Source solutions were not up to the task and also commercial ones like Zapier did not work for various reasons. Some being that they do not work well with in-house tools or complicated tasks and it gets expensive quite fast, ...
So hope n8n is as helpful for other people as it is for me. Also, all help with further improving the project and create more integrations is very welcome!
The project website with the nodes which exist and example workflows:
You can find the source code on Github: https://github.com/n8n-io/n8n
The whole project is written in TypeScript and uses Vue for the frontend. So it should be easily extendable for everybody with web development experience.
If you have any problems, questions or need an integration which does not exist yet you can post it to the forum: http://community.n8n.io
Documentation can be found here: https://docs.n8n.io
Your feedback is highly appreciated!
Thanks a lot!!
UPDATE:
[Sorry are unable to answer any questions right now as it always displays me that I am posting to fast. Will answer as soon as HN allows me!]
Interesting resource. But, how do you filter for just self-hosted... I can't find that as a specific category.
Who's your target demographic here? I work at a place that was considering using Zapier, but couldn't because the security story around that service didn't really meet requirements we had around legal compliance/regulations (SOC, PCI, etc).
Having freely available source to audit + a good security story could make n8n very appealing for back-office enterprise workflows.
As someone who left this space just two years ago and is now selling software into it I've been shocked by my users' appetite (appetites?) for self-hosted solutions. It makes me wonder whether SaaS will be short-lived and we'll see highly-regulated industries like finance and healthcare insisting data doesn't leave their servers unless absolutely necessary.
If you run a SASS and a regulated business wants to use you, they need to process a whole slew of items:
1. Compliance - are you PCI/SOC/HIPPA compliant? When was your last audit? What were the results?
2. Legal - contracts, business continuity clauses, indemnity, liability around data, etc
3. Security - when was your last penetration test? Do you have a security team? What is your security posture?
The list goes on and there is overlap between different corporate concerns. Keeping things on-prem removes many requirements in exchange for taking on the maintainable burden of a product.
Disclaimer: Worked at a SaaS company, now work in highly regulated financial services.
The source and documentation for setting it up, using it, and developing with it are already available.
Look at the Business Source license — they do that. (I'm doing the same with my project: AGPL —> GPL some years later.)
Best wishes :- )
All versions of AGPL allow both non-commercial and commercial usage. (And one needs to share-alike one's modifications.)
In any case I like the idea to be free for charities and public research :- ) You work with something like that? Is AGPL ok with you, or you're worried it might require you to open-source parts of your platform?
AGPL requires all users to open-source their projects using your work, even if they don't modify your work. It is an extension of GPL not LGPL. If my web application uses an AGPL library, it's a derivative work.
I, like many in my field, work in a small team with almost no budget. My current project involves collecting sensitive (medical) data over the internet. The cost and risk involved in open-sourcing our application is prohibitive.
However, it's slightly less relevant for your project, as I can't see much value in directly integrating it into another application :) This is more a problem we run into with AGPL libraries, not AGPL applications.
Commons Clause is not Open Source. It is free-of-charge (for certain uses) source-available proprietary software.
I don't know about all the licensing stuff and will have to evaluate if I can use it for official business but I'm glad I can just use it for my own stuff in private without paying high fees.
Don't take the harsh critics about the licensing too personally - I think it's cool that you released your code and thought about Open Source licensing.
Keep up the great work!
If you are unsure about if you can use it, simply explain what you want to do in an email to "license@n8n.io".
The goal with the license was not keeping people from using it. The main goal was to start it in a way to make the project long term sustainable which I thought would be in the interest of all people using it.
Also does not mean that people can never use it in a way which the license prohibits by default. It simply means that away has to be found which is beneficial to all sides. So just like anywhere in life.
- Bulk actions. - Sync actions.
And support for other programming languages (eg. python)
Hope that helps.
Half-tempted to dive in and see if I can code something up, but I need to focus on other parts of my business and not dive down the scratch-my-itch dev rabbit hole (again).
- Provide first class debugging and dry-run support. Don't make people either run in prod (as the demo video effectively does) or set up full testing environments.
- Strict, comprehensible scoping rules. Non-programmers will have more, not less trouble with having named data propagated everywhere for reasons that aren't visually clear. Global state is still bad.
- Don't make users think about JSON.
- Supply auto-layout. Don't force users to manually reposition things to get a decent layout, and ideally don't let them. The demo video seems to show at least the first half in place, so that's good.
- Version control. Possibly via...
- Ideally an isomorphically editable text representation. You can switch between graphical and text representations and have changes propagate.
Maybe this project checks more of these boxes than I've seen so far. I'm pathologically optimistic, so there's a good chance I'll work with this enough to find out.
I don't really know why everyone wants to keep making these benighted flow-chart UIs instead of using the relatively proven Scratch UI model.
Is this what you meant? https://scratch.mit.edu/developers
I really think the community angle is unique.
The community part is hard to generate though... there's a lot of enterprise in the workflow space.
Pricing is a key differentiator. My market research included a pricing analysis and Boomi was priced well above Zapier and other similar solutions.
I think there is a LOT of money ceded to less expensive offerings by 10 or 15 providers (including Boomi) all chasing the same enterprise market. I would've expected tiered pricing to emerge to a greater extent, but haven't seen it.
I watch this space very closely.
It’s maybe a dumb question but even after looking in some of them I usually fall back on a classic cron job + some Python scripts for automation for the flexibility. What’s the biggest advantage of these services / solutions when you already have some servers available?
Also - do you mind if I grab some of your time to discuss on the phone? my contact details are in my profile.
Thanks!
But something like n8n I would consider using, because you've provided an escape hatch to lock-in by making the source available. I think it's totally reasonable to prevent other companies from profiting from your work. I also think it falls under the umbrella of "open source". If someone wants a truly FLOSS version of this, they're welcome to make it themselves. But they won't, they'll just complain and keep using n8n, because the licensing is good enough for 99.9% of use cases.
EDIT: I just want to point out that there's been some discussion of licensing here which I've personally found interesting and instructive. I've seen several people suggest that there is a definition of the term "open source" that is essentially universally agreed upon (that being the Open Source Initiative definition [0]), and that that is the only valid definition. I've worked in what I consider to be open source for many years, and wasn't aware that such consensus had been reached. My personal views have not changed as of yet, but my paradigm has definitely shifted. I intend to pay closer attention to how others use this term, and carefully attempt to be clear about my usage in the future. Having a single agree-upon definition of things is always valuable, and if that's where we're at I'm all for it. I'm just not convinced yet that it's actually 100% agreed upon.
That said, I think the author of n8n was pretty dang clear.
I mean, I'm just using a popular non-open source piece of software as an example, you don't really have to read into it this much. Every comparison has limits, this isn't any exception. You can substitute 'Windows' for 'Gitlab EE' which is also proprietary software with available source code.
>Also, you're comparing one of the biggest tech companies in the world, to an individual who is trying to make a living. This is an unfair characterization on every level.
The depth of someone's pockets doesn't influence the definition of open source, though. This is not a characterization at all, rather, I'm saying that using the word open source to describe software that doesn't meet the criteria is always going to upset people. There is a simple solution that costs no money: removing the word open source. It is even recommended by the folks who push common clause.[1]
I realize people are very passionate about this, but please try not to read into what I'm saying too deeply.
(Also very notably: I have absolutely NOTHING against proprietary or shared source software, or developers making money; love Gitlab EE as an example. Just please be honest.)
Even beyond that, on a human level, the attacks on an individual trying to make a living seem unnecessarily harsh. My critique is mostly about the spirit of the negative comments (not just yours, sorry), which all seem to assume malice where there likely is none. I.e. several comments here and on the github repo calling the developer a liar and coward, etc (again, not you, this just happened to be the comment I replied to)
And I think this entire discussion proves that the definition of 'open source' is not as cut and dry as some people would like. And because of that, saying 'just be honest' when someone uses one of the alternative definitions of the term seems unfair.
I've always thought that the terms FOSS exists specifically to provide some extra clarity in this regard...
And I don't know what you'd call this other than "open source" because I haven't heard the term "source available" until today, and I would have had no idea what it meant if that's what the developer had used....
There is nothing wrong with marketing a project, be it open source, proprietary, free, non-free, etc. I never suggested that. Just about everything is 'marketed' in some sense.
>Even beyond that, on a human level, the attacks on an individual trying to make a living seem unnecessarily harsh. My critique is mostly about the spirit of the negative comments (not just yours, sorry), which all seem to assume malice where there likely is none. I.e. several comments here and on the github repo calling the developer a liar and coward, etc (again, not you, this just happened to be the comment I replied to)
It's because there's a lot of passion involved. Even people who are pretty great open source developers have acted in a way that is perhaps not so noble if you read the flagged comments.
However, I don't think this is necessarily out of assumption of malice. The problem is, it doesn't matter if the author is malicious or not. The term 'open source' carries some connotations that many people have an intuitive understanding of today. I firmly believe the very reason a lot of big projects choose open source is for the marketing benefit, and imo it is not deserved if your project isn't really open source. This could seriously harm the reputation of something that took decades to build, and if that seems alarmist, well, I know I'm not alone in this sentiment.
>And I think this entire discussion proves that the definition of 'open source' is not as cut and dry as some people would like. And because of that, saying 'just be honest' when someone uses one of the alternative definitions of the term seems unfair.
>I've always thought that the terms FOSS exists specifically to provide some extra clarity in this regard...
> I don't know what you'd call this other than "open source" because I haven't heard the term "source available" until today, and I would have had no idea what it meant if that's what the developer had used....
The thing is, if I say something is 'open source,' you almost certainly, today, will understand that to mean what it has meant for decades: the OSI definition of open source, contrary to the wishes of some (including rms, for example.) This is just the layperson's understanding. They may not have a deep understanding of licenses or permissiveness, but it comes with a sense of what a project has to offer. Being able to profit off of open source is something that people inherently understand nowadays, and it took a long time for that to happen.
The reason you wouldn't have understood another term is because there is not a common understanding for 'source available' or 'commons clause.' This is because it was not very popular in recent years, and remains relatively unpopular. It is mostly pushed by companies that built amazing open source projects and had trouble with creating a sustainable business around it.
And therein lies the contention.
- Because of what Open Source implies, it gives projects a decent marketing boost - including, of course, the common case where they are truly open source. People rely on open source projects understanding the implications and knowing roughly what they can do with it.
- Commons clause doesn't imply the same things. But some companies are trying to use the term 'open source' to describe them anyways. To me, this looks a lot like trying to have cake and eat it too. It's not the same 'open source' that people have slowly grown to understand.
Of course most people won't understand why this issue has much contention, because this type of thing seems like a minor detail. In fact, many people, including me, initially found it confusing that licenses like GPL allow you to profit off the work so as long as you follow the other clauses. It took me a long time to understand that this is a very important part of what makes open source special: the disconnect from the profit model. If you reconnect the development and licensing to the profit model, in my mind this is losing a key part of what makes open source so damn effective. Having many stakeholders that all profit from a project can be incredible - the Linux kernel being one such example.
People have to make money, though, and so going through the risky proposition of making truly open source software and trying to build a business around it is not always appealing. In my opinion, the obvious choice is to not make open source software. So-called "commons clause" is one option. But again, I think there is real danger in "open source" being conflated with things that nobody understands it to be.
If you're trying to make money, just don't do open source. No one owes you kudos for striking a compromise no one wants.
I wonder why, in this era of Swagger / OpenAPI / Postman Collections / API Gateways ... why this is so difficult? I feel like there was a promise that integration would become more magical at a rapid clip, but as it stands it just seems like there are more options but no less headaches.
Of course, as APIs improve (OpenAPI, etc), the barrier to entry for all workflow tools declines (which is a good thing!). You're then just serializing and deserializing JSON (or a mutation thereof) between two or more steps. Just as Google makes their Terraform provider a first class citizen by autogenerating the Terraform provider based off of their APIs (Hashiconf 2018 SF talk), so could integration partners for workflow automators. Just takes time for the ecosystem to mature.
https://github.com/DataFire/DataFire
I've used it before and it's not too bad.
However... The beauty of Zapier relies on its amount of pluggable blocks. I don't think there's anyone in this market that has as many operations as Zapier and using custom blocks you can do pretty much anything. Yes I am totally a fan of Zapier as I have been using it for years! Zapier is like LEGO, there are many clones of LEGO but only one true LEGO (ouch my feet hurt just by thinking about it ;) ) I really hope you can get people to contribute more and more integrations as that's what really matters at the end of the day: The ability to use little or no-code to achieve automation between various platforms!
Easily extendable and new integrations can be built easily.
Also helps that the author works here and is generally a great guy ;-)
As someone who relies on a lot of Zapier-style API connections, I’d love to hear more about how people approach it - how you go about managing env vars (keys/token), abstracting similar service procedures (oauth, webhooks) and generally monitoring 3rd party API endpoints for keeping the connections healthy? Any advice from Zapier / IFTTT veterans?
Edit: the n8n docs seem good and also address most of my questions [1]
Great to hear that the docs are helpful! They were actually the main reason why I did not launch on Product Hunt/Hackernews earlier. It was very important for me to have something in place which is at least reasonable. Nothing more annoying than bad docs. Anyway, still a lot on my list to add documentation for. But it will get better, I promise!
Public Service Announcement for anyone at BigCorp: Microsoft has it's own tool in this space called Microsoft Flow[1]. It's not as feature-filled as Zapier, but it works in a pinch and you get access to it automatically as part of an Office/Microsoft 365 license. So unless your corporate IT has gone to great lengths to explicitly disable access to it, you can leverage it to make your life at least a bit easier.
> Standard Library: APIs as Building Blocks
But the usual benefits of free software, like what has been possible with the Linux kernel, GNU software, and so much more, are not going to be possible to the same degree with this software.
[0] https://www.gnu.org/philosophy/free-sw.en.html [1] https://opensource.org/osd-annotated
You can already see it in the way it describes itself "Flow-based programming for the Internet of Things". So it is "programming" what n8n does not try to be. In Node-Red they give you as a guideline that you should not write high-level nodes if you can write lower-level ones instead (which could build the higher-level one when combined). Which is totally right for programming but not really to allow none coders to automate things. That is also the reason why there are no Asana, Pipedrive, ... nodes in Node-Red. It is simply not what it is made for. It is perfect for IOT applications but not for higher-level automation tasks.
n8n, on the other hand, is probably not the best choice for your IOT application.
So it is simply about using the right tool for the task at hand.
Loosely speaking Node-RED has a superset of the functionality this project has, sacrificing customization/generality for simplicity.
Zapier and n8n interface with the user via a catalog model.
Without needing to know what is going on behind the scenes or seeing any code, a person can follow a recipe and bolt together (certain) APIs to achieve business requirements.
The “certain” is an important to note because you will never achieve 100% coverage for your “API glue” for a mid size to large organization “out of the box” with any tool.
That being said, if using a tool like any of the above mentioned as a custom workflow engine (knowing you will be writing software from the onset) or as a solution and not a limiting factor or “silver bullet”, they can be very useful!
Other tools that can achieve similar results (using Directed Acyclic Graphs, where the nodes represent the execution of your code for a desired pre-programmed task) are Airflow, Flink, NiFi, Dagster, Dagobah, Celery, and many more.
"What is Commons Clause? The Commons Clause is a license condition drafted by Heather Meeker that applies a narrow, minimal-form commercial restriction on top of an existing open source license to transition the project to a source-availability licensing scheme. The combined text replaces the existing license, allowing all permissions of the original license to remain except the ability to "Sell" the software as defined in the text.
This Clause is not intended to replace licenses of existing open source projects in general, but to be used by specific projects to satisfy urgent business or legal requirements without resorting to fully "closing source".
Is this “Open Source”? No.
“Open source”, has a specific definition that was written years ago and is stewarded by the Open Source Initiative, which approves Open Source licenses. Applying the Commons Clause to an open source project will mean the source code is available, and meets many of the elements of the Open Source Definition, such as free access to source code, freedom to modify, and freedom to re-distribute, but not all of them. So to avoid confusion, it is best not to call Commons Clause software “open source.” "
- I'm allowed to setup an instance and charge clients to use it.
- I'm NOT allowed to host the instance for clients and charge for that hosting.
I don't know if X=Zapier here is that effective, but I recognized it right away, and clicked the link to learn more.
I can totally understand if a person says "I do not want to contribute code to a project for free when somebody else can make money with it". But then they can not contribute code to any OSI approved Open Source licensed project. Because with that license everybody can make money with it. And very often is that somebody the wrong one (like for example Amazon).
The only difference with the Commons Clause is that now still somebody can make money. But that somebody is now the entity behind the project. And they normally put that money right back into the project (by for example hiring developers) and make so sure that it improves and stays around a long time. So I personally would prefer to contribute code to a project which uses the Commons Clause then one which does not.
It's not so much that somebody can make money with it. It's that you, the project maintainer, will be reaping all the monetary benefits for yourself. With open source software theoretically anyone can benefit. If you don't like what the maintainer is doing, you can fork it. In this case, though I believe the commons clause does allow you to fork it, you would still be the one reaping any monetary benefits from the fork.
In my opinion the biggest issue with the commons clause is it no longer makes logical sense to fork the project. If the project dies because you couldn't make any money off it, and you don't go back and relicense your work, the code is practically dead as an 'open source' project. Well, that and that the consulting clause seems to be just sitting there waiting for a major court case to decide what it truly means (even the lawyer who led drafting the clause admitted as such [1]).
[1] https://github.com/fossas/commons-clause/issues/4#issuecomme...
I'm planning on releasing my project under similar terms. I'm not particularly interested in community contributions, but rather for there to be trust in ensuring privacy and security. Sometimes, there isn't a one-size-fits-all with the available OSI licenses and I appreciate what op has done to do his best to find what works well for him and the community.
I think developers should pick a license that makes sense for them, not necessarily for the benefit of others. What is important though, is that some thought is taken and to try it out. You can always go more permissive later.
I'm working on something that I want to monetize, but the OSI licenses aren't helpful for the kind of application I'm working on. I'm leaning towards a similar licensing structure and have been spending a great deal of time thinking about this and I hope to have more discussions on this very topic as it's extremely helpful for everyone.
edit: typos
technical note: USD uses commas to denote thousands. So, in USD 30.000 == $30 which isn't worth the time spent to do the research to pick up the first phone call.
Social note: in many US cities $30k isn't enough to survive. In the US it's certainly not enough to live _well_. So, you're basically saying "Hey, I give you permission to make an important contribution to the success and community of this project as long as you're willing to take an absolutely CRAP salary for it."
that's.... not really cool.
I don't think it should matter how much a support person can make supporting your project. The only way a support person will be crazy successful financially is if your tool is ALSO crazy successful. It's a mutually beneficial situation. Don't limit them. Their success is your success.
I guess so yes. At the same time, if someone installs and helps their customers with n8n, in addition to some other bigger more "main" things s/he does, then $30k can be fairly much?
If it's not the contractor's main thing but a smaller part of his/her offerings? ... O.t.o.h. maybe s/he never gets really good at n8n if s/he won't focus on it full time.
Still, I might use this, and thanks for releasing
Great to hear!
OTOH, this is likely to never make it into distro repos anywhere. I also wonder if the author is driving to make a business out of it.
So I'd make three points:
1) It does affect distribution
2) It otherwise doesn't materially affect how I would use it
3) It seems a little like asking for contributions to a proprietary project.
Many enterprises prefer a paid service, as such contracts usually come with somebody assuming liability for data on the system and being around to resolve problems you'd otherwise need to distract an in-house team with.
https://en.wikipedia.org/wiki/Open_source#%22Open%22_versus_...
In my view using the proper vs common version of "open source" places this into a disingenuous attempt to be associated with open source as defined by the OSI.
It is also goes against the site comment's guideline (as well as general sane rule) of: Assume good faith.
I saw "Open Source" and assumed, as I suspect many people did, that it was talking about the Open Source Initiative definition of Open Source. Intended or not, those two words carry a connotation for a lot of people. I'd rather not see that connotation watered-down, either.
Anyway, it's stupid to argue over this. The FAQ on the Commons Clause site itself, reflecting the intention and thinking of the drafter and the initiatiors, specifically states the license is "source-available", not "open source". When talking about open source as a form of licensing as opposed to e.g. software development culture/methodology, the distinction here is quite widely accepted and non-contentious.
For instance, at a previous company we were forbidden to use React until Facebook changed over to the MIT license. Facebook had a poison pill buried into their original "open source" license.
That seems pretty fair - avoids the issues of freelance work being done with the project. I find it hard to care about big corporations not having access to monetize it but that begs the question - doesn't this reduce possible hosting solutions? Especially since there's no official hosting. Does this license imply that there can't be 3rd party commercial hosting?
https://commonsclause.com/ says that I can sell n8n.io as a commercial SaaS product. So I can create and sell a new Zapier using n8n?
That wouldn't be a very comfortable legal position.
I favour the "open source = source available" definition, because that's how most people will understand it anyway. But regardless of where you stand on this, I think it's fair to say it's at least controversial.
"Open Source ≠ open source" is the essence of the problem. The source is open, yet it isn't open source.
Here's an experiment you can run: hold an informal survey amongst a representative subset of programmers. "What does open source mean?". See what they say. I think I met one who knew what the OSI was.
Ironically, "free software" is a similarly terrible term. It should be called "freedom software". I once e-mailed Stallman to ask about it, and he replied they couldn't use that term because it was already trademarked. Welp...
If you're not going by their definition, I think you're just wrong.
Commons Clause does not meet OSI's definition of "Open Source" nor the GNU/FSF definition of "Free Software" so it's fair to say it should not be called either.
https://opensource.org/osd-annotated
https://www.gnu.org/philosophy/free-sw.en.html
https://en.wikipedia.org/wiki/Source-available_software#Comm...
Yes, it doesn't fit either definition, so it shouldn't be called either.
The term 'free software' is hard to keep 'pure', because it has an obvious meaning for people who know nothing about software licensing.
But IMO, the terms 'libre software' and 'open source' should not be diluted. It doesn't serve any purpose to mis-use those terms, except confusing everyone.
The very language I'm writing this to you in is probably the world's most exemplary instance of this principle in action.
Besides, isn't using things in other ways than they were originally intended the essence of The Hacker? ;)
Deceptive tactics.