Hosting n8n for multiple clients: the multi-instance architecture for agencies and freelancers

More and more agencies and freelancers sell automation built on n8n: email triage, CRM syncs, AI pipelines, reporting. The first client is easy — one instance, one server, everyone's happy. It's at the second or third client that the real architecture question shows up: should all clients share one big n8n instance, or should each get their own?

The short answer: one instance per client, isolated in its own Docker container, behind a shared reverse proxy. This guide covers why the shared instance is a trap for an agency, what n8n's license implies for this business model, the complete multi-instance architecture (directory layout, parameterized docker-compose, Traefik), and then the day-to-day: sizing, updates, backups and rebilling.

One shared instance for every client: the trap

Putting all clients into the same n8n instance looks economical and easy to administer. Yet three concrete problems pile up very quickly.

Every client's credentials in one place. In an n8n instance, anyone with access to the editor can potentially use the existing credentials in their own workflows — even without being able to read the secrets themselves. An intern building a workflow for client A can wire up client B's Gmail account, by mistake or out of curiosity. Fine-grained separation does exist in n8n through the Projects feature and RBAC, which structure permissions per project, but it's reserved for paid plans at the time of writing. On a shared Community instance, the separation rests on discipline, not on the software.

No fault isolation. A client A workflow that loops, loads a 2 GB file or chains long AI calls saturates the memory and CPU of the entire instance: client B's webhooks stop responding, client C's scheduled executions fall behind. An incident at one client becomes an incident at every client.

A GDPR headache. n8n's execution logs retain the data flowing through workflows. On a shared instance, personal data processed for several clients — meaning several distinct data controllers — ends up mixed in the same execution database. Documenting that in a record of processing activities, answering an erasure request, or handing back "their" data to a departing client becomes considerably harder than it needs to be.

None of this trade-off is specific to n8n: it's the classic multi-tenancy dilemma. A study by Bezemer and Zaidman presented at ACM's IWPSE-EVOL workshop in 2010, "Multi-tenant SaaS applications: maintenance dream or nightmare?", analyzes exactly this compromise in multi-tenant SaaS applications: pooling reduces operating costs, but at the price of sharply increased maintenance complexity and risks of interference between tenants. That's precisely an n8n agency's equation — except at agency scale, the cost of isolation comes down to a few extra containers.

What n8n's license says (read it carefully)

Before building the offer, a point many agencies discover too late: n8n is not under a classic open source license, but under the Sustainable Use License. Among other things, this license restricts commercial use of the kind "hosting n8n to resell it as a service" — typically, offering n8n white-labeled or selling third parties access to the software itself.

Hosting and operating workflows for a client, as part of an automation engagement where the client buys an outcome (their emails sorted, their CRM synced) rather than access to n8n, appears to be a different case. But the line depends on how your offer is packaged, billed and presented, and it could be assessed differently from one situation to another. This guide is not legal advice: read the official license page, and if your model edges toward reselling access — clients logging into the editor themselves, a flat-fee "managed n8n" offer — verify your case with n8n or a lawyer before launching.

The recommended architecture: one Docker instance per client

The principle: each client gets their own n8n container, their own data volume, their own PostgreSQL database and their own subdomain (client-a.agency.com, client-b.agency.com). In front, a single reverse proxy — Traefik is the natural candidate; our guide to HTTPS and custom domains with Traefik or Caddy walks through the setup — routes each subdomain to the right container and handles TLS certificates automatically.

On the server, the directory layout stays readable even with fifteen clients:

/srv/n8n-clients/
├── traefik/
│   ├── docker-compose.yml
│   └── letsencrypt/          # certificates managed by Traefik
├── client-a/
│   ├── docker-compose.yml    # identical for every client
│   └── .env                  # everything specific to the client
├── client-b/
│   ├── docker-compose.yml
│   └── .env
└── client-c/
    ├── docker-compose.yml
    └── .env

The docker-compose.yml is strictly identical from one client folder to the next; only the .env configuration changes. That's what makes the architecture operable: a fix or an improvement to the compose file propagates by simply copying a file.

# /srv/n8n-clients/client-a/docker-compose.yml — identical for each client
services:
  n8n:
    image: docker.n8n.io/n8nio/n8n:${N8N_VERSION}
    restart: unless-stopped
    environment:
      - N8N_HOST=${CLIENT_DOMAIN}
      - WEBHOOK_URL=https://${CLIENT_DOMAIN}/
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_DATABASE=n8n
      - DB_POSTGRESDB_USER=n8n
      - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
    volumes:
      - n8n_data:/home/node/.n8n
    networks:
      - default
      - traefik_public
    labels:
      - traefik.enable=true
      - traefik.http.routers.${CLIENT_ID}.rule=Host(`${CLIENT_DOMAIN}`)
      - traefik.http.routers.${CLIENT_ID}.tls.certresolver=letsencrypt
      - traefik.http.services.${CLIENT_ID}.loadbalancer.server.port=5678
    depends_on:
      - postgres

  postgres:
    image: postgres:16
    restart: unless-stopped
    environment:
      - POSTGRES_DB=n8n
      - POSTGRES_USER=n8n
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
    volumes:
      - pg_data:/var/lib/postgresql/data

volumes:
  n8n_data:
  pg_data:

networks:
  traefik_public:
    external: true

And the .env that carries the client's entire identity:

# /srv/n8n-clients/client-a/.env
CLIENT_ID=client-a
CLIENT_DOMAIN=client-a.agency.com
N8N_VERSION=1.x.y            # pin a precise version, never latest
N8N_ENCRYPTION_KEY=...       # generated once, kept safe (see below)
POSTGRES_PASSWORD=...        # unique per client

