The riskiest object in your n8n build is not a workflow. It is the API key your client handed you.
Yes, you can charge clients for n8n work. n8n's own license documentation lists building workflows, providing consulting services and setting up or maintaining n8n as allowed, and n8n deliberately removed the older clause that blocked exactly that. What is not allowed is white-labeling n8n and offering it to your customers for money, or hosting n8n and charging people to access it. The boundary is not whether you invoice. It is whether your customers connect their own accounts to an instance you run.
Here is the part that should bother you. Nothing in the software enforces any of it. The Community edition has no license key for this, no seat check, no warning banner. You build the first client automation in your own instance because that is the fastest path, paste their CRM key into a credential, and bill a retainer. The decision that answers the license question gets made in the first hour of the first project, by whoever is in a hurry, and then it gets copied twenty times.
I have built automation systems across 500+ projects in 30 countries, and this conversation never starts with a lawyer. It starts with an agency owner who already has twenty clients inside one instance.
Every agency asks whether it can charge for n8n. That was never the restricted part. The restricted part is becoming a place your clients log in to.
The mistake: reading the license as a rule about money
n8n ran on Apache 2.0 with Commons Clause until 17 March 2022. That arrangement did restrict people's ability to charge fees for consulting or support, and n8n says it replaced the arrangement and lifted that restriction altogether. The single thing most agency owners are quietly worried about is the thing the vendor went out of its way to permit.
What replaced it is narrower and stranger. The license restricts use to your own internal business purposes, or to non-commercial or personal use, and n8n translates that into a plain test: 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 given of what that rules out are white-labeling n8n and offering it to customers for money, and hosting n8n and charging people money to access it.
Neither of those is about revenue. Both are about who is standing where.
"Are we allowed to make money from n8n?"
Yes, and it is the least interesting question on the page. Consulting, building workflows, custom features closely connected to n8n and maintaining an instance are all listed as allowed.
Open the credential list on every instance you operate and read the owner of each key. Yours, or the client's. That column sorts your book into consulting and hosting in about ten minutes.
"Whose credentials are sitting in this instance?"
n8n's own two examples differ by exactly one variable
The license FAQ answers whether n8n can act as the back end powering a feature in your app, and it answers with two worked examples built from the same fictional founder and the same fictional product.
In the first, n8n collects a user's own HubSpot credentials to sync that user's data into the app. n8n marks it not allowed. In the second, n8n powers an AI chatbot inside the same app, the chatbot runs on the company's own credentials, and end users only type questions into it. n8n marks it allowed.
Same product, same customers, same billing. One variable moves, and it is whose credentials sit inside n8n. A different answer on the same page draws the identical line for companies with policies against commercially restricted code: you should be able to use n8n provided you are not making it available to your customers for them to connect their accounts and build workflows.
Termination is automatic. Notice is optional.
This is the clause that makes the architecture question urgent rather than academic, and almost nobody who quotes this license quotes it.
Use the software in violation of the terms and your license terminates automatically. A cure period exists, but read the order of operations: it starts only if the licensor provides you with a notice of violation, and stopping within 30 days of that notice reinstates you retroactively. Violate again after a reinstatement and the license terminates automatically and permanently.
So the sequence is not warning, then problem. It is problem, then silence, then possibly a warning. Between the day the architecture crosses the line and the day anyone tells you, the state you are already in is unlicensed, and no part of the product will mention it. That is a familiar shape if you have ever inherited a build. The system reports healthy right up until someone outside it asks a question.
Four moves before your next client automation
The bottom line
You are allowed to make money from n8n. The vendor removed the clause that stopped you, then published four examples of commercial work it considers fine. What you are not allowed to do is become the place your clients log in to, and from inside a monthly invoice those two businesses look identical. What separates them is small enough to fit in a credential field.
I am not your lawyer and none of this is legal advice. The license text is the authority and n8n publishes an address for genuine edge cases. But most agencies do not have an edge case. They have a default chosen in a hurry during a first project, and the license is explicit that the software will not be the thing that tells them.
See what we build in AI automation and for agencies productizing automation, or bring in an n8n developer to move the instances with you. More about who I am.
Book a 30 minute call: cal.com/zeeshanwaheed/30min or email [email protected].