Un serveur capable de faire tourner n8n coûte moins de six euros par mois. C’est la partie facile, et c’est la seule que les pages de comparaison prennent la peine de chiffrer. Le reste de cette page porte sur ce qui n’apparaît sur aucune facture : les six pannes que nous avons eues en installant et en pilotant n8n sur une vraie machine, avec leur cause et la date à laquelle nous les avons vues.
Cette page ne recopie pas la commande docker run de la documentation officielle : elle est tenue à
jour par l’éditeur et change plus vite qu’un article. Ce qui ne change pas, ce sont les décisions que
vous prenez autour d’elle.
Ce que nous faisons tourner, exactement
Voici la machine dont viennent tous les faits de cette page.
- n8n
- 2.26.7, installé en paquet Node, pas en conteneur Docker
- Node
- 22.23.0, imposé explicitement ; le Node global de cette machine est en 26.0.0
- Machine
- Un Mac mini allumé en permanence, à l'île Maurice, service géré par launchd
- Base
- SQLite, pas de PostgreSQL
- Écoute
- 127.0.0.1:5678 uniquement ; rien n'est exposé à l'internet, c'est un choix
Les tests du pack Chambres d’hôtes ont tourné là, les 22 et 23 septembre 2026, et ceux des modèles gratuits le 23 septembre 2026. Les deux journaux de test sont dans le dépôt du projet.
Une conséquence à poser tout de suite : nous n’avons pas installé n8n dans Docker sur cette machine. Ce que dit cette page sur Docker est donc du raisonnement, marqué comme tel ; ce qu’elle dit des six pannes est mesuré.
Les six pannes, et leur cause
1. Le mauvais Node, et un plantage qui ne vous dit pas pourquoi
Le lanceur de n8n commence par la ligne #!/usr/bin/env node. Cette ligne ne demande pas une
version, elle demande le premier node du chemin. Sur notre machine, c’est Node 26, et n8n s’arrête
sur un module natif, isolated-vm, compilé pour une autre version.
Le correctif n’est pas d’espérer que le bon Node soit devant. Le service appelle l’exécutable Node 22
par son chemin complet, et met le dossier de Node 22 en tête de PATH pour que tout processus enfant
soit lui aussi en 22. Le premier réglage lance n8n, le second protège ce que n8n lance.
Si vous passez par Docker, ce problème n’existe pas : l’image embarque sa propre version de Node. C’est le meilleur argument en faveur du conteneur, et il est rarement celui qu’on avance.
2. Le dossier de données, et la deuxième base restée vide
n8n range sa base, sa clé de chiffrement des credentials et ses journaux dans un dossier de travail.
Nous avons fixé ce dossier avec la variable N8N_USER_FOLDER.
Le jour où une commande a été lancée sans cette variable, rien n’a échoué. n8n a simplement créé une autre base, ailleurs, et a travaillé dedans. Les deux fichiers existent toujours sur la machine, et l’écart se lit en une ligne : ce jour-là, la vraie base pesait 13 135 872 octets, l’autre 0 octet. Aucun message d’erreur n’a été affiché, aucun workflow n’a été perdu, et pendant quelques minutes nous avons cru que l’import n’avait rien fait.
La règle qui en sort tient en une phrase : la variable qui désigne le dossier de données doit être posée au même endroit pour le service et pour votre terminal. Nos deux bancs de test l’exportent en tête de fichier, avant la première commande.
En Docker, la même erreur prend une autre forme et coûte plus cher : sans volume monté sur le dossier de données, tout vit à l’intérieur du conteneur et disparaît à la première mise à jour de l’image. La panne est la même, la perte est définitive.
3. Un identifiant dans le fichier, si vous pilotez en ligne de commande
Nos cinq workflows portent un champ id écrit explicitement par le générateur qui les fabrique, et
le banc de test le réécrit avant chaque import. La raison est simple : c’est par cet identifiant que
toutes les commandes suivantes retrouvent le workflow, n8n update:workflow --id=... pour l’activer
et n8n execute --id=... pour le lancer.
Ce que nous pouvons affirmer, parce que c’est dans nos fichiers : un workflow piloté en ligne de commande a besoin d’un identifiant stable écrit dans son JSON. Nous n’avons pas mesuré ce que fait un import sur un fichier qui n’en porte aucun, donc nous ne l’écrivons pas. Si vous importez par le menu Import from File, la question ne se pose pas.
4. Le port 5679, tenu par l'instance qui tourne déjà
La commande n8n execute démarre un mini n8n le temps d’une exécution. Ce mini n8n veut ouvrir le
courtier de tâches sur le port 5679, et ce port est déjà pris par le service qui tourne en
permanence. Les deux bancs de test déplacent donc le courtier avant d’appeler la commande, avec
N8N_RUNNERS_BROKER_PORT=5698.
La même collision nous est arrivée dans l’autre sens : le simulateur local qui remplaçait le modèle Claude pendant la première passe écoutait sur 5679, et toutes les classifications sont revenues en 404. Le port était en cause, pas le pack.
5. /healthz répond avant que les webhooks existent
Celle-ci nous a coûté le plus de temps, et c’est la plus facile à reproduire chez vous.
Un workflow déclenché par webhook n’enregistre son adresse de production qu’au démarrage du service. Tant que vous n’avez pas redémarré, l’activation dans l’interface ne suffit pas. Nos deux bancs de test redémarrent donc le service après l’import.
Le piège est dans l’attente qui suit. La route de santé /healthz répond plusieurs secondes avant
que n8n ait fini d’enregistrer les webhooks de production. Une requête envoyée dans cette fenêtre
reçoit un 404 et ne déclenche aucune exécution. Lors de la passe du 22 septembre 2026, sept cas de
test sur seize n’ont rien exécuté pour cette seule raison, et le rapport les affichait comme des
échecs du pack. Le défaut était dans le banc, pas dans les workflows.
Le banc attend maintenant le webhook lui-même, en lui envoyant une sonde jusqu’à obtenir un 200, soixante fois au plus, à une seconde d’intervalle. Pour les modèles gratuits, la correction a pris une forme voisine : le script réessaie tant que n8n répond « is not registered ».
Si vous surveillez votre n8n avec un outil de supervision, ceci vous concerne directement : une sonde
sur /healthz vous dira que le service est vivant alors que vos webhooks refusent encore le trafic.
6. Les exécuteurs de tâches, depuis n8n 2.0
Le guide de dépannage du pack porte une ligne là-dessus : sur n8n auto-hébergé, quand un noeud Code
affiche « Task runner » ou « Code node not available », c’est que les exécuteurs de tâches ne sont
pas activés. La variable N8N_RUNNERS_ENABLED=true les rallume. Elle n’est pas obligatoire : les
exécuteurs sont actifs par défaut, et notre propre service ne pose pas cette variable.
Précision honnête, parce qu’elle contredit à moitié la ligne précédente : notre propre service ne pose pas cette variable, et nos noeuds Code fonctionnent. Quatorze corps de code des modèles gratuits ont été exécutés sur cette installation le 23 septembre 2026. La valeur par défaut de n8n 2.26.7 suffit donc ici. Retenez la variable comme le premier réglage à vérifier si le noeud Code refuse de partir, pas comme une case à cocher systématique.
Docker : les trois décisions qui comptent
Nous n’avons pas mesuré l’installation Docker, donc voici seulement les trois points sur lesquels nos six pannes disent quelque chose d’utile.
- Où vivent les données. Un volume monté sur le dossier de travail de n8n, toujours. Sans lui, la base et la clé de chiffrement des credentials sont à l’intérieur du conteneur et partent avec lui. C’est la panne 2, en pire.
- Qui termine le TLS. n8n en conteneur parle en clair sur son port, et le certificat est posé devant, par un serveur qui fait passe-plat. Notre installation évite la question en n’écoutant que sur la boucle locale, ce qui est une réponse valable quand personne n’a besoin d’y accéder de l’extérieur.
- Ce que vous redémarrez, et quand. La panne 5 ne vient pas du mode d’installation. Un webhook de production s’enregistre au démarrage, conteneur ou pas.
La commande exacte, l’image et les variables sont sur la documentation d’hébergement de n8n, en anglais, ouverte le 23 septembre 2026. Ouvrez-la plutôt que de copier la commande d’un article : c’est la seule qui soit à jour le jour où vous lisez.
Ce que coûte le serveur
Deux prix relevés le 22 septembre 2026 sur les pages des hébergeurs, sans conversion de devise.
Relevé du 22 septembre 2026, par mois
Hetzner revient souvent dans ces listes. Son tarif n’a pas pu être relevé le 22 septembre 2026 : la page publie ses prix par script et le HTML servi ne contient aucun chiffre. Il est donc marqué « à vérifier » dans nos données au lieu d’être rempli de mémoire. La page.
L’écart mensuel entre le serveur et l’abonnement est donc d’environ seize euros. Un seul des six incidents ci-dessus mange plusieurs fois cet écart la première fois qu’il tombe.
Quand l’auto-hébergement est le bon choix
Il l’est quand votre volume est gros, parce que l’abonnement grimpe et pas le serveur. Il l’est aussi quand vos données ne doivent pas sortir de chez vous, ce qui est notre cas et n’a rien à voir avec le prix.
Il ne l’est pas quand vous installez votre première automatisation sans personne pour tenir un serveur. Le calcul complet, avec le point d’équilibre en heures de maintenance par mois, est dans le guide n8n Cloud ou auto-hébergé, le coût réel en 2026, et vous pouvez le refaire avec vos propres chiffres dans le calculateur de coût n8n. Si la question est encore de choisir l’outil plutôt que la machine, le comparatif n8n, Make et Zapier traite les trois façons de facturer, qui ne se comparent pas directement.
Une dernière note sur la version. Tout ce qui est écrit ici a été vu sur n8n 2.26.7 les 22 et 23 septembre 2026, et nos workflows annoncent 2.26.0 comme version minimale. Les numéros de port et les noms de variables vieillissent bien, les messages d’erreur beaucoup moins.
Une fois par semaine, nous envoyons un workflow, un chiffre mesuré et un lien : Le Flux.