n8n price : le vrai coût à 1 000 exécutions/mois (Cloud vs self-hosted)

À 1 000 exécutions mensuelles, le n8n price affiché sur la page de tarifs ne suffit pas pour estimer votre budget. En pratique, le choix Cloud vs self-hosted se joue surtout sur ce qui n’est pas chiffré dans les tableaux : administration, sécurité, maintenance. Notre avis chez Cyberyweb : à 1 000 exécutions/mois, le Cloud revient souvent moins cher que le « gratuit », sauf si vous avez déjà une exploitation serveur propre et du temps prévu pour ça.

Ce que « 1 000 exécutions par mois » signifie vraiment chez n8n

Avant de comparer le Cloud et le self-hosted, il faut s’entendre sur l’unité facturée.

n8n compte une exécution par run complet du workflow, pas par étape. Un workflow de 2 étapes et un workflow de 200 étapes comptent chacun pour une seule exécution, d’après la comparaison officielle n8n vs Make. Si vos automatisations sont longues (beaucoup de nœuds, enrichissements, routes, boucles), la facture ne grimpe pas parce que vous avez ajouté des étapes.

En revanche, ça devient sensible si vos workflows se déclenchent très souvent : un trigger toutes les minutes, ou un webhook appelé à chaque clic client. Ce n’est pas une question de qualité technique. C’est un compteur qui peut monter vite.

À 1 000 exécutions mensuelles, on est souvent dans ces cas :

• traitement de leads (formulaires, chat, Meta Lead Ads)
• tri et routage d’emails entrants
• synchronisations simples (CRM, tableur, emailing)
• alertes et surveillance (toutes les 5, 10, 15 minutes)

Que dit la page de prix pour 1 000 exécutions en Cloud ?

Le forfait Cloud Starter est affiché à 20 € par mois avec facturation annuelle, et inclut 2 500 exécutions mensuelles, selon la page n8n.io/pricing. À 1 000 exécutions/mois, vous utilisez environ 40 % du quota et il vous reste 1 500 exécutions de marge.

Le forfait Cloud Pro est affiché à 50 € par mois avec facturation annuelle pour 10 000 exécutions mensuelles. À 1 000 exécutions, vous n’êtes pas la cible. Il devient logique quand vous dépassez régulièrement 2 500 exécutions/mois.

Deux points que nous rappelons souvent à nos clients :

• n8n facture l’exécution complète du workflow, pas chaque étape. Ça garde les coûts lisibles quand on a des workflows chargés.
• L’essai Cloud a ses propres limites : 1 000 exécutions, 5 exécutions simultanées, 180 secondes max par exécution et un seul projet d’équipe, selon n8n.io/pricing. Ce sont des limites de test. Ne les prenez pas pour votre référence en production.

Ce que la page de prix met moins en avant, c’est ce que vous n’avez pas à gérer : hébergement, mises à jour, sauvegardes, supervision. C’est souvent là que le « gratuit » du self-hosted se complique.

Le self-hosted « gratuit » : ce que vous payez quand même

L’édition Community auto-hébergée est disponible gratuitement, sans limite de durée. C’est indiqué dans le guide « Choose how to use n8n » sur docs.n8n.io.

Mais la documentation est claire sur la contrepartie : en auto-hébergement, c’est à vous de fournir et d’administrer l’infrastructure. L’hébergement, les mises à jour, les sauvegardes, la supervision et la maintenance ne sont pas pris en charge.

Quand quelqu’un vous dit « n8n self-hosted est gratuit », traduisez : « la licence peut être à 0 €, mais l’exploitation ne l’est pas ».

Quelles tâches le self-hosted ajoute-t-il concrètement ?

Pour une TPE/PME à 1 000 exécutions/mois, le sujet n’est pas la performance brute. C’est la routine d’exploitation. Et oui, ça prend du temps, même quand tout va bien.

Sécurité opérationnelle. La doc n8n recommande de ne pas exposer le composant sandbox-runner à Internet, de limiter les ports ouverts au pare-feu, et de renouveler périodiquement les clés sensibles. C’est très faisable. Mais il faut le faire, puis vérifier que ça tient après chaque changement (upgrade, nouveau reverse proxy, nouvelle intégration).

Communications sortantes par défaut. Une instance auto-hébergée communique par défaut avec les serveurs n8n (notifications de mise à jour, modèles de workflows, diagnostics). Ces communications peuvent être désactivées via des variables d’environnement. Si vous avez des contraintes internes (sécurité, conformité, réseau), mieux vaut trancher ce point avant la mise en production.

