Héberger n8n pour plusieurs clients : l'architecture multi-instances pour agences et freelances

De plus en plus d'agences et de freelances vendent de l'automatisation construite sur n8n : tri d'emails, synchronisation CRM, pipelines IA, reporting. Le premier client est simple — une instance, un serveur, tout le monde est content. C'est au deuxième ou au troisième que la vraie question d'architecture arrive : faut-il faire monter tous les clients dans la même grosse instance n8n, ou donner à chacun la sienne ?

La réponse courte : une instance par client, isolée dans son propre conteneur Docker, derrière un reverse proxy commun. Ce guide détaille pourquoi l'instance partagée est un piège pour une agence, ce que la licence de n8n implique pour ce modèle, l'architecture multi-instances complète (arborescence, docker-compose paramétré, Traefik), puis le quotidien : dimensionnement, mises à jour, sauvegardes et refacturation.

Une instance partagée pour tous les clients : le piège

Mettre tous les clients dans la même instance n8n paraît économique et simple à administrer. Trois problèmes concrets s'accumulent pourtant très vite.

Les credentials de tous les clients au même endroit. Dans une instance n8n, toute personne qui a accès à l'éditeur peut potentiellement utiliser les credentials existants dans ses propres workflows — même sans pouvoir en lire les secrets. Un stagiaire qui construit un workflow pour le client A peut brancher, par erreur ou par curiosité, le compte Gmail du client B. Le cloisonnement fin existe bien dans n8n via la fonctionnalité Projects et le RBAC, qui structurent les droits par projet, mais elle est réservée aux plans payants au moment d'écrire ces lignes. Sur une instance Community partagée, la séparation repose sur la discipline, pas sur le logiciel.

Aucune isolation des pannes. Un workflow du client A qui part en boucle, charge un fichier de 2 Go ou enchaîne les appels IA sature la mémoire et le CPU de l'instance entière : les webhooks du client B ne répondent plus, les exécutions planifiées du client C prennent du retard. Un incident chez un client devient un incident chez tous.

Un casse-tête RGPD. Les logs d'exécution de n8n conservent les données qui transitent dans les workflows. Sur une instance partagée, les données personnelles traitées pour plusieurs clients — donc pour plusieurs responsables de traitement distincts — se retrouvent mélangées dans la même base d'exécutions. Documenter cela dans un registre des traitements, répondre à une demande d'effacement ou restituer « ses » données à un client qui part devient nettement plus compliqué que nécessaire.

Cet arbitrage n'a rien de spécifique à n8n : c'est le dilemme classique du multi-tenant. Une étude de Bezemer et Zaidman présentée en 2010 au workshop IWPSE-EVOL de l'ACM, « Multi-tenant SaaS applications: maintenance dream or nightmare? », analyse précisément ce compromis dans les applications SaaS multi-locataires : la mutualisation réduit les coûts d'exploitation, mais au prix d'une complexité de maintenance nettement accrue et de risques d'interférence entre locataires. C'est exactement l'équation d'une agence n8n — sauf qu'à l'échelle d'une agence, le surcoût de l'isolation se limite à quelques conteneurs de plus.

Ce que dit (prudemment) la licence n8n

Avant de construire l'offre, un point que beaucoup d'agences découvrent trop tard : n8n n'est pas sous licence open source classique, mais sous Sustainable Use License. Cette licence restreint notamment l'usage commercial de type « héberger n8n pour le revendre en tant que service » — typiquement, proposer n8n en marque blanche ou vendre à des tiers l'accès au logiciel lui-même.

Héberger et opérer des workflows pour un client, dans le cadre d'une prestation d'automatisation où le client achète un résultat (ses emails triés, son CRM synchronisé) et non l'accès à n8n, semble relever d'un cas différent. Mais la frontière dépend de la façon dont votre offre est packagée, facturée et présentée. Ce guide n'est pas un conseil juridique : lisez la page officielle de la licence, et si votre modèle s'approche de la revente d'accès — clients qui se connectent eux-mêmes à l'éditeur, offre « n8n managé » vendue au forfait — vérifiez votre cas auprès de n8n ou d'un juriste avant de lancer.

L'architecture recommandée : une instance Docker par client

Le principe : chaque client obtient son propre conteneur n8n, son propre volume de données, sa propre base PostgreSQL et son propre sous-domaine (client-a.agence.fr, client-b.agence.fr). Devant, un unique reverse proxy — Traefik est le candidat naturel, notre guide HTTPS et nom de domaine avec Traefik ou Caddy en détaille la mise en place — route chaque sous-domaine vers le bon conteneur et gère les certificats TLS automatiquement.