Two details that matter. First, Docker Compose prefixes volumes and containers with the folder name: client-a_n8n_data and client-b_n8n_data will never collide. Second, each client has their own Postgres database in their own container: client A's executions, encrypted credentials and logs physically live somewhere else than client B's. That separation is what makes the thorny shared-instance questions trivial: handing back a departing client's data means handing over their volumes; purging their logs means purging their database and theirs alone.

Sizing: how many clients per server?

No need to rent one VPS per client from day one. An idle n8n instance with its Postgres database consumes a few hundred MB of RAM; a properly sized server — our guide to choosing a VPS for n8n gives the orders of magnitude — pools several small clients without difficulty when their workflows run a few times an hour.

The useful segmentation is by execution profile:

• Small clients (a few scheduled workflows, modest volumes) share a pooled VPS. That's the majority of an agency's client base.
• A heavy client — large volumes, long AI workflows, high-traffic webhooks — deserves their own server as soon as their executions weigh on the neighbors. The migration is a folder move: copy client-x/ and its volumes to the new VPS, update the DNS, done.
• A client that genuinely scales moves to queue mode with Redis and workers on their own instance, without touching anyone else's. That's the decisive advantage of multi-instance: each client evolves at their own pace.

Operating the fleet day to day

Ten instances don't take ten times the work of one, provided you industrialize four routines from the start.

Updates, in series and in waves. All instances share the same compose file; updating means changing N8N_VERSION in each .env and running docker compose pull && docker compose up -d folder by folder — a three-line shell loop. Apply the method from our guide to updating n8n on Docker without breaking anything, with one agency-specific refinement: update your internal instance and one low-stakes client first, let it run for a day or two, then roll the wave out to the rest of the fleet.

One encryption key per client, backed up off-server. Each instance has its own N8N_ENCRYPTION_KEY, which encrypts that client's credentials in the database. Lose the key and you lose all of the client's credentials, even with perfect backups. Record each key in the agency's password manager, in an entry under the client's name, the moment the instance is created.

Per-instance backups. One pg_dump per client database plus a copy of the n8n volume, following the routine detailed in our PostgreSQL backup and restore guide. Isolation pays off here again: restoring client A after a bad manipulation doesn't touch clients B and C in any way.

Centralized monitoring and Git versioning. A single monitoring stack watches every container and every /healthz endpoint in the fleet — see our guide to monitoring your n8n instance — and alerts you before the client does. On the workflow side, one Git repository per client (or one agency repository with a folder per client) exports and versions workflows following the method in our guide to backing up and versioning workflows with Git: it's your record of what was delivered, and your safety net before every change at a client's.

Rebilling the hosting: a sales argument

The infrastructure cost of this model is low and — above all — predictable: the slice of VPS a small client consumes counts in single-digit euros per month, not dozens. Many agencies simply fold it into the monthly maintenance retainer, with an honest margin for the real operations work (updates, backups, monitoring).

It's also a selling point against SaaS automation platforms billed per task or per operation: there, the client's bill mechanically climbs with the success of their automations. With a dedicated n8n instance, the client can run ten times more workflows next month without the hosting line moving. For an SMB automating seriously, that predictability adds up fast.

The honest alternative: n8n Cloud in the client's name

Self-hosted multi-instance isn't the right answer for everyone. Some clients want to own their instance without depending on your server: because they want to be able to switch providers without a migration, or because their internal policy rules out hosting with a non-specialized third party.

For them, the right setup is often n8n Cloud subscribed in the client's name: the client pays their subscription directly to n8n, remains the account holder, and invites you as a user to build and operate the workflows. You lose the hosting margin, but you gain a reassured client and zero operations. The criteria for choosing between the two worlds — cost, control, data constraints — are detailed in our n8n self-hosted vs cloud comparison; it's a good read to send the client so you can decide together.

Common pitfalls

• Starting on a shared instance "for now": by the third client, migrating to multi-instance means moving credentials and webhooks one by one. Isolating from the first client costs ten extra minutes.
• Reusing the same N8N_ENCRYPTION_KEY (or the same Postgres password) for every client: container isolation protects nothing if all the secrets are identical.
• Not pinning the n8n version (latest in the .env): a harmless restart becomes a surprise upgrade on a client's instance, with no prior testing.
• Forgetting to back up the encryption keys off-server: a Postgres backup without its matching N8N_ENCRYPTION_KEY restores credentials that can't be decrypted.
• Selling access to n8n rather than the service without having checked the Sustainable Use License: if your offer looks like white-labeled n8n, reread the official license page and get your case validated.
• Giving a client editor access on an instance shared with other clients: that's exactly the credential-leak scenario multi-instance exists to prevent.
• Neglecting the GDPR paperwork on the agency side: even with isolated instances, you remain a processor under GDPR for each client; isolation simplifies the documentation, it doesn't exempt you from it.

In summary

For an agency or freelancer hosting n8n for clients, the winning architecture is simple: one container, one volume, one Postgres database and one subdomain per client, a shared Traefik in front, and a per-folder .env configuration that keeps the fleet uniform and scriptable. The shared instance saves a few hundred MB of RAM; it costs you the isolation of credentials, failures and data — precisely what a client is buying when they entrust you with their automations. What's left is filling those instances: that's where a catalog of proven workflows makes the difference between artisanal delivery and an offer that deploys in hours. The Inbox AI Pack (€79) is exactly that kind of building block — AI-powered email triage and prioritization ready to install, which you can deploy and adapt for each client from their dedicated instance.