STaurtomation/docs/research/reports/n8n-gated-features-reimplementation.md

Ported from earlier research (2026-10-29) and sanitized for clean-room use: source-code-derived details removed. Not legal advice.

Rebuild n8n's paywall, but never inside it

Not legal advice. This report synthesizes license texts, case-law summaries, public documentation and pricing pages. Supporting detail is in notes/n8n-licensing-legal.md and notes/n8n-feature-feasibility.md. Before you rely on any of this commercially, have a lawyer review the plan, ideally one who knows both German and US software law.

A clean-room reimplementation of the features n8n gates behind its paid plans is legally and technically feasible. How safe it is depends on where the new code runs and who receives it, not on how good the code is. Copyright protects n8n's code but not its features. An independently written product that offers SSO, RBAC, Git environments, log streaming or external secrets, and is perhaps even compatible with n8n's workflow JSON, stands on firm ground in both the US and the EU. The danger begins once your code runs inside n8n. Files that n8n's license marks as Enterprise Edition are under a proprietary Enterprise License that assigns your modifications to n8n. The rest of the code is under the Sustainable Use License (SUL), which permits modification only for internal, non-commercial or personal use and permits distribution only free and for non-commercial purposes. Several features look gated but are already free on a self-hosted instance: execution retention and pruning, queue mode, concurrency limits and Prometheus metrics. Others can be approximated well with external tools: Git environments, workflow history, log shipping, insights and secrets injection. The recommendation is to start with external tooling and sidecars, which carry the lowest risk. Move to a purpose-built alternative if you need real RBAC and SSO without paying. Pay n8n if you need n8n itself with those features in production. Do not fork n8n unless you are an internal-only user and willing to carry a large maintenance burden and real legal uncertainty. For STaurtomation, the relevant path is the independent clean-room product (path 3 below).

Two licenses split the repository along a filename boundary

n8n is not open source by its own account. It says that "open source licenses can't include limitations on use, so we do not call ourselves open source," and it calls its model "fair-code" (n8n docs). The project moved from Apache 2.0 plus Commons Clause to the SUL on 17 March 2022 and added an Enterprise License in August 2022 (n8n docs; LICENSE.md history). The SUL grants rights to "use, copy, distribute, make available, and prepare derivative works." It then limits them to three things: use or modification "only for your own internal business purposes or for non-commercial or personal use," distribution "only if you do so free of charge for non-commercial purposes," and no altering or removing "any licensing, copyright, or other notices" (LICENSE.md). The termination clause says that use in violation "is not licensed." That wording makes the limits look like scope conditions rather than mere promises. Under the US MDY v. Blizzard condition-versus-covenant analysis, use outside those limits could therefore be copyright infringement and not just breach of contract (InfoLawGroup).

One drafting detail matters a great deal. The SUL is visibly modelled on the Elastic License 2.0, which shares its notice and patent sentences word for word. ELv2 also says "You may not move, change, disable, or circumvent the license key functionality... and you may not remove or obscure any functionality... protected by the license key." The SUL omits that sentence (Elastic-2.0 SPDX; LICENSE.md). n8n's FAQ takes a stricter view than the plain text and lists "Use enterprise features that ask for a license key without an Enterprise license" and "Fork n8n's code to launch your own automation product" as not allowed (n8n License FAQ). An FAQ is not the license, and ambiguous standard terms are usually construed against the drafter. Still, this gap between the text and n8n's stated position is the least settled question in the whole analysis. The SUL also has no governing-law clause, so it is unclear whether German, EU or US law would decide a dispute.

The Enterprise License is much stricter. Production use requires "a valid n8n Enterprise license." Copying and modification are allowed for development and testing. n8n "retain[s] all right, title and interest" in any modifications or patches, and copying, publishing, distributing and selling are otherwise forbidden (LICENSE_EE.md). The SUL's scope preamble defines the boundary only by filename: files carrying an "ee" marker in their file name or directory name. Two practical consequences follow. First, anything derived from Enterprise-licensed code is effectively n8n's property. Second, the "development and testing" carve-out lets engineers read that code lawfully, but anyone who has done so has disqualified themselves from a clean-room team. For STaurtomation the rule is stricter still: no n8n source, of either license, is read by implementers.

Copyright doctrine favors reimplementation; contract and enforcement history set the limits

The doctrine strongly supports rebuilding features. The CJEU's SAS Institute v. World Programming (C-406/10, 2012) held that "the functionality of a computer program... and the format of data files" are ideas that copyright does not protect, and that a lawful licensee may "observe, study or test" a program to determine those ideas (Fieldfisher). EU Software Directive 2009/24/EC makes contract terms that override those study and interoperability rights void. The research team quoted those articles from memory, so check them against the text (EUR-Lex). In the US, Google v. Oracle (2021) held that reimplementing about 11,500 lines of Java API declaring code was fair use, although commentators read the decision narrowly (Jenner & Block). The main US counterweight is Bowers v. Baystate (Fed. Cir. 2003), which enforced a contract ban on reverse engineering beyond what copyright requires (Wikipedia). That matters less here than it might seem, because the SUL contains no term prohibiting study or independent reimplementation. Even a licensee who builds a competing product from scratch breaches nothing.

