n8n auto-hébergé ou n8n Cloud : comment choisir, d’après notre instance en production

Cet article fait partie de notre guide Agence n8n : automatiser avec n8n et les outils no code.

Par Adam Abdelmoumen, cofondateur d’A2Z Automation Agency, responsable technique des projets d’automatisation et d’IA. Publié le 22 octobre 2026.

En bref. n8n existe en deux formes : n8n Cloud, hébergé et maintenu par l’éditeur, et n8n auto-hébergé (self hosted), que vous installez sur votre propre serveur. La version auto-hébergée est gratuite dans son édition Community et donne un contrôle total sur les données et la configuration ; en échange, quelqu’un doit installer, sauvegarder, surveiller et mettre à jour. Nous faisons tourner notre propre instance sur un serveur virtuel à 2 cœurs et 8 Go de mémoire : au relevé du 22 octobre 2026, elle exécute 41 workflows actifs, environ 2 400 exécutions par jour, avec 0,14 % d’exécutions en erreur sur les 12 derniers jours. Ce qui a vraiment demandé du travail, ce n’est pas l’installation, c’est la surveillance.

Cet article fait partie de notre dossier agence n8n, où nous expliquons comment nous construisons et exploitons des automatisations n8n pour nos clients.

Les deux options et ce que dit l’éditeur

La documentation officielle de n8n est claire : « n8n offers two primary deployment options: n8n Cloud (fully-managed) and Self-hosted (deploy on your own infrastructure) ». Sa grille de décision recommande n8n Cloud si vous voulez démarrer tout de suite, si vous n’avez pas de compétence technique en interne ou si vous ne voulez pas gérer d’infrastructure. Elle recommande l’auto-hébergement si vous avez besoin d’un contrôle complet sur l’environnement, si vous avez des cas d’usage personnalisés, si vous disposez déjà d’une infrastructure et de ressources techniques, ou si vous voulez utiliser n8n gratuitement. Pour la production, l’éditeur écrit que les deux options conviennent.

Côté fonctionnalités, l’édition Community auto-hébergée « inclut presque l’ensemble des fonctionnalités de n8n ». Ce qui manque, d’après la même page : les variables personnalisées, les environnements, les secrets externes, le stockage externe des fichiers binaires, la diffusion des journaux (log streaming), le mode multi-main, les projets, le SSO (SAML, LDAP), le partage de workflows et d’identifiants entre utilisateurs, et le versionnage Git. Ces fonctions reviennent avec une licence Business ou Enterprise, en auto-hébergé comme dans le Cloud. Les offres et leur contenu changent régulièrement ; la page des tarifs de n8n reste la seule source à jour.

Sept critères pour trancher

Le choix se joue rarement sur le prix de l’abonnement. Il se joue sur qui porte la responsabilité du service quand quelque chose casse à 3 heures du matin. Voici la grille que nous utilisons avec nos clients.

Si vous n’avez personne pour tenir les lignes « mises à jour », « sauvegardes » et « surveillance », prenez n8n Cloud, ou confiez l’exploitation à un prestataire. Un n8n auto-hébergé sans surveillance est une panne silencieuse en attente.

Notre instance en chiffres (relevé du 22 octobre 2026)

Nous hébergeons n8n sur un serveur virtuel partagé avec 18 autres conteneurs (reverse proxy, SSO, outils internes). Les chiffres ci-dessous sont lus directement dans la base de données de l’instance et dans les journaux du serveur, le 22 octobre 2026.

Le taux d’erreur de 0,14 % ne mesure pas la qualité de n8n mais celle des services que nos workflows appellent. Nous avons lu les 43 messages d’erreur : 34 viennent d’un seul workflow interne de prospection, lancé trois fois par jour, dont le fournisseur de données répond « Payment required » depuis le 12 octobre (crédits épuisés) ; 2 viennent d’un identifiant d’API expiré sur un workflow client ; les 7 autres sont des services tiers indisponibles, un serveur DNS en erreur ou une donnée invalide. Un workflow bien conçu prévoit ces cas (nouvelle tentative, puis alerte) ; aucune de ces 43 erreurs n’a nécessité d’intervention sur le serveur.

