Every question below is a negotiation you can win before a contract is signed and will probably lose nine months later, once the system is live on someone else’s server, holding credentials issued from someone else’s account.
Before an n8n agency writes a single node, four things belong in writing: who owns the instance, whose accounts authorize the connections, who pays for model usage, and what you walk away with if the relationship ends. None of those are technical details. They are commercial positions, and n8n makes you take one on each, because unlike Zapier and Make it is not a pure SaaS product. It can be self-hosted, which means somebody owns a server, a license question, and an exit.
That is the whole difference between hiring for n8n and hiring for anything hosted. On Zapier the vendor holds the account and the answer to “what happens if we part ways” is boring. On n8n the answer depends on choices your agency makes in week one, and most of them are quietly hard to reverse in month nine.
We run over 200 n8n workflows in production and 89 AI agents live, so we have been on both sides of these questions. What follows sits on top of the general hiring questions, and it is the layer that only applies when the platform can be self-hosted.
Three of the seven below exist only because n8n can be self-hosted: whose instance it is, how the license reads on that arrangement, and what actually separates your workflows from another client’s. The other four apply to any automation engagement, on any platform. They are on this list because n8n makes them materially harder to unwind, since the system ends up living on a server that somebody owns, and after go-live that somebody holds every card.
Who owns the n8n instance and the workflows?
There are three configurations, and only two of them leave you holding your own operations.
The first is n8n Cloud on an account in your company’s name, with the agency added as a user. Every paid Cloud tier includes unlimited workflows and unlimited users, so adding a builder to your account costs you nothing extra. Cloud pricing, as published in August 2026, sits at EUR 20 per month on Starter billed annually (EUR 24 on the monthly-billing plan) for 2,500 executions, EUR 50 (EUR 60 monthly-billing) on Pro for 10,000, and EUR 667 (EUR 800 monthly-billing) on Business for 40,000. An execution is one run of an entire workflow regardless of how many steps it contains, which is worth knowing before you compare any quote to a per-task tool.
The second is self-hosting on infrastructure your company controls. Your server, your database, your backups, your upgrade schedule. More work, more control, and the credentials never leave a machine you can log into.
The third is the agency running your automations on the agency’s own instance or its own Cloud account. This is common and it is often just convenience rather than strategy. It is still a commercial position: the party holding the instance is holding your operations. The real switching cost in that arrangement is never the notice period, it is the migration nobody has scoped.
Our own default is the second configuration, and it is worth saying plainly where that default is wrong, because it often is.
If nobody at your company can patch a server, and you are not paying anyone to, self-hosting hands you an operational job you have not staffed. A box that never gets updated is a worse outcome than a Cloud subscription, and it fails quietly. At small volumes the arithmetic also runs the other way: n8n Cloud at EUR 20 a month is cheaper than a VPS (a rented virtual server) plus somebody’s attention, and it stays cheaper until execution volume is high enough for the meter to hurt. And for a first paid pilot, before anyone knows whether this work is worth continuing, standing up infrastructure is a commitment nobody has earned yet. Cloud on your own account is the better opening move there, and it can be moved later.
Which points at the question whose honest answer costs an agency something, so ask it and watch what happens. After handoff, who patches that server, who tests version upgrades before they go live, who restores it if the disk fills at 3am, and what does that cost per month? Putting n8n on your own infrastructure gives you ownership and hands you an ops burden in the same motion. An agency that presents self-hosting as pure upside has not told you the whole trade. The right answer is usually a small named retainer or a named person on your side, not silence.
Then ask whose name is on the account, whose card pays the bill, and what a transfer looks like in days. An agency that has done this before will answer in a sentence. The n8n work we take on is scoped on that answer first, because it changes everything downstream.
Is it legal for an n8n agency to build workflows for clients?
Yes, in the ordinary case, and the terms are short enough that you can read them yourself rather than take anyone’s word for it.
n8n is fair-code, licensed under the Sustainable Use License rather than a standard open-source license. The plain reading: self-hosting is free for your own internal business purposes, and the license does not condition that on company size. An agency may build workflows for clients commercially without needing a separate agreement to do it. What nobody may do is resell n8n, offer it to customers as a hosted service, or build a competing platform on top of it.
The genuinely unclear case sits between those. If an agency gives each client a workspace on the agency’s own instance as part of a monthly retainer, that starts to resemble offering n8n as a service, which is the thing the license restricts. The honest answer is that it depends on specifics none of us can settle in a blog post. Treat it as a question to put to the agency and, if the arrangement matters to you, to n8n directly. Nothing here is legal advice.
For what it is worth, our own default sidesteps the question rather than arguing about it. In these engagements we normally start by installing a self-hosted n8n on the client’s own infrastructure and building there. The client is self-hosting for their own internal business purposes, which the license permits, and we are building workflows for a client commercially, which the license permits without a separate agreement. Two clearly allowed things, no grey area between them.
Notice that this is the hosting question from the previous section wearing different clothes. If the instance is yours, the license question resolves itself. If the instance is theirs and every client has a workspace on it, someone should have already asked.
How are your workflows and credentials isolated from other clients?
If an agency runs multiple clients on one self-hosted instance, ask which product feature separates them. That question has a checkable answer, which is why it is worth asking.
The n8n Community edition, the free self-hosted one, does not include projects (enforced client boundaries), credential sharing (controlled access to a connection), or SSO (logins your IT can revoke centrally). On self-hosted n8n, those live in the Business and Enterprise tiers. So an agency running twelve clients on a free Community instance is separating them by naming conventions and personal discipline, not by anything the product enforces. There is no enforced project boundary: the instance owner sees every workflow on it, and anyone who can edit a workflow that uses a credential can extract the secret through an HTTP Request node or a Code node, even though the value itself is masked in the n8n UI. Use is functionally possession.
That is not automatically reckless. A separate container or instance per client is a perfectly good answer and plenty of teams work that way. Paying for a tier that has projects is another. Discipline on a shared free instance might even hold, right up until the first contractor with broad access leaves mid-project.
Four things to ask: one instance or one per client, which edition, who currently holds editor access, and whether they can show you the boundary rather than describe it. A vague answer here is the answer.
Whose accounts authorize the connections, and what happens at handoff?
Credentials should be created under accounts your company owns, starting on day one, because an OAuth grant belongs to whoever clicked “allow” and that ownership does not transfer with a project handoff.
This is the failure that practitioners see constantly and buyers almost never anticipate. A builder connects your Google Workspace, your CRM, your Slack using their own login because it was faster during the build. Everything works. Then the engagement ends, that person’s account gets deactivated or their token expires, and the workflow stops. Usually without an error anyone sees, which is the expensive part and why automations break silently more often than they break loudly.
There is a second half to this. Credentials do not travel inside a workflow export, by design. You can be handed a complete set of JSON files and still be handed nothing that runs, because every connection in them points at an authorization you do not hold.
What good looks like is unglamorous: dedicated service accounts owned by your company, API keys issued from your own provider accounts, and a written inventory of every connection with the account that authorized it. Ask for that inventory as a named deliverable in the scope, not as a favor at the end.
Who pays for the model API usage, and how is it tracked per client?
Passed through at cost, marked up, or bundled into the retainer. All three are legitimate. Not knowing which one you are on is not.
AI workflows spend provider tokens on every run, and the two meters involved are not connected to each other. n8n counts executions. OpenAI or Anthropic count tokens. A workflow that loops on a retry, or an agent that re-reads a long document on each pass, can multiply your token spend several times over without moving the execution count at all. That is precisely the shape of runaway that goes unnoticed.
Per-client tracking has a concrete requirement: a separate provider key per client, so the provider’s own dashboard attributes the spend without anyone reconstructing it from logs. One agency key shared across a book of clients makes the question “which client caused this” a research project.
Same-day detection has a concrete requirement too. A hard spend cap on the provider account, an alert at a daily threshold rather than a monthly one, and an alarm on execution volume so an unexpected loop surfaces while it is still cheap. Discovering a runaway workflow on the invoice is discovering it three weeks late.
Ask whose provider account the keys live in, whether keys are per client or shared, what the cap is set to, and whose phone the alert reaches.
Can you export everything and run it yourself?
The workflows, yes. They are JSON and they export cleanly, and that is a real structural advantage of n8n over pure SaaS platforms where your logic is a row in someone else’s database. Exportable is not the same as operable, though, and the gap between those two words is where teams get caught.
What does not come along in an export: the credentials, the environment variables, the webhook URLs (they are bound to the host of the instance that issued them, so every external system calling those URLs needs repointing), the server itself, the queue and worker configuration, the database, any community or custom node installed on the box, and the schedule state that decides what runs tonight.
So the honest portability test is not “can we get a file”. It is “how many hours from export to running, and has anyone here done it”. Portability is usually what moves teams to n8n in the first place, and anyone who has run a real move, including off Zapier and onto n8n, knows the workflows are the easy half.
Ask for a restore runbook rather than a promise. A document that walks a competent stranger from a fresh instance to a working system, tested at least once, is the only version of portability that survives contact with an actual departure.
What does “done” mean on an n8n project?
Done means a specialist of comparable skill can pick up the system from the documentation alone if the person who built it disappears. Not a recorded walkthrough call, not a colleague who was shown it once, not the same builder six months later working from memory.
That standard sounds demanding and it is really just a checklist: what each workflow does and what triggers it, the credential inventory with the owning account for each connection, the environment variables and where the secrets actually live, the error paths and who receives the alert when one fires, and the rebuild procedure on a fresh instance. Five artifacts. A week of work at most on a system that took months, and it is what we scope into every n8n build by default.
Skip them and you have not bought a system, you have rented a dependency on one person, and the rent comes due at the worst possible moment. The wider version of this standard, the tests and monitoring that go with the documentation, is what production-grade automation means.
The tell during a sales conversation is simple. Ask what documentation ships with the build and whether it is in scope or extra. Teams that treat it as extra are pricing the handoff as an upsell.
So what should you actually ask before signing?
Seven questions, all answerable in one email by anyone who has done this properly. Send them as they are written here, or print the vendor call checklist and bring it to the call.
- Whose name will the n8n account be in? If it is yours rather than ours, what does transferring it involve and how many days does it take?
- If our workflows run on your instance, how do you read the Sustainable Use License on that arrangement?
- Will we be on our own instance or share one? Which n8n edition, and who holds editor access to it today?
- Which accounts will authorize each connection? Is a written credential inventory part of the deliverables?
- Whose provider keys pay for model usage? Per client or shared, what is the spend cap, and whose phone does the alert reach?
- What exactly is in an export, what is not, and do you have a restore runbook you have actually tested?
- What documentation ships at handoff, and is it in scope or billed separately?
And one more, which is really about you rather than them: after handoff, who patches the server and tests upgrades, and what does that cost per month?
Some answers should end the conversation rather than start a negotiation. “The instance stays on our account,” with no transfer plan attached. “Documentation is a Loom video,” in place of the five artifacts above. A refusal to put credential ownership in writing. None of these are dealbreakers because they are rude. They are dealbreakers because each one is the exact failure mode this article walks through, showing up now instead of nine months in.
The decision rule underneath all of them: the negotiation is cheap now and close to unwinnable later.
An agency that answers all seven quickly is not necessarily the best builder on your shortlist. But an agency that treats the questions as unusual has told you something useful, which is that the clients before you did not ask.