[HN Gopher] n8n.io - A powerful workflow automation tool
___________________________________________________________________
n8n.io - A powerful workflow automation tool
Author : sacrosanct
Score : 139 points
Date : 2023-08-26 16:06 UTC (6 hours ago)
(HTM) web link (n8n.io)
(TXT) w3m dump (n8n.io)
| dang wrote:
| Related:
|
| _N8n.io - Workflow automation alternative to Zapier_ -
| https://news.ycombinator.com/item?id=21191676 - Oct 2019 (196
| comments)
| bevenky wrote:
| As per its description on github: N8n is a Free and source-
| available fair-code licensed workflow automation tool.
|
| Not really OSS.
|
| Check out: https://www.activepieces.com/
|
| MIT open source.
| [deleted]
| JimDabell wrote:
| 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.
| jholman wrote:
| I'm curious why you bring this up. Sometimes people might bring
| this up because they're correcting a false headline or
| misleading copy in the linked page, but in this case neither of
| those mention "open source" or "free software", so I'm guessing
| it's not that.
|
| My next best guess is that you are implying that n8n's
| licensing is too restrictive, or too commercial, or something
| like that. Is that your point?
|
| If it is your point, could you help me to understand in what
| way the n8n license is restrictive, practically speaking? I
| mean, yes, it's not OSS, it doesn't mean the OS Definition,
| that much is clear, but so what?
| bevenky wrote:
| 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.
| jzb wrote:
| Why the interrogation about pointing out that it's not FOSS?
| ericcholis wrote:
| Anybody have experience with this in comparison to parabola?
| iFire wrote:
| Sustainable Use License
|
| https://github.com/n8n-io/n8n/blob/master/LICENSE.md
| ugur2nd wrote:
| Locale is easy to install and difficult to add to the server.
| alberth wrote:
| What do people use these tools for?
|
| I've yet to find a need for Zapier, etc but know it's hugely
| popular & generates a ton of revenue.
| extragood wrote:
| 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.
| JimDabell wrote:
| 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.
| afro88 wrote:
| 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.
| pacbard wrote:
| 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).
| vbezhenar wrote:
| 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.
| rglullis wrote:
| 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.
| sisve wrote:
| Check out windmill.dev they have auth including sso in their
| open source version. Used it to replace zapier for a lot of
| stuff and quite happy
| debarshri wrote:
| Would you pay of an enterprise version of this platform?
| ulrischa wrote:
| I found n8n some years ago and dexcided to use NodeRed instead.
| It has a large Community and more built in features
| reion wrote:
| 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.
| JimDabell wrote:
| > Still I would recommended to anyone looking for a cheap and
| open source alternative for Zapier.
|
| It's not open source, it's source available with commercial
| restrictions.
| toomuchtodo wrote:
| 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.
| JimDabell wrote:
| It's not about being a purist, the difference was a $50k/yr
| hole in our budget for a license.
| toomuchtodo wrote:
| 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)?
|
| https://docs.n8n.io/choose-n8n/faircode-license/
| JimDabell wrote:
| > 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.
| toomuchtodo wrote:
| 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.
|
| https://en.wikipedia.org/wiki/Gratis_versus_libre
| JimDabell wrote:
| > 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.
| toomuchtodo wrote:
| Great to hear you're sending customers to Zapier, thanks
| for the context.
| JimDabell wrote:
| 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".
| toomuchtodo wrote:
| 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.
| JimDabell wrote:
| > 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:
|
| https://n8n.io/embed/
| aliasxneo wrote:
| I read the home page twice and struggled to figure out the use
| case. Is Zapier what it's typically compared to?
| reion wrote:
| In footer they have n8n vs Zapier and n8n vs Make pages, I
| guess other similar software would be IFTTT
| grotorea wrote:
| 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.
| 01acheru wrote:
| 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.
| BaseballPhysics wrote:
| 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.
| tonyhb wrote:
| 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.
| cpursley wrote:
| Elixir, really? That sounds amazing. So many of these tools
| are TS or Python only.
| tonyhb wrote:
| https://github.com/darwin67/ex_inngest. We'll officially
| support this soon -- it's written by one of our engineering
| team.
|
| 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.
| giovannibonetti wrote:
| 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.
|
| [1] https://elixir-broadway.org/
| fnikacevic wrote:
| 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.
| tonyhb wrote:
| 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.
| input_sh wrote:
| 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.
| iamwil wrote:
| What do you usually automate? I had some before when I was
| working with a friend, but now I struggle to find stuff for
| myself.
| nylonstrung wrote:
| This is an straightforward alternative to Make.com or Zapier vs
| Hugginn has AI agent stuff
| rubenfiszel wrote:
| 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.
| robertlagrant wrote:
| Note: previous commenter is a windmill dev, I think.
| c0brac0bra wrote:
| I'm loving windmill currently. I've been able to automated
| all sorts software painful manual stuff with it.
|
| For a developer, it seems like a great low code tool with the
| right flexibility to write whatever script you need.
| Hnrobert42 wrote:
| 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?
| klysm wrote:
| 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.
| toomuchtodo wrote:
| 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.
| quasiuna wrote:
| 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.
| [deleted]
| smusamashah wrote:
| 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.
| tough wrote:
| docker is a -requirement- only if you plan to use their pre-fab
| stuff
|
| you can just take their dockerfile and run the infra however
| you wish too, probably.
|
| Haven't checked n8n on a while
|
| Actually. says npm OR docker right there in their docs
| https://docs.n8n.io/hosting/installation/
| skripp wrote:
| Maybe Node-RED?
| Towaway69 wrote:
| How does this compare to Node-RED? My impression is that Node-RED
| is more flexible and extendable than n8n but I've hardly used
| n8n.
|
| By the sound of it Node-RED has simpler licensing, its completely
| open source.
| iAkashPaul wrote:
| Always adored tools like this, Isoflow for isometric flowcharts
| is another one that was closed sources but is being opened up one
| feature at a time.
___________________________________________________________________
(page generated 2023-08-26 23:00 UTC)