Mises à jour et compatibilité. Une mise à jour peut corriger une faille. Elle peut aussi casser un workflow ou une intégration. En Cloud, c’est géré. En self-hosted, vous choisissez le moment, vous testez, et vous prévoyez un rollback si besoin. Sinon, vous risquez de découvrir le problème un lundi matin.

Sauvegardes et restauration. Beaucoup de dirigeants pensent « on fera une sauvegarde ». La question concrète : « qui la vérifie et qui sait restaurer vite ? » Chez Cyberyweb, nos sauvegardes de workflows n8n sont exportées chaque nuit automatiquement. Un workflow modifié à la main sans sauvegarde nous a déjà coûté une demi-journée. Sans test de restauration, une sauvegarde n’est qu’un fichier qui dort.

Notre position nette : nous déconseillons le self-hosted si personne chez vous n’a une routine serveur et une responsabilité claire sur la maintenance. La licence peut être « gratuite ». L’instance, elle, ne doit pas être gérée « entre deux urgences ».

Quand le Cloud revient moins cher que « gratuit »

n8n indique que le Cloud inclut l’hébergement et la maintenance gérés par n8n. Pour une TPE à 1 000 exécutions/mois, un abonnement à 20 € peut coûter moins cher qu’un serveur « gratuit » dès que maintenance, sauvegardes et sécurisation prennent plus de quelques heures par an.

Le seul point à vérifier au moment de l’achat : le tarif mensuel sans engagement annuel, puisque la page affiche explicitement 20 € par mois avec facturation annuelle, selon n8n.io/pricing.

Le calcul réaliste pour un dirigeant pressé

Posez-vous ces trois questions :

1) Avez-vous déjà un serveur de production géré correctement (monitoring, sauvegardes, mises à jour) ? Si oui, vous amortissez ce socle et le self-hosted peut se défendre.

2) Avez-vous besoin d’un environnement cloisonné (réseau, données, conformité) qui rend le Cloud compliqué ? Si oui, la décision se joue moins sur le prix que sur vos contraintes.

3) Votre automatisation touche-t-elle directement vos leads, commandes ou relances ? Si oui, la vraie facture, c’est une panne silencieuse. Le Cloud peut faire office d’assurance à faible coût.

Limite honnête : le Cloud ne corrige pas un workflow mal conçu. Si vos déclencheurs sont trop fréquents, si vous lancez des traitements inutiles, ou si vous avez des boucles mal maîtrisées, vous pouvez vider votre quota même en Cloud. Hébergement ou pas, la conception compte.

Comment nous pilotons le coût chez Cyberyweb

Le cas le plus parlant, c’est notre usage interne. Il met vite en évidence les deux choses qui font gonfler les coûts réels : la volumétrie (exécutions) et l’exploitation (disponibilité, pannes, suivi).

Notre problème : les leads issus du site et de notre quiz diagnostic finissaient dans du traitement manuel. Résultat, des délais variables, et parfois une demande traitée trop tard.

Ce que nous avons mis en place : une chaîne n8n qui capture les leads vers Google Sheets, notifie l’équipe, envoie une auto-réponse IA, puis synchronise dans notre CRM Odoo. L’auto-réponse part en environ 25 secondes, et nous n’avons perdu aucun lead depuis la mise en place, vérifiable dans nos journaux et dans Odoo. Nous avons aussi appris à nos dépens qu’il faut décaler les tâches planifiées à l’heure pile : sur notre VPS, toutes les tâches qui se lançaient simultanément saturaient le serveur ; quelques minutes de décalage entre chaque ont suffi à régler le problème.

Pourquoi ce cas aide à parler de coût n8n :

• En self-hosted, l’instance doit être disponible en continu. Sinon vous perdez exactement ce que vous cherchiez : la réactivité, et la certitude de ne rien rater.
• Les workflows de lead peuvent grimper vite en exécutions (un webhook par formulaire, parfois pire si on découpe mal). Le fait que n8n compte par exécution et non par étape rend la facture Cloud lisible. Mais ça suppose aussi de regrouper proprement les actions dans un workflow.

L’avis que nous appliquons en interne : quand une automatisation touche l’entrée de chiffre d’affaires, on préfère payer une plateforme gérée plutôt que payer en stress et en interruptions. Ce n’est pas une règle absolue. C’est un filtre simple, et il évite pas mal de discussions inutiles.

