我們是一家AI自動化代理公司，以n8n作為客戶交付的核心基礎，但隨著規模擴展，我們遇到了瓶頸。我很想聽聽其他代理公司是如何解決這個問題的。
我們目前的情況：
- 我們運營著越來越多的獨立客戶實例。
- 我們需要2-3名團隊成員在同一個專案內協作——不一定是同一個工作流程，但需要緊密協調且相互依存的工作流程。
- 在自託管社區版上，沒有RBAC（角色型訪問控制）也沒有專案/工作流程共享功能：只有管理員能看到所有工作流程，而其他使用者只能看到自己的。因此團隊成員無法協作處理彼此的工作流程，這使得多客戶的協作交付基本上變得不可能。
我們正在尋找適合我們的合適規模的設置——對於需要協作的團隊來說既要足夠應對，又不能過度設計。
我對社區的提問：
- 如果你在n8n上跨多個客戶運營代理公司，你的訪問權限/協作是如何設置的？ 是一個共享實例加上專案和角色，還是每個客戶一個實例？
- 有沒有任何支援的方法可以在社區版上獲得團隊協作功能（共享專案/多個編輯者），或者有沒有適合小型團隊的按比例付費選項——而不是直接跳到企業版？
如果你在將n8n擴展為代理公司規模時遇到同樣的問題，快速分享你的設置（或者點讚讓n8n看到這種需求）會對我們幫助很大。
1個讚
@fernandesnoa 對，Community 沒有專案或 RBAC，只有單一管理員，其他人都是各自隔離的。你想要的是多個編輯者的共享專案，那就是專案編輯者角色，在 Cloud Pro 和自主託管企業版中有提供。所以除了企業版之外，相應的選項是 Cloud Pro，在一個實例上有多個編輯者的專案和每個專案的角色，正好適合你的 2-3 人相互依賴的工作流程。但在自主託管上沒有中間層，只有企業版授權才包含專案和 RBAC。用一個共享實例加上專案比用每個客户一個實例要好，每個專案的角色將各個客户的工作隔離，同時你的團隊可以共享他們需要的內容。
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.
1個讚
Thanks for the input everyone!
@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.
2個讚
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.