When you build n8n workflows for a client, whose account should they run on?

Tips & Tricks
, , ,
1

This one splits freelancers, and I think it matters more than most build decisions.

Option one: you host everything. The client’s workflows run on your n8n, with their API keys saved in your credentials. You charge a monthly fee, you can fix things fast, and the client never has to think about it.

Option two: the client owns it. Their n8n account, their logins, their API keys. You get access while you build and support it, and they can remove you whenever they want.

I go with option two, even though option one pays better month to month. If I get sick or busy, the client’s business keeps running. Their customer data never sits in an account they cannot see. And if they want to leave me, they can, which honestly makes me work harder to keep them happy.

The downside is real though. Clients forget to pay the n8n bill, change a password, or lose the login, and you end up doing more admin than you planned.

A checklist I would run before handing over any client workflow:

  1. Every credential is connected with the client’s accounts, not yours.
  2. Every setting the client might change sits in one settings node at the start, so they never have to dig through the workflow.
  3. Errors go to a channel or inbox the client actually reads, not only your Slack.
  4. You have written down how to remove your access, and the client knows where that note is.

All six of my templates are built for option two. Credentials go in through n8n’s own credentials, and everything a user might change sits in one settings node at the start. You can find them in the n8n template library under my name.

What do you do with your clients, and why? If you host for them, what happens when one wants to leave?

2

option two is the right call for trust. the admin tax you mentioned (forgotten passwords, lost logins) is where handoffs usually get messy.

one pattern that helps after you leave: keep the workflow on the client’s n8n, but have each of their end users connect their own apps through a managed oauth popup instead of pasting keys into the credential store. we built viasocket for that kind of per-user connect (2,300+ apps), so the client owns the instance and each user owns their connections.

for your templates, are clients mostly connecting their own saas logins, or also wiring end-customer accounts?

3

Client-owned accounts are the safer default to me as well. I would document ownership at three layers: the n8n workspace, every external credential and billing owner, and the deployment/domain/backup owner. An exported workflow alone is not enough if the client cannot renew a key, restore a backup or receive an error alert. A named, revocable support access path and a simple ‘what to do when this fails’ note make handover much less fragile.