n8n Open Source: What Fair-Code Licensing Limits

What licence does n8n open source actually run on?

n8n open source is the label most teams reach for without checking it. n8n’s source code is public on GitHub, and you can download it, self-host it and read every line. That’s usually where people stop looking and file it under “open source.” It isn’t, not in the sense the term has carried since the Open Source Initiative defined it in 1998.

n8n publishes its self-hosted software under a fair-code licence, specifically a sustainable use licence model. Source-available and free to self-host are both true. Unrestricted in every way an MIT or Apache 2.0 licence would be is not true. The gap between those two things is what this article is about, and it matters more than most self-hosting guides let on, because the gap is a business decision, not a technical one.

This isn’t legal advice. It’s a map of the distinction so you know what question to ask, and when to stop asking a blog post and start asking someone qualified.

Fair-code sounds like open source. It isn’t quite.

Open source, in the OSI sense, means a licence with no restriction on who can use the software or what for, including running a competing commercial product on top of it. GPL, MIT and Apache 2.0 all qualify, even though they differ wildly on what you owe back to the community.

Fair-code is a newer category built specifically to close the gap that open source licences leave open: a large company can take a genuinely open source project, host it, and sell access to it without contributing anything back or paying the people who built it. Several source-available automation and infrastructure tools have moved to fair-code or similar licences for exactly this reason.

The practical result for n8n is that the software is transparent and self-hostable, but the licence carries a use restriction rather than none at all. What that restriction actually says, in its current wording, is something you need to read directly in n8n’s licence file rather than infer from a summary, because licence text changes and a paraphrase from last year can be stale by the time you rely on it.

What the licence restricts if you’re running n8n internally

If you’re a $3M–$30M ecommerce operator using n8n to wire together your own order data, your own customer service triage, or your own AI agents inside your own stack, you’re almost certainly in the use case fair-code licences are built to protect, not restrict. Running workflows for your own business, on infrastructure you control, without selling access to the workflow engine to anyone else, is internal use.

Self-hosting is free of a per-seat or per-workflow licence fee under the current open source terms, you can modify the source for your own deployment, and you can run as many internal workflows as your infrastructure supports. None of that changes because the licence isn’t OSI-approved. The restriction isn’t aimed at you doing your own automation. It’s aimed at what comes next.

What the licence restricts if you want to resell it

The line moves the moment n8n itself, or a product built directly on it, becomes something you sell rather than something you use. Fair-code licences typically restrict offering the software as a hosted service to third parties, or building a competing commercial product on top of it, without a separate agreement with the vendor.

For an ecommerce operator this shows up in a specific, easy-to-miss way: not “are we reselling n8n,” which nobody thinks they’re doing, but “did the automation engine end up embedded inside something we charge other businesses to use.” An agency running client workflows on its own n8n instance, on its own behalf, is a different fact pattern from a SaaS product where n8n is the engine customers are paying to access, even indirectly. The words “internal use” and “commercial use” both sound self-explanatory until your actual architecture sits between them.

How to check where your n8n use stands under the licence

Step 1: name your deployment mode

Write down, plainly, who runs the n8n instance and who benefits from it. “We self-host n8n and it automates our own store’s operations” is one sentence. “We self-host n8n and other businesses interact with workflows we built on it, and pay us for that” is a different sentence. Most teams can answer this in a minute once they’re forced to write it down instead of assuming it.

Step 2: check who is actually paying for access

The test isn’t who touches the n8n interface. It’s whether a third party is paying, directly or as part of a bundled fee, for access to functionality that n8n itself provides. A customer paying you for a service you deliver using n8n internally sits closer to internal use. A customer paying for a product where n8n is the visible or interchangeable engine sits closer to the restricted case.

Step 3: read the current licence file, not a summary

Licence wording is versioned and does change. Pull the licence file from the same n8n repository and release you’re actually running, not a cached memory of what it said. A summary, including this one, is a starting point for the question, not the answer to it.

Step 4: decide if a workflow crosses into “hosted service” territory

Look specifically for the case where a customer or partner never signs up for n8n themselves, but effectively gets n8n’s functionality through your product. That’s the pattern fair-code licences are written to catch. If you find it, that’s the trigger to move from reading to asking.

Step 5: get written confirmation for the edge cases

If step 4 turns anything up, or if your business model is an agency or platform play built around workflow automation, get the specific use case confirmed in writing, either through n8n’s commercial licensing team or counsel who has read the current licence text against your actual product. A verbal assumption isn’t a defence.

The step most teams get wrong

The mistake isn’t ignoring the licence. Most operators at least know it exists. The mistake is applying the internal-use conclusion to a use case that quietly stopped being internal.

A drift like this happens gradually. A team self-hosts n8n to automate their own operations, confirms that’s fine, and stops thinking about the licence. Eighteen months later, the same n8n instance is running the automation behind a client-facing service the company now sells, or a workflow a partner’s customers depend on directly. Nobody re-asked the licence question, because nobody flagged the moment the architecture changed. The licence didn’t move. The product did.

If your team ships anything that touches n8n’s workflows externally, put a recurring check on it, tied to product releases rather than to a calendar date, so a new integration doesn’t slip past the question that mattered the first time.

How to verify you’re still compliant after the fact

Verification here isn’t a technical test you run against the software. It’s a documentation habit: keep a short, dated record of what your n8n instance does, who has access to its outputs, and whether any third party pays for anything that depends on it. Revisit that record whenever you ship a new integration, not on a fixed schedule, because the trigger is a product change, not time passing.

If the honest answer to “does anyone outside our own business pay for access to something n8n provides” is yes, that’s the point to stop relying on a summary article and get the specific case read against the current licence text.

