Review n8n licensing for business use and client hosting

Licence model. n8n makes source code available but describes its model as fair-code or source available. The Sustainable Use License includes usage restrictions and should not be treated as an unrestricted open-source licence. The official licence overview explains this distinction and links to the licence texts.

Procurement. For procurement, the fact that software can be downloaded is only the beginning. Establish the edition, enabled features and intended use. A working prototype does not confirm that its commercial arrangement is permitted.

Software inventory. Record the exact edition, version, contractual basis and accountable organisation in your software inventory. An entry saying only “n8n, free” leaves an important ambiguity: it could describe an internal business process or an automation product sold to customers.

Licence FAQ. The current n8n licence FAQ distinguishes using predefined automations from external end users creating or configuring workflows. Customer-owned credentials alone do not decide that boundary. A custom interface, API or AI agent can also give an external user effective control over the workflow logic.

Actual capabilities. Document actual capabilities, not just visible screens. Can a customer change conditions, combine new actions, choose destinations or instruct an assistant to redesign the process? Or can they only submit data to a process your organisation has already defined?

Product descriptions. This distinction belongs in product descriptions as well as technical diagrams. Saying “customers never see n8n” is not a complete licensing analysis. A hidden workflow engine can still support a customer-facing workflow builder.

Roadmap. Consider the planned roadmap too. A simple setting may later become a powerful rule editor. If the business intends to add that capability, include it in the initial vendor discussion instead of assuming that approval of the first version covers every future feature.

Case A: internal order coordination. A trades business runs n8n for its own processes. Employees maintain the rules, while customers receive appointment confirmations. Record the operator, user group, edition and required capabilities. Serving a commercial purpose does not by itself mean the organisation is selling customers a workflow-building product.

Case B: a managed outcome service. An agency develops predefined processes and supplies resulting reports to customers. A customer can provide input data but cannot create or change workflows. Alongside licensing, assess customer isolation, data processing, system access and the exact service scope. The contract should describe the real architecture.

Case C: a customer automation builder. A supplier sells an interface in which customers combine triggers, conditions and actions themselves. n8n executes those processes behind the scenes. Discuss this architecture explicitly with n8n before launch. Renaming the interface does not change who determines the automation logic.

Status of the cases. These examples are assessment aids, not approvals for particular business models. Hybrid products can change during development. A fixed reporting service that later gains an editor may need a new assessment even if the underlying server remains identical.

Boundaries per case. For each case, draw the boundary between employees, suppliers and external users. The technical description should show who can build, publish, invoke and administer workflows. Those are different capabilities and should not be collapsed into a single “user access” checkbox.

The following architecture examples are synthetic. They help formulate a precise question to the vendor; they are not licence approvals issued by modernagents.

Fixed report with a selectable period: A customer chooses a month and an existing business unit. The provider has defined the sources, calculation and output. The customer supplies parameters to an established service. Still document any additional choices and who can change the process. The actual capability matters more than calling a control a filter.

Fixed process connected to the customer’s account: A customer connects their CRM so that a provider-defined report can retrieve information. The current n8n FAQ does not treat customer-owned credentials alone as disqualifying. Establish whether the customer merely connects an account or can also design their own automation. Credential handling, data processing and revocation of the connection require separate arrangements.

Configurable automation assistant: A user writes, “When an enquiry from sector X arrives, check source Y and send the result to destination Z.” An assistant creates new logic from that request. The user may therefore shape the automation without seeing a workflow editor. Describe this explicitly in the licence enquiry. Using a language model does not remove the underlying configuration capability.

Managed dedicated instance: An agency maintains an environment for one customer. Establish the contracting party and operator, which customer employees receive access and whether they can create workflows. Technical separation alone does not resolve every licensing question or distinguish internal use from a platform service offered to customers.

Starting point. Use the official licence FAQ as the starting point. For a hybrid model, describe every control path: interface, API, administration access and AI assistant. Screenshots alone can omit meaningful capabilities.

Features and edition. Permitted use of Community Edition does not establish that its feature set fits your team. Roles, identity integration, version management or operational capabilities may require another edition. Compare mandatory requirements with the current plan information and the actual contract offered.

Feature list. Build a short feature list with a business reason for each item. “Two project teams must not use each other's credentials” is more useful than “enterprise security required.” “Changes need review before production” is clearer than “we need Git.” Concrete requirements let you identify the product feature or organisational control that will meet the need.

