TL;DR: White-labelling n8n and selling it to your customers is explicitly listed as not allowed under n8n's Sustainable Use License. The surprise is that buying the commercial agreement does not fix it. n8n's paid embedding option (now called OEM deployment, previously Embed) requires that "n8n branding is required as part of an OEM integration", and n8n's own OEM page answers "Can I white-label n8n inside my own product?" with "No." There is no licence you can buy that makes n8n look like your product in the editor. What an agency can do is large and mostly unrestricted: consulting, building workflows, hosting, maintenance, and running n8n as an invisible backend behind your own UI. Those need no special agreement at all.
This is informational, not legal advice. Every quote below is from n8n's published licence and docs, linked so you can read the clause yourself. If money depends on the answer, email license@n8n.io and get it in writing.
Can you legally white-label n8n?
No. Not for free, and not by paying. The Sustainable Use License forbids selling a product whose value derives substantially from n8n, and n8n's paid OEM agreement - the only sanctioned way to expose the n8n editor to your customers - explicitly requires n8n branding to remain visible. Rebranding the editor is off the table under both.
Most articles on this keyword still tell you the Embed licence is the paid path to a rebranded n8n. That was the widely held understanding, and n8n's own help centre still carries language implying it. The current documentation says otherwise, and the current documentation is what governs.
What the Sustainable Use License actually says
The whole restriction is three sentences. From LICENSE.md in the n8n repository, under "Limitations":
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. You may not alter, remove, or obscure any licensing, copyright, or other notices of the licensor in the software. Any use of the licensor's trademarks is subject to applicable law.
Three separate things are being restricted, and people usually only notice the first.
The internal business purposes limit is what stops you selling n8n-as-a-service. The free of charge limit is what stops you redistributing it commercially. And the third sentence - the one nobody quotes - is the one that specifically kills white-labelling at the code level: you may not alter, remove, or obscure the licensor's notices. Forking n8n, ripping the logo out of the editor, and shipping it as "AcmeFlow" runs straight into that clause plus the trademark sentence.
Separately, any source file with .ee. in its filename is not under the Sustainable Use License at all. Those files fall under LICENSE_EE.md, which states the software "may only be used in production, if you (and any entity that you represent) hold a valid n8n Enterprise license corresponding to your usage." So a fork that keeps the enterprise-flagged files and strips the licence check is not a grey area. It is two violations.
What n8n lists as explicitly not allowed
n8n does not leave this to interpretation. Its Sustainable Use License FAQ sets the test and then gives examples:
Our license restricts use to "internal business purposes". In practice this means all use is allowed unless you are selling a product, service, or module in which the value derives entirely or substantially from n8n functionality.
The two examples it gives of what is not allowed:
-
White-labeling n8n and offering it to your customers for money.
-
Hosting n8n and charging people money to access it.
That is the entire prohibited list in the FAQ. Note how narrow it is. It is not "you cannot make money with n8n". It is "you cannot make money selling n8n itself". The distinction is the whole article.
What the Embed licence adds (and what it does not)
Here is the part that has quietly changed. n8n's Embed product is now documented as OEM deployment, and the old /embed/white-labelling/ docs URL now 307-redirects to it. The page reads:
n8n's OEM deployment option lets you embed and surface n8n's interface inside your own product's UI. This allows your users to build workflows, configure connections, and run workflow automation without leaving your product. n8n branding is required as part of an OEM integration.
And n8n's OEM page puts it in a FAQ, in as few words as possible:
Can I white-label n8n inside my own product? No. n8n branding stays visible in the editor. You can embed the canvas inside your product and your end customers can build workflows there, but they will see it as n8n, not as a fully rebranded experience.
It even tells you to walk away: "If full white-labeling is a hard requirement for your product, OEM isn't the right fit."
So what does the agreement actually buy? Permission. It makes it legal to put the n8n canvas in front of paying end customers - the exact thing the Sustainable Use License forbids - and it brings the supporting machinery: token exchange for iframe SSO against your own identity provider, credential overwrites so users authenticate without seeing your OAuth client secrets, and a custom workflow template library. It requires a separate commercial agreement negotiated with n8n; there is no self-serve checkout.
Be aware of one live inconsistency before you plan around this: n8n's help-centre article on licensing still refers to a "white-labeled Embed license", while the product page and the docs (updated far more recently) both say branding stays. Do not build a business model on the older phrasing. Get the current position in writing from license@n8n.io.
What an agency can do with no agreement at all
This is the section that matters, and it is the one the fear-mongering posts skip. The same FAQ lists what is allowed, and consulting work is on it verbatim:
Providing consulting services related to n8n, for example building workflows, custom features closely connect to n8n, or code that gets executed by n8n.
Supporting n8n, for example by setting it up or maintaining it on an internal company server.
Read that plainly. Building workflows for money is allowed. Setting up and maintaining an instance for money is allowed. Writing custom nodes and integrations is allowed. Charging whatever you want for any of it is allowed. n8n went out of its way to permit this: when it replaced Apache 2.0 with Commons Clause in March 2022, it wrote that the old licence "restricted people's ability to charge fees for consulting or support services related to the software: we have lifted that restriction altogether."
The service you are selling is your expertise. The moment the thing you are selling is access to n8n, you have crossed the line. That is the only line.
Running n8n as an invisible backend
If what you actually want from "white label" is that your client's end users never see n8n, you do not need OEM. You need the backend model, and n8n documents it as requiring no special agreement:
This is distinct from using n8n as a backend, where workflows execute behind the scenes and end users never see n8n. In that model, your product calls n8n using a webhook or the API to trigger workflows, and n8n behaves like any other self-hosted service in your infrastructure - your users never see any n8n UI. This is available on all paid plans under the standard license, with no separate agreement needed.
Your UI, your branding, n8n as the engine nobody sees. That is the closest legitimate thing to a white-labelled n8n, and it is free of licensing drama - with one hard condition.
The condition is credentials. From the FAQ on using n8n to power a feature in your app: "Usually yes, as long as the back-end process doesn't use users' own credentials to access their data." n8n gives two examples. An AI chatbot embedded in your app, running on your company's credentials, where users only type questions: allowed. Collecting a user's own HubSpot credentials so n8n can sync their HubSpot data into your app: not allowed.
That is the tripwire, and it is where most agency "portals" die. The instant you build a screen where each client pastes in their own Google or HubSpot or Stripe credentials and n8n uses those to reach into their accounts, you are no longer running a backend feature. You are operating n8n as a service on their behalf, and you need to talk to n8n.
Which model needs which licence
| What you are doing | Who owns the instance | What you need |
|---|---|---|
| Building workflows, consulting, training, custom nodes | Client | Nothing. Explicitly permitted. |
| Setting up and maintaining an instance for a client | Client | Nothing on your part. The client licenses their own tier. |
| n8n as a hidden backend for your product, using your own credentials | You | A paid n8n plan. Standard licence, no agreement. |
| Hosting clients' workflows and credentials in your own shared instance | You | Per n8n's help centre, an Enterprise licence. Ask before you build. |
| Exposing the n8n editor to your paying end customers | You | An OEM agreement. And n8n branding stays visible. |
| Forking n8n, removing the branding, selling it as your product | You | Not available at any price. |
When you do NOT need an Embed or OEM agreement
The most common reason agencies think they need a licence is that they have not separated who owns the instance from who does the work. n8n's help centre is direct about this: "If your role is limited to assisting your clients with setting up their own internal instances of n8n, no commercial license would be required on your part."
So the cleanest agency structure, and the one to default to: the client owns the instance. It runs on their infrastructure or their n8n Cloud account, billed to their card, under their licence. You have admin access because they granted it. You build, you maintain, you invoice for your time. The client's own use of n8n is internal business use, which is exactly what the free licence is for. Nothing you do triggers a commercial agreement, because you are not the one using n8n commercially - they are, and their use is internal.
This has a second benefit that has nothing to do with licensing: it makes you replaceable, and clients pay more to firms they could fire. It also means the engagement can end cleanly, which is the next problem.
If you are still choosing between hosting models, n8n Cloud vs self-hosted covers the cost and effort side, and when self-hosting is a mistake covers who should not run their own instance at all.
The client handover template
Client-owned instances only work if the handover is real. The failure mode is an agency that "hands over" a client's n8n by sharing a login, and six months later the client cannot restore a backup because nobody kept the encryption key. Every credential in that database is then unrecoverable ciphertext.
Copy this into your statement of work and run it at engagement end. It is the artifact that makes "the client owns the instance" true rather than nominal.
N8N CLIENT HANDOVER CHECKLIST
Client: ____________________ Instance URL: ____________________
Handover date: ____________ Agency contact: ____________________
[1] INSTANCE OWNERSHIP
[ ] Hosting account (Cloud / VPS / cloud provider) is in the CLIENT's name
[ ] Billing card / invoice details are the CLIENT's, not the agency's
[ ] Domain and DNS records transferred to the client's registrar account
[ ] TLS certificate renewal is automated and does not depend on agency access
[ ] n8n licence / plan (if any) registered to the client's email
[ ] Client account created with the OWNER role; agency accounts demoted or removed
[2] ENCRYPTION KEY CUSTODY (do this first - nothing else works without it)
[ ] N8N_ENCRYPTION_KEY handed over via a password manager or one-time secret link
(never email, never Slack, never committed to the repo)
[ ] Client has stored it in THEIR password manager and confirmed in writing
[ ] Client understands: without this key, every credential in a restored backup
is undecryptable ciphertext. The key is not recoverable from n8n.
[ ] Key is recorded in the client's disaster-recovery runbook
[3] CREDENTIAL TRANSFER
[ ] Every third-party credential (Google, Slack, Stripe, CRM, SMTP, ...) is
re-issued under the CLIENT's own accounts, not the agency's
[ ] Agency-owned OAuth apps and API keys revoked after the swap is verified
[ ] Each workflow re-tested against the client-owned credentials
[ ] Shared/service accounts documented: who owns them, who pays, who can rotate
[4] DATA AND RECOVERY
[ ] Postgres (or SQLite) backup schedule is running and OWNED by the client
[ ] One full restore performed end-to-end and verified, with the client watching
[ ] Backup destination is a client-owned bucket, not the agency's
[ ] Retention period agreed and documented
[5] DOCUMENTATION
[ ] Every workflow: what it does, what triggers it, what breaks if it stops
[ ] Environment variables list, with what each is set to and why
[ ] Error handling and alerting: where failures go, who is on call
[ ] Named upgrade path: version pinned, how to upgrade, what to test after
[ ] Exported workflow JSON committed to a CLIENT-owned repository
[6] ACCESS TEARDOWN
[ ] Agency SSH keys, API keys, and n8n accounts removed
[ ] Removal verified by the client (they log in and confirm the agency is gone)
[ ] Signed off by both parties
The encryption key section is the one that gets skipped and the one that causes the incidents. The variable is N8N_ENCRYPTION_KEY; if it was never set explicitly, n8n generated one and wrote it to disk, and it needs to be found and handed over. The n8n environment variables reference covers where it lives, and the backup and restore guide covers why a backup without the key is worthless.
FAQ
Can I remove the n8n logo from a self-hosted instance my client uses internally? The Sustainable Use License says you may not "alter, remove, or obscure any licensing, copyright, or other notices of the licensor in the software", and adds that use of n8n's trademarks is subject to applicable law. Do not modify the branding. If the goal is that end users never see n8n, hide the editor entirely and drive it through the API instead.
Can I charge a client a monthly fee for an n8n instance I run for them? It depends on what the fee is for. Charging for your management, monitoring, and maintenance of an instance the client owns is consulting and support, which n8n explicitly permits. Charging for access to n8n itself matches "hosting n8n and charging people money to access it", which is listed as not allowed.
Does the Embed or OEM licence let me rebrand the editor? No. n8n's docs state "n8n branding is required as part of an OEM integration", and its OEM page answers the white-label question with a flat "No. n8n branding stays visible in the editor." OEM makes commercial embedding legal; it does not make n8n look like your product.
Can I put multiple clients on one n8n instance I own? n8n's help centre says that if you host and manage clients' workflows and credentials within your own internal instance, an Enterprise licence is required. This is the most commonly violated boundary in agency setups. Ask n8n before you build the architecture, not after you have sold it.
What happens if I violate the Sustainable Use License? The licence terminates automatically. If n8n notifies you and you stop within 30 days, it is reinstated retroactively - but a violation after reinstatement terminates your licence permanently. The clause is in LICENSE.md under "Termination".
Is n8n open source? No, and n8n says so itself: because open source licences cannot restrict use, n8n does not call itself open source. It uses the term fair-code: source-available, free for internal use, commercially restricted by the author.
What to do with this
If you are an agency, stop trying to white-label n8n and start structuring engagements so the client owns the instance. It is permitted without any agreement, it removes the licensing question entirely, and it is a better product for the client. If you genuinely need the n8n canvas inside a product you sell, talk to n8n about OEM and accept the branding stays. If you just need the automation to be invisible, run n8n as a backend behind your own UI, on your own credentials, and you are already fully compliant.
We build and hand over client-owned n8n instances on exactly the checklist above. If you want the workflows without inheriting the licensing risk, get in touch - or if you are still deciding who should build them, hiring an n8n developer in 2026 breaks down the options.
