We're using this tool for some of our project. Basically our manager with zero programming skills was able to build a quite complex backend, which uses postgres, some REST APIs. It runs scheduled tasks and webhook-initiated tasks. It was impressive for me.
One of the downsides is that we have sporadic errors which we just live with, with retries. Probably will be fixed in the foreseeable future.
I, personally, don't have interest with this tool, I prefer proper programming stack. However I can suggest this kind of tool for someone with lacking programming skills (however it's expected that you understand some SQL, some databases fundamentals, some HTTP fundamentals).
We self host it within our kubernetes cluster, it's not a worst thing I had to deal with. Of course free version is quite restricted when it comes to user management, etc, can't even think about oidc integration. But we're cheapos, don't have money for software, so better than nothing.
> I, personally, don't have interest with this tool, I prefer proper programming stack. However I can suggest this kind of tool for someone with lacking programming skills (however it's expected that you understand some SQL, some databases fundamentals, some HTTP fundamentals).
It's an interesting dilemma. End users who are directly generating the requirements can do amazing things when empowered by these tools. But they have zero understanding of some of the unreducible complexities that bedevil almost any system that gets beyond a toy level size. Transactions ... error handling... race conditions ... throttling / load balancing ... computing costs etc etc.
We use Apache Camel for something similar to this and it's a full programming stack (mostly JVM based so you have to be in that scene really). You can get diagrams out the other end. It's not too bad if you want to do all this programmatically. But the end users have zero mechanism to do anything. I wouldn't mind having something that was hybrid and we had a graceful / gradual mechanism to let users build simple things and then onramp them to fully engineered solutions.
The lack of user management was what killed it for me. I was ready to sell it for management when our Zapier bill was growing to equivalent salary of a FTE support person, but it wouldn't work if there was at least no basic separation for accounts.
Totally understandable. We have however basic user management in n8n for quite a while already and it is available for free. Since the beginning of the year we also have built collaboration, that is however a paid feature.
The problem I see in n8n is that a lot of the integrations seem a little half baked. We tried to use it instead of Zapier something less than an year ago:
- you have an FTP node, but it doesn't work with FTP over TLS
- you have an AWS SES node, but cannot attach files to the email
- you have a Salesforce node, but it only has very few options available
Just to name a few that I remember now, we were quite disappointed. It is a great software crafted with care, but the integration nodes seem to be built on a hurry to say "over N integrations available".
Maybe it changed now that it reached 1.0, I don't know but they need to invest a bit into it.
> You may use or modify the software only for your own internal business purposes or for non-commercial or personal use. You may distribute the software or provide it to others only if you do so free of charge for non-commercial purposes.
So basically "source available", but still proprietary.
or, even worse, claiming that other vendors are not upstreaming "material changes" (or whatever the fuck their sleazy phrasing was), while having 200+ PRs in limbo and a "note" in their contributing FAQ about basically pausing PR reviews.
I am maintaining a fairly complex set of nodered flows, dealing with some long running tasks performed by other tools.
When checking n8n the impression was that it's like a v2 of NodeRed that learned from what NR did wrong. Lots of tools an capabilities you end up wishing for in NR are built into n8n.
For example:
* data flow is simplified, no one global "msg" var that gets clobbered by every 2nd custom script
* you can fairly easily test flows
* you can see execution history, including in/out data
* you can see exacting flows
It's more than 10 words and definitely inconclusive as to whether Python or image is more explanatory. The only good thing is that the image is Node-RED "code" and can actually be executed in Node-RED.
Anyone know how this compares to Huginn? I've built out some self hosted automation on Huginn and it works great once it's set up, but it's just a bit janky and difficult to use. And getting initial flows set up can be frustrating as the diagnostics aren't always great.
I haven't tried Huginn in a while, but from my experience n8n can get a bit janky at times as well.
I feel like the sweet spot it hits is neither developer- nor newbie-friedly, but somewhere in between where it's equally bad for both target groups. Workflows get out of hand very quickly, making me need more blocks than lines of Python I'd have to write to achieve the same thing. You need to really understand their logic gates to do stuff, and the docs you'll be relying on range from not great to very bad, incomplete, or just plain incorrect. You'll have to rely on their (Discourse) community forum quite a bit.
If you're one of those people that are strict about open source definitions (I'm personally not one of them), then it's not open source, as you'd need the enterprise license to run it in production for commercial purposes. But, to make it worse, you'll reach some of those enterprise features in your personal projects as well: global variables, Git version control, bash scripts, custom nodes, workflow history (so that you can revert if you mess something up)... all behind an unobtainable license for personal use.
With that out of the way, it is the closest thing to what I want out of such a tool, so I keep on using it despite its flaws. Managing credentials is very easy, you can make custom HTTP requests, sharing and importing workflows is very straightforward, debugging them is easy (most of the time), it's easy to self-host using Docker, it supports many of the APIs I want to use that other similar tools don't (okay some of the cloud ones do, but they're pretty unobtainable .
Overall, I'd say 6/10? It's good, but it could be so much better.
windmill.dev is a modern take on Huginn: optimal performance, great DX, scale to any cluster, work with python, typescript, go, bash, and flows that are more powerful.
n8n is great because their UX is simple and they have many well-made integrations, including an automatic way of setting up the webhooks in your github account for instance to trigger automation on changes to your repo.
Windmill is less about having many integrations, and more about being able to write real code-based workflows, running on your infra and with potentially long-running jobs that you can assign easily to bigger nodes. It's a compromise between n8n and temporal for the workflow part.
Anyway, n8n was a precursor in many aspects and a great inspiration for all of us building workflow engines.
RE. initial flows and diagnostics, I totally feel your pain. Part of the trouble with these systems is that they're too different from our average SDLC we have every day:
- Write regular code
- Test locally
- Then deploy
This is one of the key aspects we're fixing at https://www.inngest.com — you can write regular TS (or Go, or Elixir) code as a function, create simple workflows, test locally, and have your functions automatically triggered by events.
I still think there's room to go with improving automations here, and it's going to be an interesting few years as things develop.
The SDKs are lightweight, work in any language (we only support a few right now), and you can live-migrate long running functions across languages at any time. Long running state is automatically transferred across those SDKs.
One of our foundational aspects is to make long running state, queues, events really easy, and that means we need to make multi-cloud and multi-lang migrations easy, too.
Transferring state across sdks sound very cool, how do you achieve that?
With all the workflows as code frameworks (like say, Temporal), this is what I imagine to be a shortcoming. With regular services + state in database implementations, you can query the database separately. While with a temporal workflow, you can't cleanly figure out where a particular workflow run is atm since the state is an append only stream of events?
For Elixir, you might be interested in Broadway [1], described in their website as "Build concurrent and multi-stage data ingestion and data processing pipelines with Elixir." It is maintained by Jose Valim's consultancy company, so it should be pretty good. I'm looking forward to using it in a project at work soon.
Sorry for the loaded question, but can you share examples of companies using inngest in production and roughly what scale? Your product appears to fill the exact gaps in Supabase's current offering.
Yeah, for sure. Individual companies run tens of millions of functions a month across anything as basic as braze-like customer lifecycle emails (https://www.inngest.com/blog/lifecycle-emails-with-resend) to running complex AI workflows at scale.
The basic premise is that you can send Inngest events (for free) then start writing functions hosted in your own API at any time, with local testing, branch deploys, etc.
My favourite is a flow to pull HTML-formatted newsletters out of my email and push them to Wallabag. I then use Wallabag's RSS feature with Calibre to turn them into an ebook I can read on my Kindle.
My other major use case is centralized notifications. For a lot of things (e.g. backups), I have a webhooks in Huginn that then push out a notification via Gotify to my phone.
I've also used Huginn to scrub/clean up RSS feeds, since it can pull the feed, apply transforms to it, and then republish it.
This sounds fine but what is this doing that a bash script + cronjob doesn't? Isn't all of this functionality available in CLI tools (and in fact you're likely already using them, e.g. making calibre convert the HTML newsletter to .mobi).
I ask because I'm also curious what I can use these sort of tools for. I installed Node Red before and other than visual smart home automation, was at a loss of ideas. As someone who can write bash scripts (and nowadays ChatGPT does all the scripting for me), how can they make my life easier?
I think you're underestimating the effort involved in writing something to poll an IMAP folder, checking for new emails, pull the right mime attachments, etc, etc, and then turning around and post them to the right place.
Yeah I could write some Ruby or Python or Perl to do the job but I can also spend way less time and use something like Huginn to do it for me.
Honestly, your argument could apply to virtually anything you might do with something like Zapier or equivalent. Nothing they do can't be done via scripting. The point is these tools simplify the grunt work so you can go from idea to implementation much faster, with proven code that you don't have to write and maintain yourself.
I have been using n8n for over a year. I prefer it over popular Zapier as it gives me more flexibility and I am able to self host. It have its quirks that you learn about only when you work enough with it to look up solutions on community forums. The only thing I wouldn't recommend is their Cloud, it seams more buggy/unstable than my self hosted instance (more timeouts, probably to conserve shared resources). Still I would recommended to anyone looking for a cheap and open source alternative for Zapier.
Right, you can run it yourself or pay n8n to run it. For purists the language matters, realistically for users it does not. You’re not locked into the SaaS platform is the point.
I assume because you were not running it for internal business only but were attempting to distribute or white label/SaaS it? Isn’t $50k about 3-4 months of one dev’s time (assuming fully loaded costs)?
> I assume because you were not running it for internal business only but were attempting to distribute or white label/SaaS it?
Yes, we wanted our customers to be able to set up integrations themselves. We didn’t care about white labelling it, we just needed to a) modify it, b) self-host it, and c) use it commercially. Something that open source is ideal for.
> Isn’t $50k about 3-4 months of one dev’s time (assuming fully loaded costs)?
Yes but that means absolutely nothing if you don’t have the budget for it, or even if you do have the budget for it but there are more valuable things for your developers to work on, or if you do have the budget for it but it isn’t worth that much. In our case the value provided by n8n wasn’t anywhere near $50k/yr. And, more to the point, $50k/yr is $50k/yr more expensive than open source. It would have been worth using if it had been open source, but it wasn’t worth using at that price.
Right, so it prevented freeloading. It’s working as intended. Still usable for those who want to eject from the hosted platform, but if you make money from it, n8n should get paid for that value. You’ve proved the point of why open source would’ve been a suboptimal license for them to use.
Open source was intended as free as in speech, not free as in beer. “Open source because I don’t want to pay something” is…not great.
> if you make money from it, n8n should get paid for that value.
We weren’t really expecting to make any money out of it. We already have a Zapier integration that our customers were using. We just wanted things to be a little bit easier for our customers. Does this have an indirect impact on our profits? Sure, I guess marginally. Enough to justify a $50k/yr license fee? Nope, not even remotely close. Our customers can carry on using Zapier.
> You’ve proved the point of why open source would’ve been a suboptimal license for them to use.
They didn’t get paid either way, the only difference was we send all our customers to their competitor now. Which also isn’t open source, of course, but Zapier has the brand recognition and reach n8n doesn’t. Everybody knows Zapier, a lot of customers ask for it specifically. Nobody asks for n8n. I don’t want to make the “you’ll get paid in exposure” argument, but in practical terms, the only difference to n8n in our particular case was they had a chance to stop us sending customers to Zapier. They never had the opportunity to earn money from us directly, only to get us to stop sending customers to their competitor.
If n8n want to license their product in that way, that’s up to them. It’s totally their right to do so. But it’s not open source and this is a big issue for some potential users here. Discussion about that belongs here, especially when people are saying that it’s open source.
> Open source was intended as free as in speech, not free as in beer.
You’ve misunderstood that. Open source and Free Software includes both. Open source was originally promoted as the commercially-attractive alternative to Free Software.
I don’t have specific numbers to hand, so assume any percentages below are inflated placeholders.
Let’s say 10% of our customers explicitly ask for Zapier integration because they are already Zapier customers. A further 20% have the expressed need for some third-party automation that we don’t directly support, but is supported through Zapier. And a further 30% could benefit from it but have no idea this kind of thing even exists. 0% ask for n8n. 0% have even heard of n8n.
Well we need to build the Zapier integration to keep that 10% happy. Now that we have that integration, we can turn to the 20% that need something like this and tell them to sign up for Zapier, and then they will be happy too. Then we can publish how-to articles and give a nice surprise to the other 30%, who will also go and sign up to Zapier.
There’s friction here. Some customers will fit in Zapier’s free tier and others will have to pay extra. The process for hooking Zapier up to our product is clunky. And every time the customer wants to change some aspect of their automation, they have to leave their product dashboard and go to an external service.
The goal was to self-host n8n so that customers could keep doing everything within our product. Most of the 10% existing Zapier customers would carry on using Zapier; some would switch. We wouldn’t need to send customers over to Zapier to keep the 20% of users asking for something like this happy, and the how-to articles would help the other 30% without sending them to Zapier as well. Some of our customers would save money by not having to pay Zapier, for others it would make no difference. Our customers would be able to manage their integrations without going off to some third-party site.
You can see how this is a desirable thing for us to do. You can also see that the value to us is way, way, way below $50k/yr. We aren’t going to gain or lose any customers over this. The main difference for us is marginal UX improvements.
n8n received $0 from us. If n8n were open source, they would still receive $0 from us. The difference is that we wouldn’t be sending 50% of our customers to become new Zapier customers. n8n would have gained one small integration – us. There’s no point in us building an n8n integration when we have Zapier though, because nobody is asking for it and Zapier does everything we need and has more integrations. It’s also possible that we / our customers would add to the other n8n integrations if we needed them or contribute functionality or bugfixes, but again, that’s veering a little to close to the “payment in exposure” argument I dislike.
As I said before, if n8n want to play things this way that’s their prerogative. But somebody here was telling people that it’s open source when it’s not. It being open-source or not is a big deal for cases like ours; it’s not “purism”.
I suppose I don’t understand why you couldn’t build an integration with n8n solely with generic webhooks vs having to bring a copy of their software into your stack. You didn’t need a copy of Zapier to integrate with Zapier (although you mentioned it was a clunky integration, I’m sure the Zapier folks would be interested in feedback on how to improve there).
It sounds like n8n needs to offer a library under a different license to smooth this integration issue? Correct me if I’m wrong there.
Email in profile if you’d rather have the convo there. I’m very interested in smoothing the integration story for all workflow providers, and I misunderstood your use case that you were trying to bring the entire software app in to support your integration.
> I suppose I don’t understand why you couldn’t build an integration with n8n solely with generic webhooks vs having to bring a copy of their software into your stack.
It’s a better user experience for customers. They don’t have to sign up for some third-party service, they don’t have to pay for some third-party service, they don’t have to mess around with API keys or onboarding flows, they don’t have to go to a third-party service to configure how things work, they don’t have to manage their admins separately, etc.
Sure, we could integrate with n8n the same way we integrate with Zapier. But why would we? We already have Zapier for that. And our customers ask for Zapier. And they’ve heard of Zapier. And Zapier has more than 10x number of integrations. There’s no benefit for us to replicate what we already have with Zapier using n8n. The benefit of n8n was closer integration, but in order to get that we would have to spend $50k/yr which simply wasn’t worth it for us.
I don’t think the problem can be solved with a differently licensed library. n8n explicitly considered this use case and this is how they want things to work:
>Is a person that uses Linux or FreeBSD without paying for it also a 'freeloader'?
A few times? No. All the time, without ever giving back? Yes. It's the truth.
It's not about money specifically, it's about contributing to the open-source movement in general. This movement is why desktop and server computing is as open as it is and we're not all renting our dev tools and OSes for a monthly fee to one of the dystopian tech giants.
It's like if you joined a commune where they provide you with a room and meals at no cost. They tell you you can stay as long as you want. If you're still there after 2 years, you don't think you oughta give something back?
Users of free and open source software also give back by contributing feedback, bug reports, and patches. They promote the software through word of mouth and offer support to other users, building a community that extends the longevity of the software. The FOSS movement encompasses more than monetary payment in exchange for software, and it is not "freeloading" to use software exactly as prescribed by the license the developers selected.
While n8n is not open source, n8n is at least upfront about its business model and does not falsely brand itself as open source, which is more than can be said about some other companies.
I've worked in open source for two decades and something that I've observed that I think is as close to a law (as in law of physics) as anything I've seen is the 90 | 9 | 1 ratio.
90 percent of any community - the Hacker News community, reddit, x, or any open source community - will be passive consumers.
9 percent will be contributors - as the reply below says, through feedback, testimonials, bug reports and the like.
1 percent will be creators - new features, innovations, fixes.
This is the way it is. "Freeloading" is a very very unfortunate term and I wish it had not been inserted into the popular lexicon. The creators of open source that I know WANT their software to be used.
IFTTT is target more at personal usage while the others are more professional or more complex uses. n8n is, as the starting page, open source and self-hosted unlike those two.
Looking at self hosting, one of the requirements is docker. Is there another tool with similar UI to automate workflows on your computer locally (windows, Linux etc)? I just realized there are a few very good android automation tools which monitor various states and can act on apps and settings but I haven't seen anything that intuitive for windows.
Docker is the ultimate application format for Linux. It IS Linux. If you read a Dockerfile, you can replicate it on a fresh install command by command, it serves as doc too. For example if it says "FROM debian:bookworm RUN apt install nginx blah blah" you can just repeat those steps on Bookworm. It's just the developer already that work for you so all you need to do is run "docker run -dt sometool:sometag" and presto it's all running on your PC.
Dockerized apps run with almost no overhead, it's not like using a VM.
Take 2 hours to learn it, trust me it's worth it. This isn't some "Cloud Scale!" hype. It's useful even for someone with just a Pi at home. Just stick to the basic Docker commands (exec, run, compose if you want to be fancy). Don't bother with that Google-scale stuff like Kubernetes unless this becomes your career.
I believe Node-RED (https://nodered.org/) is the way to go. It's just an NPM package to install and you can run it how ever you wish (even on Windows). It has a friendly and helpful community with even the main developers tirelessly answering even beginner level questions. In fact the community forum its THE friendliest forum I've ever been a member of by a large margin. Node-RED's development is supported by the JS Foundation and it's completely free and open source. It's widely used in the industrial automation industry and even integrated by some PLC manufacturers such as Siemens.
Docker is actually not a requirement. You can also run it directly with npm. You can even start it for testing (when you have npm installed) simply by typing "npx n8n".
Let’s say you’re building a software product. When something happens in your product (maybe somebody buys something, or shares a link, or creates an image, etc.), some of your customers want something to happen in response. Maybe they want the user to receive an email, maybe they want something to be posted to social media, etc.
Normally you would have to integrate with each of those third-party services directly. With n8n, Zapier, etc., you can write one integration and let your customers decide what to plug it into. So you get thousands of integrations “for free” by integrating one service.
The same goes in reverse – maybe something happens in a third-party service and your customers want something to happen in your product as a result. Instead of requiring all those third-party services to integrate with you, they can just integrate with n8n, Zapier, etc.
Because services like n8n and Zapier provide a common interface between very different services, it sidesteps a combinatorial explosion of integrations needed to wire everything up to everything else explicitly.
For instance “when somebody buys something from our Shopify store, I want to add them to a private Slack channel”. Shopify aren’t going to spend time building an integration like that, Slack aren’t going to spend time building an integration like that, and a customer isn’t going to want to commission bespoke software to wire it all up. But if they both integrate with n8n or Zapier, then customers can do it themselves.
I'm pretty sure OP was asking about the end user use cases. But I appreciate your reply because I'm developing a product and this made something click for me about letting users integrate with other things with minimal effort.
My company has "apps" on n8n, Zapier, and Make. I've used them all and they're fairly similar: they make integration of supported platforms easy and support simple automation workflows.
E.g. if x happens on y platform, get relevant data, process it, send me a text message if it's during the day or email me if it's at night/weekend.
It's frequently faster than building out the integrations yourself, and is more accessible to inexperienced programmers/ less technical folks.
In terms of ease of use, I'd rank it: Zapier (top), Make, n8n. Same ranking for available apps. Complexity of workflows I'd rank those in reverse though. You can do more with n8n.
I use it for some webhook stuff to put together an RSS feed for a website that doesn't provide one. I didn't want to have to code up a web app just for it.
N8N comes with a webhook listener, and it was easy enough to cobble something together with the built-in nodes and coding custom ones with javascript (they just released a python node that I haven't tried yet).
Thanks for this. We had previously evaluated n8n a year ago and couldn’t use it because it wasn’t open source and they wanted to charge us $50k/yr. I wasn’t aware of ActivePieces, will check it out.
Thank you for this recommendation. I was looking for a FOSS replacement for n8n with a similar user interface and feature set, and Activepieces seems to be a great fit.
Its the latter. The project does good work so don't want to dump on the project.
When one sees source code on Github, one assumes that its OSS, but its not and thats why I share that.
The license is a fair code license and it says "is commercially restricted by its authors" and its not clear what commercially restricted really means here.
Thanks for doing this. I found n8n 2 days ago and was working on integrating it but just found that their "license" is too much. I was going to integrate it on my platform and sell their product as an affiliate but that license is a no-go.
I really want to like these tools. Yet every time I consider Zapier or IFTTT, their integrations are a mile wide and an inch deep. I’ll see that they integrate with XYZ corp, but then it’s only with a handful of endpoints.
Like say I wanted to gather attendees from my Google Meet, Zoom, Webex, etc and send them to salesforce. I’d look at Zapier and see they work with Google. Then I’d look for Google Meet and see there’s nothing there.
I get that these connectors can only integrate with existing endpoints. I’m not criticizing. I’m just confused. How do people actually use these services?
We’ve used N8N for about 2 years, at scale, in production, self-hosted on a VM with docker compose. It’s phenomenal.
We run every piece of client-specific custom integration work through it.
Plumbing a few systems together is a piece of cake - either triggered by webhook or scheduled cron-like.
There are tonnes of out the box nodes for common services, but for everything else the JavaScript code block and HTTP request nodes fill in any missing gaps.
We’ve tried Zapier, Integromat and loads of others - N8N has nailed the UX for us.
I find that these services are typically used to implement shitty half broken database replication. It’s obvious to anybody that’s worked on that sort of problem that it’s a fools errand and is going to result in terrible, brittle, untrustable data. However, their marketing and product success depends on you not knowing that.
Simple integrations that would otherwise require dev time to build and maintain. As long as the workflows last just long enough for the value they’re providing, it’s a superior solution to a bespoke build.
One of the downsides is that we have sporadic errors which we just live with, with retries. Probably will be fixed in the foreseeable future.
I, personally, don't have interest with this tool, I prefer proper programming stack. However I can suggest this kind of tool for someone with lacking programming skills (however it's expected that you understand some SQL, some databases fundamentals, some HTTP fundamentals).
We self host it within our kubernetes cluster, it's not a worst thing I had to deal with. Of course free version is quite restricted when it comes to user management, etc, can't even think about oidc integration. But we're cheapos, don't have money for software, so better than nothing.