Sur le serveur, l'arborescence reste lisible même avec quinze clients :

/srv/n8n-clients/
├── traefik/
│   ├── docker-compose.yml
│   └── letsencrypt/          # certificats gérés par Traefik
├── client-a/
│   ├── docker-compose.yml    # identique pour tous les clients
│   └── .env                  # tout ce qui est propre au client
├── client-b/
│   ├── docker-compose.yml
│   └── .env
└── client-c/
    ├── docker-compose.yml
    └── .env

Le docker-compose.yml est strictement identique d'un dossier client à l'autre ; seule la configuration .env change. C'est ce qui rend l'architecture exploitable : un correctif ou une évolution du compose se propage par simple copie de fichier.

# /srv/n8n-clients/client-a/docker-compose.yml — identique pour chaque 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

Et le .env qui porte toute l'identité du client :

# /srv/n8n-clients/client-a/.env
CLIENT_ID=client-a
CLIENT_DOMAIN=client-a.agence.fr
N8N_VERSION=1.x.y            # épinglez une version précise, jamais latest
N8N_ENCRYPTION_KEY=...       # générée une fois, conservée précieusement (voir plus bas)
POSTGRES_PASSWORD=...        # unique par client

Deux détails qui comptent. D'abord, Docker Compose préfixe volumes et conteneurs par le nom du dossier : client-a_n8n_data et client-b_n8n_data ne se marcheront jamais dessus. Ensuite, chaque client a sa propre base Postgres dans son propre conteneur : les exécutions, les credentials chiffrés et les logs du client A vivent physiquement ailleurs que ceux du client B. C'est cette séparation qui rend triviales les questions qui étaient épineuses en instance partagée : restituer les données d'un client qui part, c'est lui remettre ses volumes ; purger ses logs, c'est purger sa base à lui.

Dimensionnement : combien de clients par serveur ?

Inutile de louer un VPS par client dès le premier jour. Une instance n8n au repos avec sa base Postgres consomme quelques centaines de Mo de RAM ; un serveur correctement dimensionné — notre guide choisir son VPS pour n8n donne les ordres de grandeur — mutualise sans difficulté plusieurs petits clients dont les workflows tournent quelques fois par heure.

La segmentation utile se fait par profil d'exécution :

• Les petits clients (quelques workflows planifiés, des volumes modestes) cohabitent sur un VPS mutualisé. C'est le cas de la majorité des clients d'une agence.
• Un client intensif — gros volumes, workflows IA longs, webhooks à fort trafic — mérite son propre serveur dès que ses exécutions pèsent sur les voisins. La migration est un déménagement de dossier : on copie client-x/ et ses volumes sur le nouveau VPS, on met à jour le DNS, terminé.
• Un client qui scale vraiment passe en mode queue avec Redis et des workers sur son instance à lui, sans toucher à celles des autres. C'est l'avantage décisif du multi-instances : chaque client évolue à son rythme.

Exploiter la flotte au quotidien

Dix instances ne demandent pas dix fois le travail d'une seule, à condition d'industrialiser quatre routines dès le départ.

Les mises à jour, en série et par vague. Toutes les instances partagent le même compose ; mettre à jour, c'est changer N8N_VERSION dans chaque .env et relancer docker compose pull && docker compose up -d dossier par dossier — une boucle shell de trois lignes. Appliquez la méthode de notre guide mettre à jour n8n sous Docker sans rien casser, avec un raffinement propre aux agences : mettez d'abord à jour votre instance interne et un client peu sensible, laissez tourner un jour ou deux, puis déployez la vague sur le reste du parc.

Une clé de chiffrement par client, sauvegardée hors serveur. Chaque instance a sa propre N8N_ENCRYPTION_KEY, qui chiffre les credentials du client en base. Perdre cette clé, c'est perdre tous les credentials du client, même avec des sauvegardes parfaites. Consignez chaque clé dans le gestionnaire de mots de passe de l'agence, dans une entrée au nom du client, dès la création de l'instance.

Des sauvegardes par instance. Un pg_dump par base client plus la copie du volume n8n, selon la routine détaillée dans notre guide sauvegarde et restauration PostgreSQL. L'isolation paie encore ici : restaurer le client A après une fausse manipulation ne touche en rien les clients B et C.

