Hey everyone! I need some guidance on scaling my automation platform. Right now I have a working system that uses n8n, Supabase, Apollo, LangChain, and OpenAI to handle automated email outreach. The basic flow works great - it finds leads, sends emails, tracks responses, and handles follow-ups.
My client wants to turn this into a product they can sell to other businesses. The tricky part is they want to keep n8n running from one central location while giving each customer their own separate workspace. Each customer should only see their own campaigns and data.
I’m trying to figure out the best way to handle:
Making sure customers can’t see each other’s stuff
Setting limits like max 1000 leads per customer
Letting each customer use their own email domains
Adding new features like custom AI agents later
Getting alerts when things break or emails bounce
The current setup already has row level security in Supabase, some reporting dashboards, and email tracking through Mailgun.
What’s the cleanest way to architect this? Should I duplicate the n8n workflows for each tenant or use some kind of dynamic routing? Any thoughts on database design for this kind of multi-tenant setup?
I’ve hit similar multi-tenant automation issues before. The biggest lesson? Build tenant isolation into your architecture from the start - don’t bolt it on later. Skip duplicating workflows. Instead, inject a tenant context layer into every n8n execution. Your workflows should always include a tenant ID parameter that filters data at the query level. For your database, add tenant_id columns to every table and make sure your Supabase RLS policies are rock solid. I learned this the hard way when a bad policy config almost leaked customer data during deployment. Set up tenant-specific config tables for email domains, rate limits, and feature flags. This lets you customize behavior per customer without touching code. Build a centralized tenant management service - it’ll handle provisioning, enforce limits, and monitor health. This service can intercept n8n webhook calls and apply tenant rules before execution. One last thing: implement tenant-aware logging and alerts from day one. Trust me, debugging multi-tenant problems without proper context is a nightmare.
Honestly, routing beats duplicating workflows every time. Handle tenant limits at the queue level - don’t jam that logic into workflows. I’d throw in a tenant service to validate requests before they hit n8n. Makes debugging way easier when stuff breaks. Database-wise, slap tenant_id on everything, but partition if you’re expecting heavy traffic. Email domain switching is pretty straightforward with n8n’s dynamic credentials.
Multi-tenant n8n is tricky but totally doable with the right setup. Don’t duplicate workflows - instead, build parameterized ones that pull tenant config at runtime. Use webhook triggers with routing logic that checks permissions before anything runs. The secret sauce is a middleware layer that grabs all n8n calls and auto-injects tenant context. For the database, I’d go with schema-per-tenant plus RLS. It beats shared tables with tenant_id columns, especially when customers have wildly different data volumes. Monitor everything at the tenant level using n8n’s execution data API. Track success rates, execution times, and resource usage per customer. For email domains, store SMTP configs per tenant and swap Mailgun settings on the fly within workflows. I’ve had good luck using n8n’s credential system for tenant-specific API keys. Just make sure your error handling doesn’t leak tenant data in error messages or logs.