Combien coûte vraiment un n8n self-hosted ? Le calcul complet (TCO)

« n8n est gratuit en self-hosted » : la phrase est vraie, et pourtant elle ne répond pas à la question que se pose toute équipe qui compare n8n Cloud et une instance auto-hébergée. Le coût d'un logiciel ne se limite jamais à sa licence — il inclut le serveur, le domaine, les sauvegardes, et surtout les heures passées à maintenir tout cela en vie. Cet article pose le calcul complet du TCO (Total Cost of Ownership) d'un n8n self-hosted, sans chiffres inventés : des ordres de grandeur explicites pour ce qui se chiffre, et une méthode pour estimer le reste. Si vous hésitez encore entre les deux modèles sur des critères non financiers, notre comparatif self-hosted vs Cloud complète cette analyse.

La licence : fair-code, gratuit et sans limite d'exécutions

n8n est distribué sous une licence fair-code (Sustainable Use License). Concrètement, pour un usage interne — automatiser vos propres processus, ceux de votre entreprise, même à des fins commerciales — l'installation self-hosted ne coûte rien en licence, et surtout n'impose aucune limite au nombre d'exécutions de workflows. C'est la différence structurelle avec la plupart des plateformes d'automatisation, dont la facturation croît avec le volume d'opérations.

Deux nuances honnêtes :