Un monitoring centralisé et du versionnage Git. Une seule stack de supervision surveille tous les conteneurs et tous les endpoints /healthz du parc — voir notre guide superviser son instance n8n — et vous prévient avant le client. Côté workflows, un dépôt Git par client (ou un dépôt par agence avec un dossier par client) exporte et versionne les workflows selon la méthode de notre guide sauvegarder et versionner ses workflows avec Git : c'est votre trace de ce qui a été livré, et votre filet de sécurité avant chaque modification chez un client.

Refacturer l'hébergement : un argument commercial

Le coût d'infrastructure de ce modèle est faible et — surtout — prévisible : la part de VPS consommée par un petit client se compte en euros par mois, pas en dizaines. Beaucoup d'agences l'intègrent simplement dans le forfait de maintenance mensuel, avec une marge honnête pour le travail d'exploitation réel (mises à jour, sauvegardes, supervision).

C'est aussi un argument de vente face aux plateformes SaaS d'automatisation facturées à la tâche ou à l'opération : chez elles, la facture du client grimpe mécaniquement avec le succès de ses automatisations. Avec une instance n8n dédiée, le client exécute dix fois plus de workflows le mois prochain sans que la ligne d'hébergement bouge. Pour une PME qui automatise sérieusement, cette prévisibilité se chiffre vite.

L'alternative honnête : n8n Cloud au nom du client

Le multi-instances self-hosted n'est pas la bonne réponse pour tout le monde. Certains clients veulent être propriétaires de leur instance sans dépendre de votre serveur : parce qu'ils veulent pouvoir changer de prestataire sans migration, ou parce que leur politique interne exclut l'hébergement chez un tiers non spécialisé.

Pour eux, le bon montage est souvent n8n Cloud souscrit au nom du client : le client paie son abonnement directement à n8n, reste titulaire du compte, et vous invite comme utilisateur pour construire et opérer les workflows. Vous perdez la marge d'hébergement, mais vous gagnez un client serein et zéro exploitation. Les critères de choix entre les deux mondes — coût, maîtrise, contraintes de données — sont détaillés dans notre comparatif n8n self-hosted vs cloud — une lecture à envoyer au client pour trancher ensemble.

Pièges fréquents

• Démarrer sur une instance partagée « en attendant » : au troisième client, la migration vers le multi-instances impose de déménager credentials et webhooks un par un. Isoler dès le premier client coûte dix minutes de plus.
• Réutiliser la même N8N_ENCRYPTION_KEY (ou le même mot de passe Postgres) pour tous les clients : l'isolation des conteneurs ne protège plus rien si tous les secrets sont identiques.
• Ne pas épingler la version de n8n (latest dans le .env) : un redémarrage anodin devient une mise à jour surprise sur l'instance d'un client, sans test préalable.
• Oublier de sauvegarder les clés de chiffrement hors serveur : une sauvegarde Postgres sans la N8N_ENCRYPTION_KEY correspondante restaure des credentials indéchiffrables.
• Vendre l'accès à n8n plutôt que la prestation sans avoir vérifié la Sustainable Use License : si votre offre ressemble à du n8n en marque blanche, relisez la page licence officielle et faites valider votre cas.
• Donner les accès de l'éditeur au client sur une instance mutualisée avec d'autres clients : c'est exactement le scénario de fuite de credentials que le multi-instances existe pour empêcher.
• Négliger le registre RGPD côté agence : même avec des instances isolées, vous restez sous-traitant au sens du RGPD pour chaque client ; l'isolation vous simplifie la documentation, elle ne vous en dispense pas.

En résumé

Pour une agence ou un freelance qui héberge n8n pour ses clients, l'architecture gagnante est simple : un conteneur, un volume, une base Postgres et un sous-domaine par client, un Traefik commun devant, et une configuration .env par dossier qui rend le parc uniforme et scriptable. L'instance partagée économise quelques centaines de Mo de RAM ; elle coûte l'isolation des credentials, des pannes et des données — précisément ce qu'un client achète quand il vous confie ses automatisations. Reste à remplir ces instances : c'est là qu'un catalogue de workflows éprouvés fait la différence entre une prestation artisanale et une offre qui se déploie en heures. Le Pack Inbox IA (79 €) est exactement ce genre de brique — un tri et une priorisation d'emails par IA prêts à installer, que vous pouvez déployer et adapter chez chaque client depuis son instance dédiée.