نحن وكالة أتمتة الذكاء الاصطناعي ندير n8n كعمود فقري لتسليم خدماتنا للعملاء، ونواجه عائقاً أثناء التوسع. أود أن أسمع كيف حل وكالات أخرى هذه المشكلة.
وضعنا الحالي:
ندير عدداً متزايداً من نسخ العملاء المنفصلة.
نحتاج إلى تعاون من قبل 2-3 أعضاء فريق داخل نفس المشروع — ليس دائماً في نفس سير العمل، لكن مع تنسيق وثيق وتبعيات متبادلة.
في Community Edition بالاستضافة الذاتية، لا توجد RBAC ولا مشاركة للمشاريع/سير العمل: يرى المسؤول فقط جميع سير العمل، بينما يرى المستخدمون الآخرون فقط سيرهم الخاص. لذا لا يمكن لأعضاء الفريق العمل على سير عمل بعضهم البعض، مما يجعل التسليم المتعاون والموجه لعدة عملاء مستحيلاً بشكل أساسي.
نحاول إيجاد إعداد مناسب الحجم لهذا — شيء متناسب مع فريق يحتاج إلى التعاون، دون الإفراط في الهندسة.
أسئلتي للمجتمع:
إذا كنت تدير وكالة على n8n عبر عدة عملاء، كيف يتم إعداد الوصول والتعاون لديك؟ نسخة واحدة مشتركة مع مشاريع + أدوار، أم نسخة واحدة لكل عميل؟
هل هناك أي طريقة مدعومة للحصول على التعاون بين الفريق (مشاريع مشتركة / محررون متعددون) في Community، أو خيار مدفوع متناسب لفريق صغير — بدلاً من الانتقال مباشرة إلى Enterprise؟
إذا كنت تقوم بتوسيع n8n كوكالة وواجهت نفس الشيء، ملاحظة سريعة حول إعدادك (أو تصويت إيجابي حتى ترى n8n الطلب) سيكون مفيداً جداً.
@fernandesnoa صحيح، Community ليس لديه مشاريع أو RBAC، مسؤول واحد والجميع معزولون. ما تريده، مشروع مشترك مع عدة محررين، هو دور Project Editor، وهو متاح في Cloud Pro والعروض Enterprise ذاتية الاستضافة. إذن بصرف النظر عن Enterprise، الخيار المناسب هو Cloud Pro، مشاريع مع محررين متعددين وأدوار لكل مشروع على نسخة واحدة، بالضبط لـ 2-3 أشخاص لديهم سير عمل معتمد على بعضهم البعض. أما في الاستضافة الذاتية فلا توجد طبقة وسيطة، المشاريع و RBAC تأتي فقط مع ترخيص Enterprise. ونسخة مشتركة واحدة مع مشاريع أفضل من نسخة لكل عميل، أدوار كل مشروع تحمي عمل كل عميل بينما يشارك فريقك ما يحتاجه.
وكالة الحماية (خطة العمل المدفوعة/Pro): مثيل واحد عالي الأداء حيث يتعاون فريقك وينشئ القوالب واختبر عملاء الذكاء الاصطناعي الجدد. هنا حيث يحدث “البحث والتطوير” لديك.
إنتاج العميل (Community Edition): بمجرد إتقان سير العمل في الحماية، يتم نشره على مثيل Community خفيف الوزن ومعزول للعميل.
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.
You’ve hit the exact “growth wall” every agency faces with n8n. To be blunt: Community Edition is not designed for agency collaboration. Its architecture is “single-admin” by design, and there is no “middle tier” workaround—RBAC and multi-editor Projects are gated strictly behind the Enterprise license.
Here is the strategic breakdown of how agencies typically handle this:
1. The Reality of “Proportionate” Scaling
If you cannot jump to Enterprise yet, the industry-standard workaround is Cloud Pro.
Why: You get Project-level RBAC and multiple editors on a single instance.
The Benefit: It centralizes your team and credentials, allowing you to wall off client work into specific projects using “Project Editor” roles without giving them access to your entire workflow library or global connection secrets.
2. Why “Instance-per-Client” is a Maintenance Trap
I strongly advise against running an instance per client unless they require complete infrastructure isolation (e.g., for HIPAA/GDPR compliance).
The Overhead: You will end up manually updating and maintaining dozens of Docker containers, tracking environmental variables, and handling separate credential stores. It becomes a massive DevOps burden that kills your profit margins as an agency.
3. The “Hybrid” Survival Strategy
If you are currently self-hosting and scaling fast:
Adopt a “Single Source” repo: Push your workflows to a GitHub repository (using the n8n GitHub integration). This allows your team to at least version control and peer-review code, even if they can’t edit the same live instance simultaneously.
Credential Discipline: Treat your credential manager as your most sensitive asset. If you stay on Community, define strict naming conventions for credentials (e.g., CLIENT_NAME | TYPE | SERVICE) so the team doesn’t accidentally trigger a production workflow for the wrong account.
If you’re at the point where 2-3 people are tripping over each other’s work, the cost of the time lost to version collisions and siloed workflows is already higher than the cost of a Pro subscription.
Following this thread with a lot of interest — @Rory_Hayes, your list (which clients have which workflows, which are critical, who owns each, what proves it’s healthy, what’s reportable) is exactly the gap I’ve been looking into. And @dima_automation, the “silent until the client emails” failure mode is the specific thing I’m trying to solve for.
I’m building something narrow for this: one dashboard across your n8n instances showing workflow health and ownership, with an alert before a client notices something went quiet — starting with n8n, not trying to replace projects/RBAC, just sitting above it the way Rory described.
Not selling anything yet — trying to make sure the mvp I’m building will be useful. If any of you (or @fernandesnoa, @achamm, @kjooleng) would be up for a quick 15-min call about how you handle this today, I’d really appreciate it — and happy to share back what I learn from talking to others hitting the same wall. Anyone else running into this, feel free to jump in too.
Keep in mind that number 2 while it can be a maintenance trap if you are hosting the n8n instances for free for your clients using Cloud for each client instance reduces it a lot.
It may be worth thinking about our license as well, While you can offer consulting services around n8n running client workflows in your instance rather than theres could be against the license terms if you are using their credentials for a service that you do not own.