Cloud vs self-hosted : quels critères pour décider à 1 000 exécutions/mois ?

Critère	Cloud	Self-hosted
Licence	20 €/mois (Starter, facturation annuelle)	0 €
Hébergement et maintenance	Inclus	À votre charge
Sauvegardes et mises à jour	Gérés par n8n	À votre charge
Quota à 1 000 exécutions/mois	Starter : 2 500 incluses (marge confortable)	Aucune limite d’exécutions
Contrainte réseau ou conformité	Données chez n8n	Données chez vous
Compétence requise	Aucune côté serveur	Routine DevOps nécessaire

Prenez le Cloud si…

• Vous êtes à 1 000 exécutions/mois et vous voulez une facture simple. Le forfait Starter inclut 2 500 exécutions, ce qui laisse de la marge.
• Vous ne voulez pas gérer sauvegardes, mises à jour et supervision.
• Vous n’avez pas de contrainte réseau particulière.

À 1 000 exécutions mensuelles, c’est le cas le plus courant pour des TPE/PME qui veulent que ça tourne sans créer un sujet interne supplémentaire.

Prenez le self-hosted si…

• Vous avez une raison hors prix : contrainte de sécurité, de réseau, ou besoin de contrôler les communications sortantes. Rappel : l’instance auto-hébergée communique par défaut avec les serveurs n8n pour certaines fonctionnalités, mais cela peut se désactiver.
• Vous avez déjà un socle DevOps (ou un prestataire) qui gère une production : pare-feu, ports, secrets, renouvellement de clés.
• Vous acceptez que « gratuit » veut dire « vous êtes l’hébergeur ».

Notre position : si votre seule motivation est d’éviter 20 € par mois, nous déconseillons le self-hosted. Pas par principe. Juste parce que, dans la vraie vie, ce calcul finit souvent en temps perdu et en incidents.

Ce que les pages de prix disent peu : les pièges qui font déraper le budget

Confondre quota d’essai et quota réel

L’essai Cloud a des limites spécifiques : 1 000 exécutions, 5 simultanées, 180 secondes, 1 projet, selon n8n.io/pricing. Nous voyons des dirigeants conclure « n8n est limité » alors qu’ils parlent encore du mode test.

Découper un processus en trop de workflows

n8n ne facture pas par étape, mais par exécution du workflow. Si vous transformez un seul processus en 10 workflows chaînés au lieu d’un workflow orchestrateur, vous multipliez les exécutions mécaniquement.

Sous-estimer la sécurité en self-hosted

La doc liste des recommandations explicites : ports, sandbox-runner, renouvellement des clés. Le point dur n’est pas de les lire. C’est de les appliquer dans la durée.

Croire que le self-hosted est « off-grid »

Même en auto-hébergé, des communications par défaut existent (updates, templates, diagnostics), désactivables. Si vous découvrez ça après la mise en production, vous perdez du temps en reconfiguration, et parfois en validation sécurité.

Que veut dire le seuil de 1 000 exécutions/mois pour vous ?

Si c’est 1 000 exécutions/mois, le Cloud Starter couvre le besoin avec marge, selon n8n.io/pricing. Si c’est 1 000 € par mois de budget, alors vous n’achetez pas n8n. Vous achetez surtout de la fiabilité, de la gouvernance et des automatisations maintenues.

Dans ce deuxième cas, ce qui coûte vraiment, c’est :

• la conception des workflows (éviter les exécutions inutiles)
• la sécurisation (secrets, ports, composants)
• la surveillance (pannes silencieuses, alertes)
• la maintenance continue

n8n est un bon moteur. Pour que ça tourne tous les jours, il faut penser exploitation, pas seulement outil.

Et concrètement, chez vous ?

Commencez par lister 5 processus et estimez leur fréquence (combien de déclenchements par jour). Repérez ceux qui touchent directement vos leads, commandes ou relances. À 1 000 exécutions/mois, nous partons presque toujours sur le Cloud pour valider la valeur rapidement. Nous ne reconsidérons le self-hosted que si une contrainte (sécurité, réseau, conformité) l’impose.

Ensuite, nous concevons les workflows pour éviter les exécutions inutiles et les découpages qui font grimper le compteur. Si vous voulez une recommandation claire Cloud vs self-hosted sur votre cas, demandez notre diagnostic gratuit.