Ce que l’auto-hébergement nous a vraiment coûté : trois incidents

L’installation initiale a pris une après-midi. Les vrais coûts sont arrivés ensuite, sous forme d’incidents que n8n Cloud nous aurait épargnés ou que nous aurions au moins vus plus tôt.

1. Juillet 2026, 40 heures de nœuds Code figés. Le conteneur qui exécute le code JavaScript et Python des workflows (les task runners) s’est arrêté après le crash d’une dépendance, et n’est pas reparti malgré la règle de redémarrage automatique de Docker. Les workflows sans nœud Code continuaient, les autres attendaient 600 secondes puis échouaient avec « Task request timed out ». Personne n’a été prévenu pendant 40 heures, parce que n8n lui-même fonctionnait. C’est cet incident qui nous a fait écrire notre surveillance externe.
2. Juillet 2026, journaux Docker corrompus. Une rotation de journaux configurée en dehors de Docker a tronqué des fichiers que le démon Docker continuait d’écrire. Résultat : le démon tournait à 136 % de processeur dès qu’on lisait les journaux, et la commande docker logs ne répondait plus. Leçon : laisser Docker gérer lui-même la rotation de ses journaux.
3. Septembre 2026, redémarrage du serveur. Une compilation lourde lancée sur la même machine a saturé la mémoire et provoqué un redémarrage. n8n est reparti seul, mais un autre service de la machine est revenu incomplet. Leçon : ne pas partager un serveur de production avec des tâches de compilation, ou les brider.

Aucun de ces trois incidents n’est une faiblesse de n8n. Ce sont des incidents d’exploitation, c’est-à-dire précisément ce que vous achetez quand vous prenez n8n Cloud, et ce que vous assumez quand vous auto-hébergez.

Comment nous surveillons l’instance

Depuis l’incident des task runners, un script lancé par le planificateur du serveur, toutes les deux minutes, contrôle six choses : la réponse de n8n sur son point de santé interne, l’état des deux conteneurs (n8n et exécuteurs), la présence du message « Task request timed out » dans les journaux, la fraîcheur de la dernière exécution d’un workflow témoin qui tourne en continu, le taux d’erreur de ce workflow sur 30 minutes, et l’expiration du certificat TLS. Le script lit la base de données de n8n directement depuis le serveur, jamais à travers le conteneur : si n8n est mort, il doit pouvoir le dire. Un contrôle de santé de la machine (charge, disque, mémoire) a été ajouté ensuite.

Depuis le 23 août 2026, date de début de nos journaux conservés, ce script a envoyé 4 alertes critiques (deux indisponibilités de n8n, un blocage d’exécuteurs, un workflow témoin arrêté), 15 avertissements de passage par Cloudflare et 162 avertissements de santé du serveur. Ce dernier chiffre est volontairement bavard : la charge du processeur dépasse régulièrement le seuil sur deux cœurs partagés avec dix-huit autres conteneurs. C’est notre prochaine limite à traiter, et un argument honnête pour dimensionner plus large qu’on ne le pense au départ.

Dans quels cas nous recommandons n8n Cloud

Nous installons n8n auto-hébergé chez nos clients parce que nous en assurons l’exploitation, mais nous recommandons n8n Cloud dans trois situations.

• Personne en interne ne touchera jamais au serveur et aucun prestataire n’est engagé sur la maintenance. La différence de coût mensuel entre un abonnement et un serveur ne vaut pas une panne de 40 heures que personne ne voit.
• Vous avez besoin des fonctions d’équipe (partage des workflows et des identifiants, projets, SSO, environnements) sans vouloir gérer une licence auto-hébergée. Elles sont absentes de l’édition Community, d’après la comparaison officielle des éditions.
• Vos workflows ne touchent que des outils SaaS (CRM, messagerie, tableur en ligne) et aucune donnée sensible ne transite : l’argument de la localisation des données pèse alors moins.

À l’inverse, nous restons en auto-hébergé quand les workflows doivent joindre une base de données ou un ERP en réseau privé, quand les données traitées ne doivent pas quitter un serveur choisi (c’est le cas de la plateforme de devis que nous décrivons dans notre article sur les devis automatiques, où même l’IA tourne sur le serveur du client), ou quand le volume d’exécutions dépasserait les plafonds des plans Cloud.