What n8n Cloud and enterprise licensing change

n8n also sells hosted and enterprise plans that sit outside the fair-code question entirely, because they’re a direct commercial agreement rather than the self-hosted open source terms. If your actual need is a hosted instance, dedicated support, single sign-on, or a use case you already know falls into the commercial category, that path exists precisely so you don’t have to reason about fair-code restrictions at all. Check n8n’s own current pricing and plan pages directly for what those plans include, since plan names, limits and terms change and a stale description here would be worse than none.

Why this comes up in a security review or an acquisition, not just a legal chat

The licence question sounds academic until someone outside your team asks it formally. An acquirer’s due diligence checklist and an enterprise customer’s vendor security review both ask, in some form, “what does your stack depend on, and under what terms.” A dependency on fair-code software isn’t disqualifying — plenty of acquired and audited companies run on it — but an unclear answer is a flag in a way a clear one isn’t. “We self-host n8n for internal automation, confirmed against the current licence, documented” closes the question in one line. “We use n8n, I think it’s open source” invites a follow-up, and follow-ups in due diligence cost time you don’t get back. If you’re building toward an exit or selling into enterprise accounts that run their own vendor security process, a short dated record of what n8n does, who touches its outputs, and whether any third party pays for anything downstream of it is the thing you hand over, not something you reconstruct under deadline.

The community maintaining the nodes you’ll actually use

n8n’s core is fair-code, but a meaningful share of what makes a given workflow possible is the node library, and a chunk of that library is community-built rather than n8n-maintained. Anyone can publish a custom node that talks to a specific API n8n doesn’t cover natively, and a fast-moving ecommerce stack — a niche shipping carrier, a regional payment processor, a smaller review platform — is exactly where you end up relying on one. That’s a genuine strength of a source-available, actively used project: coverage grows faster than any single vendor could fund. It’s also a dependency risk worth naming plainly. A community node maintained by one person, as a side project, can go stale the moment that person moves on, and a workflow built around it inherits that risk silently until the underlying API changes and nothing updates to match. Before you build a production workflow around a community node rather than a core, n8n-maintained one, it’s worth checking who publishes it, how recently it’s been updated, and whether the same integration is common enough that you could fork and maintain it yourself if the original author stops. That last option is only available because the source is visible — which is the next point.

Reading the code is a debugging tool, not just a licence footnote

Source availability has a practical payoff that has nothing to do with the licence category: when a workflow breaks in a way the UI doesn’t explain, you can open the node’s actual code and see what request it sends, what response shape it expects, and where it’s silently swallowing an error. With a closed-source automation platform, a broken integration means opening a support ticket and waiting. With n8n, it means the option — not the obligation — to read the exact HTTP call a node makes, patch it locally if you’re comfortable doing so, or at minimum diagnose precisely where a third-party API changed underneath you. This doesn’t require touching the licence question at all; it’s a property of source-available software generally, distinct from whether you’re also permitted to resell it. Teams that never plan to build a commercial product on n8n still get real value from this — faster incident resolution on the automations their own operations already depend on.

What actually changes if n8n changes its licence

Fair-code and source-available projects have changed licence terms before, across the industry, usually in the direction of tightening what a large hosting competitor can do without paying, not in the direction of restricting a small operator’s internal use. There’s no way to promise n8n won’t adjust its terms again, and a summary written today is a snapshot, not a guarantee about the future. What reduces your exposure to that risk isn’t predicting the change, it’s keeping your architecture loosely coupled to begin with: treat n8n as a workflow orchestration layer sitting in front of your own data and your own APIs, not as the system of record. If your order data, customer records and business logic live in your own database and your own services, and n8n is the automation layer wiring calls between them, a licence change that affects what you can do with n8n itself is a migration project, not a rebuild. Teams that embed n8n so deeply that ripping it out means rewriting core business logic have taken on a different, larger risk than the licence question itself — and it’s the one worth budgeting against, because it’s the one a licence change would actually hurt.

Where this sits next to other source-available tools you may already use

If this is the first time your team has run into a fair-code licence by name, it’s worth knowing the shape isn’t unique to n8n. Source-available, use-restricted licensing has become common across infrastructure and developer tooling generally — databases, search engines and monitoring tools have taken similar paths, typically source visible, self-hosting free, and a restriction aimed specifically at a hosting competitor reselling the software as a managed service. If your stack already includes a tool under one of these models, the mental checklist is the same one this article walks through for n8n: are you the end user of the software, or are you the one selling access to it. Operators who’ve already cleared that question for one tool in their stack usually find the n8n version of it faster to answer, because it’s the same distinction wearing a different vendor’s name.

Who this article is not for

If you’re under the $3M revenue floor, the licence question is rarely the binding constraint yet — you’ll hit operational and cost limits on self-hosting before you hit a commercial-use edge case worth formal advice. If you’re already paying for n8n Cloud or an Enterprise agreement, you’re operating under different, explicit commercial terms and most of the fair-code analysis in this article doesn’t apply to you directly. And if your actual question is “how do we get n8n running reliably” rather than “what does the licence allow,” that’s a self-hosting operations question, not a licensing one, and belongs in a different article.

For everyone else — a $3M–$30M ecommerce operator self-hosting n8n for internal automation, with a product roadmap that might eventually touch a customer-facing feature — the licence question is worth five minutes now, because it’s cheap to answer early and expensive to unwind after a product ships. That’s a governance question as much as a legal one, and it sits inside the same decision as which workflows you let an AI agent run unsupervised and which you don’t. Pointerflow’s AI agents work starts with exactly that boundary: what an agent or an automation platform is trusted to do on its own, and where a human or a formal agreement needs to sit in the loop first.