Hi everyone! I’m building an automation system using n8n for email marketing workflows. My setup includes OpenAI, LangChain, Supabase, Mailgun, and Notion for handling campaign creation, delivery, tracking, and responses. Currently running everything through Docker Compose locally, but planning to move to Kubernetes after testing with around 6-7 customers. I’m trying to figure out the best multi-tenant approach since I don’t want customers accessing the n8n interface directly. Instead of Notion triggers, I want to build a custom web app where clients can start campaigns and check progress. I’m considering a container-per-customer setup where each client gets their own isolated n8n instance with separate workflows and configs. All containers would connect to the same Supabase database so I can track all campaigns, leads, and events centrally. Then build a frontend that lets clients manage their stuff without seeing the n8n dashboard. Questions I have: Is this isolated container approach good for n8n multi-tenancy? Any issues with having all tenants share one Supabase backend? What other architectures work well (like workflow orchestrators, role-based access in single n8n, etc.)? Looking for advice from anyone running multi-tenant n8n in production. Thanks for any insights!
I’ve been running n8n in production for 18 months now and the container-per-client approach works really well. Started with 10 clients, now handling 40+ instances. The isolation is fantastic - no cross-tenant data leaks, individual scaling, and you can customize workflows per client without affecting others. Resource overhead isn’t as bad as you’d think if you set proper limits. The shared Supabase setup is solid, we do something similar with a central PostgreSQL instance. Just make sure your database schema has proper tenant_id fields everywhere and solid row-level security policies. One thing to watch - you’ll want good observability across all those containers. We use Prometheus with custom metrics to track workflow performance per tenant. This architecture scales way better than trying to hack multi-tenancy into a single n8n instance, which wasn’t designed for it.
We faced this exact choice last year and went with a hybrid approach that might work for you. Started with one n8n instance but quickly ran into workflow conflicts and resource issues between tenants. The container-per-client model you’re talking about is definitely the right move for production - especially when you need that isolation. But once you move to Kubernetes, throw Istio or another service mesh into the mix. It’ll handle communication between services and make managing all those n8n instances way easier. For the shared Supabase backend, we had good luck but you’ll need proper connection pooling since each n8n container maintains its own DB connections. PgBouncer worked great for us here. One tip - build your tenant provisioning automation early. Manually spinning up new client containers gets old fast, and you’ll want automated deployment pipelines for pushing updates across all tenant instances.
tbh, going for a container-per-client for just 6-7 customers seems like a lot. a single n8n instance with good tenant isolation in your frontend might still give you the control you need. you can always switch to that container setup later if it makes sense.