• La licence encadre la revente de n8n comme service à des tiers (vous ne pouvez pas héberger n8n et le facturer comme produit sans accord commercial).
• Certaines fonctionnalités destinées aux grandes organisations (SSO avancé, contrôle d'accès granulaire, environnements) relèvent d'offres payantes, y compris en self-hosted.

Pour les tarifs de n8n Cloud, qui évoluent régulièrement, la seule source fiable est la page officielle n8n.io/pricing — tout chiffre recopié dans un article de blog serait périmé en quelques mois. Retenez simplement le principe : le Cloud facture un abonnement lié notamment au volume d'exécutions, quand le self-hosted déplace le coût vers l'infrastructure et le temps humain.

Les postes de coût visibles du self-hosted

Le serveur

Une instance n8n pour une petite équipe tourne confortablement sur un VPS de 2 vCPU et 4 Go de RAM. En ordre de grandeur — et uniquement en ordre de grandeur, les prix variant selon l'hébergeur, la région et les promotions — comptez de quelques euros à une vingtaine d'euros par mois. Le dimensionnement dépend surtout de vos workflows : ceux qui manipulent de gros fichiers binaires ou beaucoup d'appels IA parallèles consomment plus de mémoire que des synchronisations de données classiques.

Le nom de domaine et le HTTPS

Un nom de domaine coûte typiquement une dizaine d'euros par an. Le certificat TLS, lui, est gratuit via Let's Encrypt dès que vous placez un reverse proxy devant n8n — notre guide HTTPS avec Traefik ou Caddy détaille la mise en place. Ce poste est négligeable financièrement mais obligatoire : les webhooks et les intégrations OAuth exigent une URL HTTPS propre.

Les sauvegardes et le stockage

Une instance sans sauvegarde testée est une instance en sursis. Il faut prévoir :

• un stockage externalisé pour les dumps PostgreSQL et la clé de chiffrement des credentials (un bucket objet ou un second serveur, quelques euros par mois en ordre de grandeur pour des volumes de ce type) ;
• le temps de mettre en place et de tester la restauration, détaillé dans notre guide sauvegarde et restauration PostgreSQL.

Redis, si vous passez en mode queue

Tant que l'instance reste en exécution simple, aucun composant supplémentaire n'est requis. Si le volume grandit au point de passer en mode queue avec Redis (une instance principale, des workers, Redis comme file d'attente), ajoutez le coût d'un Redis — modeste s'il partage le serveur, un peu plus s'il est managé — et surtout la complexité opérationnelle d'un composant de plus à superviser.

Le coût caché : le temps humain

C'est le poste que les comparatifs oublient, et c'est pourtant lui qui domine le TCO dans la plupart des cas. Une instance self-hosted demande, de façon récurrente :

• Les mises à jour : n8n publie fréquemment ; laisser une instance vieillir plusieurs mois expose à des failles corrigées et rend les montées de version plus risquées.
• La supervision : disponibilité de l'instance (un Schedule Trigger manqué pendant une panne n'est pas rattrapé), espace disque, croissance de la base d'exécutions.
• La sécurité : durcissement du serveur, gestion des accès, protection des credentials API — la clé de chiffrement n8n est un actif critique à sauvegarder à part.
• Les restaurations : le jour où le disque lâche, la différence entre deux heures et deux jours d'interruption tient à des procédures testées à l'avance.

Ordre de grandeur raisonnable pour une instance de petite équipe bien outillée : quelques heures par mois en régime de croisière, davantage les premiers mois et lors des incidents. Valorisez ces heures au coût complet d'un profil technique de votre organisation et comparez : c'est souvent là que le Cloud redevient compétitif, pas sur le prix du VPS.

Cet arbitrage n'a rien de nouveau. L'article de référence sur l'économie du cloud, publié en 2010 dans Communications of the ACM (Armbrust et al., « A View of Cloud Computing » — Google Scholar), formalisait déjà les termes du choix : le cloud convertit des dépenses d'investissement en dépenses d'usage, transfère le risque opérationnel au fournisseur et offre une élasticité qu'une infrastructure en propre ne peut égaler — mais devient moins avantageux quand la charge est stable, élevée et prévisible. Appliqué à n8n : un volume d'exécutions massif et régulier plaide pour le self-hosted ; une charge faible ou incertaine, pour le Cloud.

Quand chaque modèle gagne

Le self-hosted gagne quand :

• le volume d'exécutions est élevé — l'absence de plafond change l'équation dès que les workflows tournent en continu, par exemple pour tracer chaque appel IA comme dans notre guide sur le suivi des coûts d'appels IA ;
• les données sont sensibles : emails clients, documents contractuels, données personnelles soumises au RGPD, avec une exigence de maîtrise complète de l'hébergement et de la localisation ;
• une compétence infra existe déjà dans l'équipe, et les quelques heures mensuelles de maintenance s'insèrent dans un rôle existant plutôt que d'en créer un.

Le Cloud gagne quand :

• personne dans l'équipe ne peut (ou ne veut) administrer un serveur — un TCO qui repose sur des heures que personne n'a n'est pas un TCO, c'est une panne différée ;
• le volume est faible ou irrégulier : quelques centaines d'exécutions par mois ne justifient pas de porter une infrastructure ;
• le time-to-value prime : un compte Cloud est opérationnel en minutes, quand un self-hosted propre (HTTPS, sauvegardes, supervision) demande des jours.

La grille de décision

Répondez à ces quatre questions dans l'ordre :

1. Vos données peuvent-elles quitter votre infrastructure ? Si non (contraintes RGPD fortes, secteur régulé), le self-hosted s'impose — le reste de la grille ne sert qu'à dimensionner l'effort.
2. Avez-vous une compétence serveur disponible en interne ? Si non, restez sur le Cloud, au moins pour démarrer : une migration vers le self-hosted reste possible plus tard, les workflows s'exportent.
3. Votre volume d'exécutions dépasse-t-il durablement les paliers de l'offre Cloud ? Comparez votre projection au tarif officiel : si l'abonnement nécessaire dépasse le coût serveur plus vos heures de maintenance valorisées, le self-hosted devient rationnel.
4. L'automatisation est-elle critique pour le métier ? Si oui et que vous partez en self-hosted, budgétez la supervision et les sauvegardes dès le premier jour, pas après le premier incident.

Le résultat honnête : pour beaucoup de petites équipes, le Cloud est le bon point de départ, et le self-hosted devient rentable avec le volume, la sensibilité des données ou une infra déjà en place — rarement pour économiser trois euros de VPS.

Ce que ça change pour vos workflows

La bonne nouvelle : ce choix d'hébergement n'engage pas vos workflows. Un workflow n8n s'exporte en JSON et tourne indifféremment sur Cloud ou self-hosted — c'est le cas de tous les workflows FlowKit, comme le tri d'emails du Pack Inbox IA (79 €) ou le pipeline RAG complet du Pack Assistant RAG (119 €), livrés en JSON importable sur l'une ou l'autre infrastructure. Commencez là où votre équipe est efficace aujourd'hui ; le TCO se recalcule chaque année, et la migration reste toujours ouverte.