Si vous auto-hébergez : la liste minimale

Voici ce que nous mettons en place sur chaque instance, dans cet ordre. Les commandes et variables exactes sont dans la documentation d’installation Docker et la page sur la sécurisation d’une instance.

1. Docker Compose avec un volume persistant pour les données et un conteneur séparé pour les exécuteurs de code, afin qu’un script de workflow qui plante n’emporte pas n8n.
2. Un reverse proxy avec certificat TLS automatique et, devant lui, un filtrage des adresses IP entrantes : seuls le proxy Cloudflare et vos postes joignent le serveur.
3. Une authentification unique (SSO) devant l’interface, en plus du compte n8n.
4. La purge de l’historique des exécutions (gestion des données d’exécution) : sans elle, la base grossit sans fin. Chez nous : 14 jours ou 30 000 exécutions.
5. Une sauvegarde quotidienne du volume, copiée hors du serveur. La nôtre est encore stockée sur le même disque, avec trois jours de rétention : c’est insuffisant et nous le corrigeons.
6. Une surveillance indépendante de n8n, qui vérifie aussi les exécuteurs de code et un workflow témoin, avec une alerte qui part en moins de trois minutes.
7. Une procédure de mise à jour : lire les notes de version, sauvegarder, mettre à jour, vérifier les workflows critiques. Une version majeure se teste d’abord sur une copie.

Limites de ce retour d’expérience

Ces chiffres décrivent une seule instance, la nôtre, sur un serveur partagé avec d’autres services, et sur une fenêtre de 12 jours pour les exécutions (notre historique est purgé au-delà). Ils ne disent rien des performances de n8n Cloud, que nous n’exploitons pas en production, ni d’une instance à fort volume en mode file d’attente (queue mode) avec plusieurs workers. Le taux d’erreur dépend des API appelées par nos workflows, pas de n8n. Enfin, l’édition Community et les plans évoluent : vérifiez la page des tarifs avant de décider.

Vous hésitez entre les deux, ou vous voulez qu’on reprenne l’exploitation d’une instance existante ? Prenez 30 minutes avec nous : nous regardons vos workflows, vos contraintes de données et qui tiendra la surveillance. Nos prestations autour de n8n sont décrites sur la page agence d’automatisation.

Questions fréquentes

n8n auto-hébergé est-il gratuit ?

Oui pour le logiciel : l’édition Community s’installe sans licence et inclut presque toutes les fonctions. Vous payez le serveur, le temps d’installation et surtout le temps d’exploitation (sauvegardes, surveillance, mises à jour).

Quel serveur faut-il pour héberger n8n ?

Notre instance tourne sur 2 cœurs et 8 Go de mémoire pour 41 workflows actifs et environ 2 400 exécutions par jour, n8n n’utilisant lui-même que 194 Mo. La charge du processeur, partagée avec d’autres services, est notre vraie limite. Pour un n8n seul, un serveur plus petit suffit ; pour des workflows lourds en données ou en IA, prévoyez plus de mémoire.

n8n Cloud est-il adapté à la production ?

Oui. La documentation officielle indique que les deux options, Cloud et auto-hébergé, conviennent à la production. La différence porte sur qui exploite l’instance et où vivent les données.

Peut-on passer de n8n Cloud à l’auto-hébergement plus tard, ou l’inverse ?

Oui. Les workflows s’exportent en JSON et se réimportent. Les identifiants d’API doivent être ressaisis, et les URL de webhooks changent : il faut les mettre à jour chez les services qui les appellent.

Que se passe-t-il si l’instance tombe en panne ?

Sans surveillance, rien : les webhooks sont perdus et personne ne le sait. C’est ce qui nous est arrivé pendant 40 heures en juillet 2026. Avec une surveillance externe, une alerte part en moins de trois minutes et l’intervention commence.

Faut-il une base PostgreSQL plutôt que SQLite ?

SQLite nous suffit à 2 400 exécutions par jour sur une seule instance. Dès qu’il faut plusieurs workers (mode file d’attente) ou un volume nettement supérieur, PostgreSQL devient nécessaire, comme l’indique la documentation sur la montée en charge.