# How I handle multi-tenant n8n for agency clients (isolated instance per client, shared updates) **URL:** \ **Category:** Tips & Tricks\ **Tags:** http-request, núcleo, construcción-de-fluj, transformación-de-da, nodo, credenciales, ia, código, anuncios-de-clientes, implementación\ **Created:** [July 1, 2026, 5:35am UTC](https://community.n8n.io/t/how-i-handle-multi-tenant-n8n-for-agency-clients-isolated-instance-per-client-shared-updates/301614 "2026-07-01T05:35:12Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![SiennaBase](https://dub1.discourse-cdn.com/n8n/user_avatar/community.n8n.io/siennabase/32/180181_2.png) [@SiennaBase](https://community.n8n.io/u/SiennaBase)\ **Post date:** [July 1, 2026, 5:35am UTC](https://community.n8n.io/t/how-i-handle-multi-tenant-n8n-for-agency-clients-isolated-instance-per-client-shared-updates/301614/1 "2026-07-01T05:35:12Z")
I kept seeing the same question here — “what’s the best way to run n8n for multiple clients?” — so I wanted to share the setup that’s been working for me, in case it saves someone the trial and error. **The short answer: one isolated n8n instance per client, managed from a shared stack.** After trying the single-instance-with-projects route, I went with a container-per-client approach. Here’s the reasoning and the architecture: **Why instance-per-client** - Real isolation. Each client’s credentials (Salesforce, HubSpot, Gmail tokens) live in their own container and their own database schema. No risk of cross-tenant leaks. - Process isolation. If one client’s n8n misbehaves, it doesn’t take down the others. - Cleaner offboarding. Parting ways with a client = tear down one container, done. **The architecture** - Docker Compose stack: Caddy (reverse proxy + automatic HTTPS), Postgres, Qdrant (for RAG use cases), and a base n8n. - Postgres with schema-per-tenant: one database, but each client gets an isolated schema. Good balance between isolation and not running 20 separate databases. - Caddy with wildcard subdomains: each client gets [client.yourdomain.com](http://client.yourdomain.com) with HTTPS handled automatically. Adding a client doesn’t mean touching DNS each time. - A CLI that provisions a new client in one command: creates the schema, spins up the container, wires the subdomain, reloads the proxy. ~30 seconds instead of the usual half-day of manual setup. **Two things that bit me (so they don’t bite you)** - The N8N\_ENCRYPTION\_KEY must be consistent and backed up. If it changes, every client’s stored credentials become unrecoverable. Generate it once, keep it safe, never regenerate. - Pin your n8n version. Running :latest means clients created at different times can end up on different versions, and an update can break workflows with no warning. **Updates across all clients** Because every client runs the same pinned image from a shared compose, rolling an update is one operation, not one-per-client. That was the part I worried about most and it turned out to be the easiest. * * * I ended up packaging all of this (the stack, the provisioning CLI, backup/restore per client, a few ready-made workflow templates) into a project called Siennabase, since I was tired of rebuilding it. If anyone wants to skip the setup, it’s at siennabase.dev Happy to answer questions about any of the architecture decisions. ---
**Author:** ![sarrazola](https://dub1.discourse-cdn.com/n8n/user_avatar/community.n8n.io/sarrazola/32/189194_2.png) [@sarrazola](https://community.n8n.io/u/sarrazola)\ **Post date:** [September 8, 2026, 4:13am UTC](https://community.n8n.io/t/how-i-handle-multi-tenant-n8n-for-agency-clients-isolated-instance-per-client-shared-updates/301614/2 "2026-09-08T04:13:49Z")
The per-client rollback path seems especially important here. A shared pinned image makes deployment consistent, but a database migration can make rolling the image back insufficient. I would test restoring one client’s database and encryption key into a separate environment, and run an update against a test client before rolling it across the stack. For WhatsApp agency deployments, I also find it useful to distinguish workflow execution from client-facing operations: conversations, knowledge bases, branding and human handoff. Disclosure: I develop [OpenLivery](https://github.com/sarrazola/openlivery), an MIT-licensed, self-hosted platform focused on those multi-client agent workspaces. It does not provision n8n instances; the instance-per-client approach you describe addresses a different part of the setup. How do you handle per-client restores when an update includes a schema migration? Are backups and encryption keys versioned together with the pinned image?