Wir sind eine KI-Automatisierungsagentur, die n8n als Rückgrat unserer Kundenbelieferung einsetzt, und wir stoßen beim Skalieren an Grenzen. Ich würde gerne wissen, wie andere Agenturen das gelöst haben.
Unsere Situation:
Wir betreiben eine wachsende Anzahl separater Kundeninstanzen.
Wir benötigen 2–3 Teammitglieder, die innerhalb desselben Projekts zusammenarbeiten — nicht immer an denselben Workflows, aber eng abgestimmte, voneinander abhängige.
Bei der selbstgehosteten Community Edition gibt es kein RBAC und keine Projekt-/Workflow-Freigabe: nur der Admin sieht alle Workflows, während andere Benutzer nur ihre eigenen sehen. Daher können Teammitglieder nicht an den Workflows der anderen arbeiten, was eine kollaborative, kundenübergreifende Belieferung praktisch unmöglich macht.
Wir versuchen, das richtige Setup dafür zu finden — etwas, das proportional zu einem Team ist, das zusammenarbeiten muss, ohne es zu überverkomplizieren.
Meine Fragen an die Community:
Falls ihr eine Agentur auf n8n über mehrere Kunden hinweg betreibt, wie ist euer Zugriffs-/Kollaborations-Setup aufgebaut? Eine gemeinsame Instanz mit Projekten und Rollen, oder eine Instanz pro Kunde?
Gibt es irgendeine unterstützte Möglichkeit, Teamzusammenarbeit (geteilte Projekte / mehrere Editoren) in der Community Edition zu bekommen, oder eine proportionale kostenpflichtige Option für ein kleines Team — ohne gleich auf Enterprise zu springen?
Falls ihr n8n als Agentur skaliert und auf dasselbe Problem stoßt, wäre eine kurze Notiz zu eurem Setup (oder ein Upvote, damit n8n die Nachfrage sieht) sehr hilfreich.
@fernandesnoa richtig, Community hat keine Projekte oder RBAC, nur ein Admin und alle anderen sind isoliert. Was du möchtest, ein gemeinsames Projekt mit mehreren Editoren, ist die Project Editor-Rolle, die es bei Cloud Pro und bei selbst gehosteter Enterprise gibt. Ohne Enterprise ist die angemessene Option Cloud Pro, Projekte mit mehreren Editoren und Pro-Projekt-Rollen auf einer Instanz, genau für deine 2–3 Personen mit voneinander abhängigen Workflows. Bei selbst gehosteter Version gibt es aber keine Mittelstufe, Projekte und RBAC gibt es nur mit der Enterprise-Lizenz. Eine gemeinsame Instanz mit Projekten schlägt eine Instanz pro Client, die Pro-Projekt-Rollen grenzen die Arbeiten jedes Clients ab, während dein Team das teilt, das sie brauchen.
Das nachhaltigste Modell für dich ist eine Split-Architektur:
Agency Sandbox (Paid Business/Pro Plan): Eine einzelne, leistungsstarke Instanz, in der dein Team zusammenarbeitet, Templates erstellt und neue KI-Agenten testet. Hier findet deine „Forschungs- und Entwicklung
The collaboration side has solid answers above, Cloud Pro projects or the sandbox-plus-CE split. The part that bit us hardest as the instance count grew was not access, it was visibility. Once every client sits on their own isolated Community instance, there is no single place that tells you when one of them quietly stopped doing its job. A workflow sits deactivated after a restart, or a credential expires and the runs just stop, and on CE nothing surfaces that across instances. With 3 clients you notice. With 20 you find out when the client emails. Whatever architecture you land on, I would put a flat external check on top that watches each client’s critical flows from the outside and pings you when an expected run does not happen, so silence becomes an alert instead of an assumption. The split model is the right call, just do not let the isolation hide a dead flow.
@achamm that confirms it: on self-hosted there’s no middle tier, and projects + per-project roles on a single instance start at Cloud Pro. For where we are now (small team, no clients needing access yet), we’re staying on Cloud Pro and organising clients into folders within projects, then revisiting once we outgrow it (or the partner program is launched).
@kjooleng love the sandbox-vs-production split, parking that as our scale-up option, since it keeps collaboration and cost separate nicely.
Cloud Pro is the right call for your stage. One thing worth noting for when you eventually move workflows to client Community instances: n8n’s source control (git integration) is available on Enterprise tier, but for Community you can manually export workflows as JSON and version them in a private git repo. It’s a manual process, but it at least gives you version history and a way to push tested workflows from your Pro sandbox to client instances without rebuilding them. Keeps the two-tier setup kjooleng described functional as you grow.
@fernandesnoa your welcome, happy to help! if you need anything else, feel free to ping any one of us, if your good, feel free to mark any of the replies as the solution, and have a good day!
One extra bit I’d write down now is the boundary between collaboration and client authority.
Folders/projects help the team build together. They don’t replace a per-client handoff: who owns credentials, which workflows can write to CRM/email, who approves production changes, and what receipt proves a run happened. If that checklist lives in each client folder now, the later split into client instances gets much less painful.
One pattern that works well alongside the split architecture: use n8n’s REST API (/api/v1/workflows) to automate the deployment step. When a workflow is approved in your sandbox, a small deploy script can export the JSON and import it into the client’s Community instance via API, keeping credentials detached. This makes the “move from sandbox to production” step repeatable without manual export/import each time. Pair it with git for versioning and you have a lightweight deployment pipeline for workflow delivery - especially useful once you’re managing 10+ client instances.
I would separate two problems: build-time collaboration and post-launch ownership.
For build-time collaboration, Cloud Pro or Enterprise projects/RBAC is the cleanest path if you want multiple people editing the same client work. If cost or architecture pushes you toward one instance per client, then a shared agency sandbox plus isolated client production instances can work, but you need a disciplined promotion process.
For post-launch ownership, I would not let the n8n instance structure be the only source of truth. Agencies usually need a separate operating layer that answers:
Which clients have which workflows?
Which workflows are business-critical?
Who owns each workflow?
What checks prove the workflow is healthy?
What issues are open, resolved, or recurring?
What can be reported back to the client?
That is the exact agency problem I am building Maintain Flow around. It does not replace n8n projects/RBAC; it sits above the delivery stack so the agency can maintain client automations after launch without losing track across instances.
