Should a Client's n8n Live in Your Account or Theirs?

What goes wrong when the agency owns everything

• Offboarding becomes a hostage situation, even when nobody intends it. When the relationship ends, the client's operations run on infrastructure they do not control. Untangling it takes time from both sides, and it is often when relationships are already strained.
• You become the custodian of their data. Execution history in n8n can contain customer records, emails, and anything else that passes through a workflow. If the instance is yours, you are holding that data.
• Credentials pile up in one place. One instance with every client's CRM, email, and finance tokens is a single point of failure and an attractive target.
• Costs blur. Hosting, upgrades, backups, and execution volume for many clients on one bill make it hard to see what each client actually costs to serve.

Data responsibility: who is accountable

n8n's own privacy documentation is clear about its side. For self-hosted n8n, n8n is neither a controller nor a processor of the data flowing through your workflows: that data stays on your infrastructure and n8n never receives it. For n8n Cloud, n8n acts as controller and processor and offers a data processing agreement as part of its terms.

The practical consequence for agencies: if the self-hosted instance runs on your server, the responsibility for that data sits with whoever operates it, and n8n's documentation notes that self-hosted users are responsible for deleting user data. If the client runs the instance (self-hosted on their infrastructure, or their own n8n Cloud account), the data, the agreement with n8n, and the retention decisions sit with them, where they usually already have the policies. Exactly how controller and processor roles split between you and your client is a question for your contracts and your privacy advisor.

The licensing line agencies need to know

The self-hosted community version of n8n is under the Sustainable Use License (see n8n's fair-code license page), which limits use to your own internal business purposes or non-commercial use. n8n has explicitly lifted any restriction on charging for consulting and support, so building workflows for clients as a paid service is fine.

The license FAQ gets specific about agency setups. As of October 2026 it says you can:

• Build automations for your clients on your instance, as long as your clients cannot create or edit them.
• Charge clients for workflow creation, setup, maintenance, training, and consultancy.
• Run several instances of the community version.

And that you cannot, among other things:

• Host n8n as a service and let your clients build workflows.
• White-label n8n by removing its branding and offering it as is.
• Use enterprise features that ask for a license key without an Enterprise license.

So "we run it and the client never touches the editor" can be permitted on the community version, while "we run an instance and give the client editor access" is the kind of setup the FAQ says needs a commercial agreement. The FAQ's own advice for anything unclear is to confirm your architecture with [email protected] before launch. n8n Cloud has its own terms, which the community license FAQ does not cover.

Three access models, compared

Billing: pass it through, do not absorb it

When the client owns the instance, they pay n8n, their hosting provider, and their API vendors directly, and you bill for building and maintaining. That keeps your invoices about work rather than infrastructure resale, and it means a spike in execution volume shows up on their bill, where the decision to scale belongs. If you do host, itemise hosting and usage separately from services so neither side is surprised.

The handover checklist

Whichever model you choose, agree at the start what the client receives at the end:

• Workflow exports. n8n saves workflows as JSON and can export and import them. Exported files include credential names and IDs but not the secrets, so review names and any authentication headers in HTTP Request nodes before sharing. On self-hosted instances the CLI exports everything, for example n8n export:workflow --backup --output=backups/latest/.
• A credentials inventory. Every service the workflows connect to, which account each credential belongs to, and the scopes it needs. The client recreates or rotates them under their own accounts.
• For a full instance transfer: the database and the encryption key. Without the key, stored credentials cannot be decrypted.
• Documentation. What triggers each workflow, what it reads and writes, what alerts look like, and what to do when common failures happen.
• A handover session. A walkthrough with whoever will own the automations on the client's side.

Most of this overlaps with what makes a workflow reliable in the first place; see making n8n workflows production-ready.

My recommendation

Default to client ownership: their instance, their credentials, their n8n agreement, your user account. Choose agency hosting only when the client genuinely wants a managed service, then use one instance per client, keep clients out of the editor on the community version (or get the appropriate n8n agreement), and write the exit plan into the contract before the first workflow ships. It costs a little more effort up front and saves a great deal of it later.

Frequently asked questions