Anti-circumvention law is a weaker threat than it first appears. Asked in its May 2025 DMCA notice whether it had "technological measures in place to control access," n8n answered "No" (GitHub DMCA 2025-05-27). Platform policy is a separate matter. GitHub bans "software for bypassing checks for product licensing keys" regardless of statute (GitHub DMCA policy). Trademark is simple: the SUL grants no trademark rights, n8n has a US application for "N8N" (Justia), and its takedown explicitly complained that the fork had "used our name". Use your own name and limit references to nominative statements such as "compatible with n8n workflows."

Enforcement so far has been selective and has relied on platforms. The only license-enforcement action on record is the May 2025 DMCA takedown against a fork that combined the three highest-risk factors: n8n's name, redistributed Enterprise-licensed code, and public npm packaging. n8n's complaint was that it "made all our paid Enterprise features freely available, which is obviously not allowed, as that code has a different license" (GitHub DMCA). The framing is about Enterprise-licensed code, not about touching gates as such. Other "unlocker" forks that redistribute n8n's Enterprise code exist; they are outside the Enterprise License, and they are deliberately not named or linked here. A different pattern is the sreent/n8n fork ("tuflow"), created in September 2026, which claims to delete all enterprise code, rebuild the features, rebrand, and stay "for internal business use only." There is no recorded n8n response, and its clean-room claims have not been audited. It is prior art only: its code is a derivative of n8n source and must not be read or copied by STaurtomation contributors. No court has ever interpreted the SUL. One caution from a comparable case: in 2024 HashiCorp sent OpenTofu a cease-and-desist claiming that reimplemented functionality copied BSL code (OpenTofu). Accusations happen even when the reimplementation is legitimate, so provenance records are what protect you. Unlike Elastic and Redis, n8n has no permissively licensed past version to fork. Its pre-2022 code was already under Commons Clause, so the OpenSearch and Valkey escape route does not exist.

Documented extension points of stock n8n

This section is relevant only to the "external tooling" path (running unmodified n8n); it is not a design input for STaurtomation. The documented, ungated ways to extend or integrate a self-hosted n8n are: community nodes; backend external hooks loaded via EXTERNAL_HOOK_FILES (documented hooks include n8n.ready and frontend.settings); credential overwrites (CREDENTIALS_OVERWRITE_DATA / CREDENTIALS_OVERWRITE_ENDPOINT); the public REST API (/api/v1/... with an API key); CLI export and import; and direct database access (external hooks docs). The docs describe no built-in trusted-header or forward-auth login. Seamless proxy SSO therefore needs an in-process hook that turns a verified identity header into an n8n session. One NixOS deployment does exactly this with oauth2-proxy and Kanidm (thalheim dotfiles), and cweagans/n8n-oidc offers "bolt-on OIDC." Whether hook-based SSO complies with the license is officially unanswered. A user asked n8n in March 2026 and had no reply by April (community thread).

Per-feature difficulty: half the list is already free or easily done outside n8n

Several items on the "limited" list are restrictions of the cloud plans, not of self-hosting. n8n Cloud caps execution retention at 7 days on Starter and 30 on Pro (pricing), but on self-hosted Community pruning is fully configurable with EXECUTIONS_DATA_PRUNE, EXECUTIONS_DATA_MAX_AGE and EXECUTIONS_DATA_PRUNE_MAX_COUNT (0 means no limit), which the docs do not mark as license-gated (executions env vars). Queue mode with workers is included in Community (CE features). So are concurrency limits and the /metrics Prometheus endpoint (monitoring). A free email registration unlocks folders, debug in editor and custom execution data. The truly gated Community features are SSO and LDAP, projects, sharing, variables, environments and Git, external secrets, external binary storage, log streaming and multi-main (CE features). On the paid side, the cheapest self-hosted plan with SSO and Git is Business at €667/month billed annually, with 6 shared projects. "Unlimited" shared projects, custom roles, log streaming and external secrets appear only under Enterprise, which is sales-priced (pricing).

Feature	Status in self-hosted CE	Best low-risk external approach	In-product clean-room difficulty
Execution retention / pruning	Free (env vars)	Configure; archive rows to cold storage before pruning	None needed
Queue mode, concurrency, metrics	Free	Configure; Kubernetes autoscaling on queue depth	None needed
Git version control, environments	Gated	Separate dev/prod instances; CI runs CLI export, commits, reviews, imports; community templates (12721, 7304)	Medium (credential remapping, merge)
Workflow history / diff	24 h only	Git commit on every change gives unlimited history plus git diff	Low–medium
Insights dashboard	Summary only	Grafana or Metabase over Postgres or /metrics	Low–medium
Log streaming	Gated	Ship stdout/file logs via Vector or Fluent Bit; CDC on execution tables; global Error Workflow; hooks for lifecycle events	Medium (node and audit events are the hard part)
External secrets	Gated	Vault Agent / External Secrets Operator rendering into credential overwrites or env	Medium
Variables	Gated	$env, a config Data Table or a sub-workflow	Low
External binary storage	Gated	S3 mounted via FUSE/CSI into the filesystem path	Medium
SSO (SAML/OIDC/LDAP)	Gated	Forward-auth proxy (Authentik, Authelia, Pomerium) as an access gate; a hook for seamless login (grey zone)	Medium–high
Multi-user RBAC, sharing, unlimited projects	Gated (projects excluded from CE)	Separate instance per team; proxy-level method blocking (crude)	High: per-object authorization must be enforced on every API and UI surface
Multi-main HA	Gated	Active/passive main, fast restart, separate webhook processes	High (leader election, trigger dedup)