Plan and deployment. Then establish whether the selected plan provides that capability in the intended deployment model. Cloud and self-hosted offers are not interchangeable labels. A quote should specify the edition, deployment, allowances, contractual period and service boundaries.

Subscription owner. Also check who owns the subscription. An implementation partner may administer a customer-owned account or include a service within its own agreement. Those arrangements have different exit and renewal implications, even when the editor looks the same to a project participant.

A strong licensing enquiry describes the architecture concisely, without relying on marketing terminology. Include these details in a licensing enquiry to n8n:

• The instance operator and owner, and the number of separate customer environments.
• Who creates, modifies and publishes workflows.
• What external users can do through an interface, API or assistant.
• Who owns connected accounts and administers credentials.
• What is being sold: consulting, operation, outcomes or user-controlled workflow creation.
• The required edition and any additional product capabilities.

Concrete transaction. Add a concrete transaction. “A customer starts a fixed export” differs materially from “a customer freely selects a source, transformation and destination.” Request a written assessment of the described model and retain the response with the relevant contract version.

Undecided design. Where part of the design remains undecided, say so. It is better to identify a pending choice than to obtain an answer about an architecture that the team does not actually intend to build. The decision record should make clear which assumptions the assessment depends on.

Documents to retain. Retain the applicable licence and contract versions, review date, architecture description and written vendor responses. Assign responsibility for renewals and changes. If a supplier creates accounts, establish whose name appears on the agreement and how the organisation can change suppliers later.

Reassessment. Reassess material changes: external users gain new configuration powers, an internal tool becomes a commercial product, or several clients are served through a shared platform. Do not silently carry an earlier assessment into a different operating model.

One-page summary. A practical final deliverable is one page containing the use model, required features, unresolved questions and accountable decision-maker. Procurement or legal advisers can then examine a concrete case. Clear architecture before sale is generally easier to evaluate than a finished product whose contractual basis still depends on assumptions.

Gradual change. A boundary case often develops gradually. A provider first delivers a fixed report, then lets customers select additional sources, and later adds arbitrary conditions and user-defined destinations. Each addition may look minor while the overall product increasingly resembles a configurable automation platform.

Change record. Maintain a short change record asking whether external users gain new control. The product owner should answer that question before release. If a change falls outside the architecture previously described to the vendor, obtain an updated assessment before selling the new capability.

Submitted architecture version. A written answer depends on the facts supplied. Keep the submitted architecture version alongside the response. Otherwise a later reviewer may be unable to establish whether the answer applies to the current product or an earlier, narrower service.

Resellers and subcontractors. Include reseller and subcontractor arrangements in that description when they affect access or operation. A diagram showing only the end customer and the server can conceal another organisation that administers the system or sells access. The vendor should assess the real delivery model, not an incomplete version chosen for simplicity.

Two independent assessments. An appropriate commercial agreement can address a licensing question without establishing adequate customer separation. Conversely, a well-isolated technical architecture does not correct unsuitable usage rights. Evaluate the two independently.

Three distinct results. An offer should therefore have three distinct results: a permitted usage model, the product features actually available, and an operating and data-processing design. Consider whether customers could access each other’s information, who manages secrets and how one customer leaves a shared environment. These questions remain relevant with paid software.

Higher tier. A higher subscription tier is not automatically the answer to every embedded use case either. Describe the actual end-user access and have the vendor confirm which agreement is intended for it. A row on a public pricing page is not an assessment of a particular distribution model.

Narrower architecture. A team can continue planning a narrower, clearly described architecture while an unresolved issue is investigated. For example, it may implement an internal process while explicitly excluding an external workflow builder from the commissioned scope. Reflect that limit in both the product and the offer. A note in project minutes is insufficient if the software already provides the broader capability.

Open vendor answer. Record the missing vendor answer, the person responsible for obtaining it and the feature that depends on it. This allows useful prototype work without presenting an unverified assumption as an established usage right. Resolve the specific contractual position before selling the dependent feature.

Handover. At handover, distinguish confirmed facts from assumptions still requiring review. The next operator should be able to identify the allowed service, the evidence supporting it and the changes that trigger another assessment. That record makes later product decisions faster without turning a previous answer into blanket permission.

These pages cover the service overview and the related decisions for n8n licensing:

• n8n implementation and workflow operations
• n8n Cloud or self-hosting: assign operating responsibility
• Calculate n8n costs beyond the subscription
• Introducing AI: software, an internal team or an agency?

For a workflow review, start with the task, systems involved and typical exceptions. Discuss it with modernagents.