The pattern is clear. Externalizing works well for anything that consumes n8n's outputs, such as workflow JSON, execution rows, logs and metrics. It works badly for anything that must decide, request by request, who may see or edit an object. Authorization and active-active coordination can only be implemented inside the process, and inside the process is where the license constraints are tightest.

Four paths ranked from lowest to highest legal risk

1. External tooling and sidecars on stock Community Edition (lowest risk). Proxies, CI pipelines, log shippers, secret agents and database dashboards run n8n unmodified, within its documented configuration and the internal-use grant. They involve no Enterprise-licensed code and no gate changes, and they survive upgrades better than patches do. This path covers retention, Git environments, history, insights, log shipping, secrets and access gating. It cannot deliver fine-grained RBAC, sharing or multi-main. Hook-based seamless SSO is a step up in risk. It is SUL-compatible on the text but officially unconfirmed, and hooks are an unstable in-process API.

2. Switching to an alternative tool (low legal risk, high migration cost). Most open-core competitors gate the same enterprise set. Windmill Community caps SSO at 10 users and has no audit logs or external secret backends (Windmill pricing). Activepieces puts SSO in its $200/month Team plan, and SCIM, audit and Git sync in Ultimate (Activepieces pricing). Kestra's Apache-2.0 open-source edition includes Git versioning but sells SSO, RBAC, audit and secrets managers (Kestra pricing). Fully free stacks such as Airflow and Temporal are code-first, a different paradigm; their licensing was not re-verified in this research. In practice "free SSO and RBAC" means accepting either a different paradigm or another vendor's limits. See kestra-windmill-activepieces-comparison.md for detail.

3. Independent, compatible product built clean-room (low copyright risk, very high effort). A new codebase that imports n8n workflow JSON and offers its own SSO and RBAC is the only route to a commercial offering, and the doctrine supports it (SAS, Google v. Oracle). It is safe only with real discipline. Spec writers work from public docs and black-box behavior. A reviewer strips code expression out of the specs. Implementers have never read n8n source (of either license), nor source-derived descriptions of it. Everything is documented. Do not copy UI text, docs, icons or node descriptions, and do not use the n8n name. The practical obstacle is not the enterprise features but the hundreds of integration nodes that make n8n valuable, all under the SUL, which would have to be rewritten as well.

4. Fork with Enterprise-licensed code removed and features rewritten (moderate, uncertain risk; internal use only). This is defensible on the SUL text: the SUL allows modification for internal use, contains no license-key clause, and the new code is your own. It is contrary to n8n's FAQ, untested in court, and immediately high-risk once you distribute it commercially or host it for others, because those acts fall outside the SUL's use and distribution conditions whatever the gating question. It requires keeping every copyright and licensing notice, adding the SUL's required modification notice, rebranding, pinning to a specific version (the CLA lets n8n tighten future license versions), and rebasing against a fast-moving upstream indefinitely. It is not an option for STaurtomation, which is a clean-room AGPL project. Below all four options sits the path not to take. Running or distributing existing Enterprise-licensed code with gates disabled is outside the Enterprise License, and it is precisely the conduct n8n has already taken down.

Conclusion

The gated features are not hard because they are secret. The hard ones (RBAC, sharing, SSO, multi-main) are hard because they must make access and coordination decisions inside the process, which is exactly where n8n's license constraints are tightest. That changes the usual "build or buy" question. For most teams the useful split is outputs versus decisions. Everything that reads what n8n produces can be built freely outside it today, and much of the "limited" list turns out to be cloud-plan packaging that self-hosting already removes. Everything that decides access inside n8n must either be paid for, or rebuilt in a fork whose legality rests on one omitted sentence and an untested license with no governing-law clause.

The recommended sequence for n8n users is as follows. Configure what is already free. Externalize Git environments, history, log shipping, insights and secrets. Gate access with an identity-aware proxy. If you need real per-object RBAC or SSO in production, either buy Business or Enterprise, or move to a tool whose free tier fits. A clean-room independent product is the only route to commercial use, and its real cost lies in the integration catalog rather than the enterprise features. The precedents also show that n8n's leverage is less about courts than about platforms such as GitHub and npm, and about its own name, so a project that stays off n8n's code, name and package namespaces avoids every enforcement action n8n has actually taken.