n8n en mode file d’attente : passer à plusieurs exécutants

Il arrive un moment où votre instance n8n ne suit plus. Les exécutions s’empilent, une
tâche lancée à 9 h démarre à 9 h 07, et l’interface devient poussive au moment précis où le
serveur travaille le plus. Vous avez déjà augmenté la mémoire, et le problème revient.

C’est le signal que n8n attend pour changer de fonctionnement. Par défaut, un seul processus
fait tout : il sert l’interface, reçoit les webhooks et exécute les automatisations, les
unes après les autres. Le mode file d’attente sépare ces rôles et confie l’exécution à
plusieurs processus qui travaillent en parallèle.

Ce guide décrit l’opération complète : comment savoir si vous en avez vraiment besoin,
les trois pièces à ajouter, le fichier de configuration commenté, combien d’exécutants prévoir,
comment basculer sans couper la production, et quoi surveiller ensuite. Nous disons aussi, à la
fin, dans quels cas il faut revenir en arrière — c’est arrivé, et ce n’est pas un échec.

Le symptôme qui justifie le changement

Nous l’écrivions dans quel VPS choisir pour n8n : le
mode file d’attente est une réponse à un problème constaté, jamais une précaution. La très
grande majorité des instances n’en a pas besoin, et beaucoup de gens l’installent parce que ça
fait sérieux, puis passent six mois à administrer trois pièces au lieu d’une pour un gain nul.

Le seul symptôme qui compte est celui-ci : vos exécutions attendent.
Pas « elles sont lentes » — une exécution lente reste lente avec dix exécutants, parce
que sa lenteur vient du service qu’elle interroge, pas de n8n. Elles attendent :
entre le moment où le déclencheur part et le moment où le premier nœud s’exécute, il s’écoule
des secondes, puis des minutes.

Vous le vérifiez en une minute. Ouvrez la liste des exécutions et comparez, sur une même
exécution, l’heure de déclenchement et l’heure de début réelle. Si l’écart est constant et
proche de zéro, votre problème n’est pas là. S’il grandit aux heures de pointe et se résorbe la
nuit, vous avez bien une file qui se forme.

Trois autres situations justifient la bascule, indépendamment du volume.

La première : une automatisation longue bloque toutes les autres. Un
traitement de trois minutes qui tourne une fois par heure suffit à retarder tout ce qui se
déclenche pendant ce temps. Avec plusieurs exécutants, les autres passent par un chemin libre.

La deuxième : l’interface devient inutilisable pendant les traitements.
C’est le signe que le processus qui vous sert la page est le même que celui qui calcule. Séparer
les rôles règle le problème même sans gain de débit.

La troisième : vous ne pouvez pas vous permettre de perdre une exécution en
cours. En fonctionnement normal, un redémarrage interrompt ce qui tournait. En mode
file d’attente, le travail reste dans la file et un exécutant le reprend. C’est un argument de
fiabilité, pas de performance, et c’est souvent le vrai motif.

En revanche, si vous cherchez à faire tourner plus d’automatisations différentes, ou
à en accélérer une seule, ce n’est pas le bon levier. Le mode file d’attente augmente le nombre
de choses que vous pouvez traiter en même temps. Il n’accélère rien pris isolément.

Ce que fait vraiment le mode file d’attente

En fonctionnement par défaut, votre instance est un seul processus qui porte trois casquettes.
Il affiche l’éditeur, il écoute les adresses de déclenchement, et il exécute. Quand il exécute,
il fait moins bien le reste. Quand il redémarre, tout s’arrête en même temps.

Le mode file d’attente ne change pas vos automatisations — elles restent identiques, vous
n’avez rien à réécrire. Il change qui les exécute. Le processus principal continue d’afficher
l’interface et de recevoir les déclenchements, mais au lieu d’exécuter, il dépose une
demande dans une file d’attente. Des processus séparés, les exécutants, piochent dans
cette file et font le travail.

Trois conséquences en découlent, et ce sont elles qui font tout l’intérêt de l’opération.

Les exécutions deviennent parallèles : cinq exécutants traitent cinq
demandes en même temps. L’interface reste réactive, puisque le processus qui la
sert ne calcule plus. Et le travail devient durable : une demande déposée
dans la file y reste jusqu’à ce qu’un exécutant la prenne, même si tout redémarre entre-temps.

Le prix à payer est réel et il faut le connaître avant de commencer. Vous passez d’une pièce
à surveiller à trois. Vous devez obligatoirement quitter la base de données par défaut. Et le diagnostic se complique : quand une exécution échoue, il faut savoir dans quel processus regarder — la méthode est dans une exécution n8n qui échoue.

Les trois pièces à ajouter

L’architecture cible comporte trois éléments nouveaux à côté de l’instance que vous avez
déjà.

Le distributeur de file. C’est un service qui garde en mémoire la liste des
travaux à faire et les distribue. n8n utilise Redis pour cela. Sa fonction ici est étroite :
il ne stocke ni vos automatisations, ni vos données, ni vos identifiants. Il ne contient que des
tickets de travail, dont la durée de vie se compte en secondes. C’est une pièce légère, qui
consomme peu et ne demande presque aucun entretien.

Les exécutants. Ce sont des copies du même programme n8n, lancées dans un
mode qui ne fait qu’une chose : prendre un travail dans la file et l’exécuter. Ils n’ont
pas d’interface, ils n’écoutent aucune adresse publique. Vous en lancez autant que votre machine
peut en porter.

La base de données partagée. C’est le point que beaucoup découvrent trop
tard. Plusieurs processus doivent lire et écrire les mêmes données au même instant. La base par
défaut, qui est un simple fichier, ne sait pas faire cela correctement. PostgreSQL devient donc
obligatoire, pas recommandé.

Pourquoi PostgreSQL devient obligatoire

Ce n’est pas une préférence d’éditeur. La base par défaut de n8n est SQLite, c’est-à-dire un
fichier sur le disque. SQLite est excellent — rapide, sans administration, parfaitement adapté à
une instance qui tourne seule. Mais il autorise une seule écriture à la fois, et sérialise tout
le reste.

Tant qu’un seul processus écrit, personne ne le remarque. Dès que quatre exécutants écrivent
en même temps le début, la progression et la fin de leurs exécutions respectives, trois d’entre
eux attendent en permanence. Vous auriez déplacé le goulot d’étranglement au lieu de le
supprimer, et vous risquez des verrous qui font échouer des exécutions au hasard.

PostgreSQL gère nativement les écritures concurrentes. Si vous êtes encore sur SQLite, la
migration se fait avant la bascule en mode file d’attente, jamais en même temps
— une opération à la fois, c’est ce qui rend le diagnostic possible si quelque chose se passe
mal. Cette migration a son propre coût en mémoire, entre deux et quatre cents mégaoctets sur une
configuration modeste, à ajouter à votre calcul.

La clé de chiffrement : le piège qui casse tout

C’est l’erreur numéro un de cette bascule, et elle est particulièrement déroutante parce que
tout semble fonctionner. L’instance démarre, les exécutants démarrent, la file se remplit, les
exécutions partent — et toutes échouent sur une erreur d’identifiants.

La raison est simple. Vos identifiants de connexion aux services extérieurs sont chiffrés
dans la base. La clé qui permet de les déchiffrer est propre à chaque instance : si vous ne
la déclarez pas explicitement, n8n en génère une au premier démarrage et la garde dans son
dossier de données. Chaque exécutant lancé sans clé déclarée génère donc la sienne,
différente, et se retrouve incapable de lire des identifiants chiffrés par un autre.

La règle est donc absolue : la clé de chiffrement doit être déclarée
explicitement et identique sur le processus principal et sur tous les exécutants. Si
votre instance existante fonctionne déjà, c’est sa clé actuelle qu’il faut reprendre —
en générer une nouvelle rendrait illisibles tous les identifiants déjà enregistrés.

Si vous ne l’aviez jamais déclarée, elle se trouve dans le fichier de configuration du
dossier de données de votre instance. Notez-la ailleurs avant toute chose. Nous détaillons ce
point, et la façon de la sauvegarder, dans
sauvegarder, restaurer et migrer n8n.

Le fichier de configuration, commenté

Voici la configuration complète. Elle reprend le fichier décrit dans
le fichier compose expliqué ligne par ligne et lui ajoute les
trois pièces. Si les notions de service, de volume et de variable d’environnement ne vous sont
pas familières, lisez cet article d’abord : nous ne les réexpliquons pas ici.

# Les valeurs communes : écrites une fois, reprises par les trois services.
# C'est ce qui rend impossible l'oubli de la clé sur un exécutant.
x-commun: &commun
  image: docker.n8n.io/n8nio/n8n:1.62.1   # une version figée, jamais « latest »
  environment:
    - EXECUTIONS_MODE=queue                # le mode, sur les TROIS services
    - QUEUE_BULL_REDIS_HOST=file
    - DB_TYPE=postgresdb                   # obligatoire, pas recommandé
    - DB_POSTGRESDB_HOST=base
    - DB_POSTGRESDB_DATABASE=n8n
    - DB_POSTGRESDB_USER=n8n
    - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
    - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}   # IDENTIQUE partout
    - GENERIC_TIMEZONE=Europe/Paris
    - EXECUTIONS_DATA_PRUNE=true           # sinon la base grossit sans fin
    - EXECUTIONS_DATA_MAX_AGE=336          # 14 jours d'historique
  volumes:
    - n8n_data:/home/node/.n8n

services:
  base:
    image: postgres:16-alpine
    environment:
      - POSTGRES_DB=n8n
      - POSTGRES_USER=n8n
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
    volumes:
      - pg_data:/var/lib/postgresql/data
    restart: unless-stopped

  file:
    image: redis:7-alpine
    restart: unless-stopped
    # Aucun port publié : la file ne doit jamais être joignable de l'extérieur.

  principal:
    <<: *commun
    environment:
      - WEBHOOK_URL=https://n8n.exemple.fr/   # sur le service qui reçoit
    ports:
      - "127.0.0.1:5678:5678"
    depends_on: [base, file]
    restart: unless-stopped

  executant:
    <<: *commun
    command: worker                        # la seule différence avec le principal
    environment:
      - N8N_CONCURRENCY_PRODUCTION_LIMIT=5 # tâches menées en parallèle par exécutant
    depends_on: [base, file, principal]
    restart: unless-stopped
    deploy:
      replicas: 2                          # commencez à 2, pas plus

volumes:
  n8n_data:
  pg_data:

Le nombre d’exécutions simultanées est le produit des deux réglages : 2 exécutants × 5 tâches = 10 en parallèle.

Quatre points méritent un commentaire.

Le bloc de valeurs communes en haut du fichier évite de recopier douze
variables sur chaque service. C’est du confort, mais surtout une protection : la clé de
chiffrement et les identifiants de base y sont écrits une seule fois, ce qui rend impossible
l’oubli sur un exécutant.

Le mode est déclaré sur les trois services, pas seulement sur le principal.
C’est ce qui indique au processus principal de déposer au lieu d’exécuter, et aux exécutants
d’aller piocher.

La commande worker est ce qui distingue un exécutant du
processus principal. Le programme est exactement le même image ; seul le mode de démarrage
change.

Les dépendances de démarrage évitent qu’un exécutant se lance avant que la
base et la file soient prêtes. Sans elles, le premier démarrage échoue une fois sur deux, se
relance seul, et vous laisse avec des messages d’erreur inquiétants mais sans conséquence.

Combien d’exécutants prévoir, et combien de tâches chacun

Deux réglages se combinent, et on les confond souvent. Le nombre d’exécutants
est le nombre de processus que vous lancez. La concurrence est le nombre
d’exécutions qu’un seul exécutant accepte de mener en parallèle. Le nombre total d’exécutions
simultanées est le produit des deux.

La logique est celle-ci : la concurrence coûte peu quand vos automatisations
attendent (un appel à une API, une pause), et coûte cher quand elles
calculent (du traitement de fichier, un navigateur piloté). Le nombre d’exécutants,
lui, coûte toujours : chaque processus prend sa part de mémoire, qu’il travaille ou non.

Commencez petit. Deux exécutants avec une concurrence de cinq couvrent déjà largement le cas
qui vous a amené ici, et vous laissent de la marge pour observer. Monter d’un cran est
l’affaire d’une ligne dans le fichier et d’un redémarrage ; redescendre après avoir saturé
la machine est nettement moins agréable.

Le plafond n’est pas le processeur, contrairement à ce qu’on suppose. C’est la mémoire, et
accessoirement le nombre de connexions que votre base accepte. Chaque exécutant ouvre les
siennes : à partir d’une dizaine de processus, PostgreSQL demande à être réglé en
conséquence.

Qui répond aux webhooks, et pourquoi ça compte

Dans la configuration ci-dessus, le processus principal reçoit toujours les webhooks. Il les
dépose ensuite dans la file. Pour la plupart des installations, cela suffit parfaitement.

Un cas fait exception : les webhooks qui doivent répondre quelque chose
à l’appelant, et les volumes d’appels très élevés. Dans ces situations, le processus principal
redevient un goulot d’étranglement, puisqu’il traite chaque réception, même brève, en plus de
servir l’interface.

n8n permet alors de lancer un troisième type de processus, dédié uniquement à la réception
des webhooks. Vous en mettez plusieurs derrière votre reverse proxy, et l’interface n’est plus
sollicitée du tout par le trafic entrant.

N’ajoutez pas cette pièce d’emblée. Elle ne se justifie qu’à partir de plusieurs dizaines
d’appels par seconde, ou quand vos webhooks renvoient une réponse attendue par un système
extérieur. En dessous, elle ajoute de la complexité pour rien.

Ce qui ne doit pas tourner en double

Voici le point que presque personne n’anticipe, et qui produit les dégâts les plus concrets.
Tant qu’un seul processus exécute, deux exécutions d’une même automatisation ne peuvent pas se
chevaucher : la seconde attend que la première se termine. Ce comportement, vous en
dépendez peut-être sans le savoir.

Avec plusieurs exécutants, ce n’est plus vrai. Une automatisation programmée toutes les cinq
minutes et qui met parfois six minutes verra sa deuxième exécution démarrer pendant que la
première tourne encore. Les deux liront les mêmes lignes « à traiter », et les
traiteront deux fois.

Concrètement : deux factures émises pour la même commande, deux e-mails envoyés au même
client, deux lignes créées dans le même tableau. Le genre d’erreur qu’on ne détecte pas tout de
suite, et qui se voit surtout de l’extérieur.

Trois protections, à choisir selon le cas.

Marquer avant de traiter. C’est la plus robuste, et elle ne dépend d’aucun
réglage de n8n. La première action de l’automatisation marque les lignes qu’elle prend en
charge ; les exécutions suivantes ne voient plus que ce qui reste. C’est la méthode à
préférer dès qu’il y a de l’argent ou un client au bout.

Espacer le déclenchement. Si un traitement met couramment six minutes, le
programmer toutes les cinq n’a de toute façon aucun sens. Passez à quinze, et le problème
disparaît sans code.

Poser un verrou. Une valeur dans un tableau ou une base, posée au début et
retirée à la fin, que l’automatisation vérifie avant de commencer. C’est efficace, mais pensez
au cas où l’exécution échoue en plein milieu : un verrou jamais retiré bloque tout le reste.
Donnez-lui toujours une date d’expiration.

Faites l’inventaire avant la bascule, pas après. La question à poser pour chaque
automatisation programmée est simple : que se passe-t-il si elle tourne deux fois en
même temps ? Si la réponse est « rien de grave », passez à la suivante.

Basculer sans couper la production

La bascule elle-même dure quelques minutes, mais la méthode compte plus que la durée. Le
principe est le même que pour une migration de serveur : on ne remplace rien tant qu’on
n’a pas vérifié que le remplaçant fonctionne.

Sauvegardez d’abord. Le volume complet et la clé de chiffrement, déposés
ailleurs que sur le serveur. C’est la seule étape non négociable de toute la procédure :
elle vous permet de tout annuler en vingt minutes si l’opération tourne mal.

Migrez la base ensuite, et arrêtez-vous là. Passez sur PostgreSQL, laissez
tourner en fonctionnement normal pendant vingt-quatre heures, et vérifiez que rien n’a bougé.
Deux changements simultanés rendent tout diagnostic impossible : si quelque chose casse,
vous ne saurez pas lequel accuser.

Ajoutez la file et un seul exécutant. Un, pas quatre. À ce stade, vous ne
cherchez pas de la performance : vous vérifiez que le mécanisme fonctionne, que les
identifiants se déchiffrent et que les exécutions arrivent bien à destination.

Vérifiez avant d’augmenter. Déclenchez une automatisation à la main et
suivez-la dans la liste des exécutions. Elle doit apparaître, démarrer, et se terminer
normalement. Vérifiez surtout qu’une automatisation utilisant un identifiant enregistré
fonctionne : c’est le test qui valide la clé de chiffrement.

Montez ensuite, un cran à la fois, en regardant la mémoire après chaque
ajout. Et gardez l’ancienne configuration de côté pendant une semaine.

Vérifier que ça marche vraiment

Une instance en mode file d’attente qui semble fonctionner peut en réalité n’avoir aucun
exécutant actif : les demandes s’empilent dans la file, et rien ne les prend. Vue de
l’interface, la différence n’est pas évidente au début — les exécutions apparaissent, elles sont
simplement marquées en attente.

Trois vérifications suffisent à lever le doute.

D’abord, les journaux d’un exécutant au démarrage doivent indiquer qu’il
s’est connecté à la file et qu’il attend du travail. S’il boucle sur une erreur de connexion,
c’est presque toujours le nom du service de file qui est mal orthographié dans la
configuration.

Ensuite, une exécution de test déclenchée à la main doit passer de l’état en
attente à l’état terminé en quelques secondes. Si elle reste en attente, aucun exécutant ne
pioche.

Enfin, l’exécution doit indiquer quel processus l’a traitée. Lancez deux
automatisations lentes en même temps : elles doivent démarrer ensemble et non l’une après
l’autre. C’est la preuve directe que le parallélisme fonctionne, et c’est le seul test qui la
donne.

# 1. Les exécutants sont-ils vivants et connectés à la file ?
docker compose logs --tail=40 executant

# 2. Combien tournent réellement ?
docker compose ps executant

# 3. La file se vide-t-elle ? (0 = rien n'attend, c'est l'état normal)
docker compose exec file redis-cli LLEN bull:jobs:wait

# 4. Monter d'un cran, sans coupure
docker compose up -d --scale executant=3

La troisième commande est celle à surveiller dans la durée : une valeur qui monte sans jamais redescendre est le signal d’alerte.

Surveiller la file : les trois signaux

Une fois en place, le mode file d’attente demande une surveillance différente. Vous ne
regardez plus « est-ce que n8n tourne », mais « est-ce que la file se vide ».

La longueur de la file est le signal principal. Une file qui monte aux
heures de pointe et retombe ensuite est saine. Une file qui monte et ne redescend jamais signifie
que vos exécutants ne suivent pas — ou qu’ils sont morts sans que vous l’ayez remarqué.

Le temps d’attente est le signal utile. C’est l’écart entre le dépôt et le
début de traitement. C’est exactement la mesure qui vous a fait ouvrir cet article : elle
doit être revenue à quelques centaines de millisecondes, et y rester.

Le nombre d’exécutants vivants est le signal qu’on oublie. Un exécutant qui
s’arrête ne provoque aucune alerte : le travail est simplement réparti entre les autres, un
peu plus lentement. Vous pouvez perdre la moitié de votre capacité sans rien voir pendant des
semaines, jusqu’au jour où le dernier lâche.

C’est ce troisième point qui mérite une alerte automatique. La règle est la même que pour les
sauvegardes : ce qui échoue en silence finit toujours par échouer au pire moment.

Les erreurs les plus fréquentes

Presque tous les problèmes de cette bascule tiennent dans le tableau ci-dessous. Ils ont un
point commun : le symptôme visible ne désigne jamais la vraie cause.

Quand revenir en arrière

Revenir au fonctionnement normal n’est pas un échec, et c’est parfois la bonne décision. Nous
préférons le dire, parce que peu de guides le font.

Trois situations le justifient. La première : le gain n’est pas au
rendez-vous. Si le temps d’attente n’a pas bougé, c’est que votre problème n’était pas
une file — c’est une automatisation lente, une API distante bridée, ou un serveur sous-dimensionné.
Le mode file d’attente ne les corrige pas.

La deuxième : la machine sature. Trois exécutants et une base
PostgreSQL sur un serveur de quatre gigaoctets, et vous vous retrouvez avec des processus tués
par le système. Mieux vaut revenir à une pièce sur une machine confortable que trois sur une
machine à l’étroit.

La troisième : le volume a baissé. Une saison, un client parti, un
traitement supprimé. Rien n’oblige à conserver une architecture dimensionnée pour un pic qui ne
revient pas.

Le retour en arrière est simple, à une condition : attendez que la file soit vide.
Arrêtez le processus principal pour qu’il cesse de déposer, laissez les exécutants terminer,
puis repassez le mode en fonctionnement normal. Vous pouvez rester sur PostgreSQL — il n’y a
aucune raison de revenir en arrière sur ce point.

FAQ — vos questions fréquentes

Faut-il modifier mes automatisations ?

Non, aucune. Elles s’exécutent à l’identique. Le seul point d’attention concerne les
automatisations qui écrivent des fichiers sur le disque du serveur : si l’exécutant n’a pas
accès au même dossier que le processus principal, le fichier écrit devient introuvable. Montez
le même volume sur tous les exécutants, ou passez par un stockage extérieur.

Combien de mémoire faut-il au minimum ?

Comptez huit gigaoctets pour une configuration à deux exécutants avec PostgreSQL sur la même
machine. En dessous, le mode file d’attente consomme plus que ce qu’il apporte. Le détail des
paliers est dans quel VPS choisir pour n8n.

Redis contient-il mes données ?

Non. Il ne contient que des tickets de travail — l’identifiant de l’exécution à faire — dont
la durée de vie se compte en secondes. Vos automatisations, vos identifiants et votre historique
restent dans la base de données. Une perte de Redis fait perdre les exécutions en attente à cet
instant, rien d’autre.

Puis-je mettre les exécutants sur une autre machine ?

Oui, et c’est même l’intérêt principal de cette architecture à grande échelle. Il faut alors
que la file et la base soient joignables depuis ces machines, ce qui suppose un réseau privé
entre elles — n’exposez jamais Redis ni PostgreSQL sur l’internet public.

Est-ce que ça accélère une automatisation lente ?

Non, jamais. Une automatisation qui prend trois minutes en prendra toujours trois. Ce qui
change, c’est que les autres n’attendent plus qu’elle se termine. Si votre besoin est
d’accélérer un traitement précis, regardez du côté du traitement par lots et des appels
parallèles à l’intérieur de l’automatisation.

Que devient une exécution si un exécutant s’arrête en plein travail ?

Elle est marquée en échec, comme lors d’un redémarrage en fonctionnement normal. La
différence est que les exécutions en attente, elles, ne sont pas perdues : elles
restent dans la file et partent chez un autre exécutant. C’est un gain de robustesse, pas une
garantie d’exécution intégrale.

Faut-il un exécutant par automatisation ?

Non, et ce serait un contresens. Les exécutants ne sont pas spécialisés : n’importe
lequel prend n’importe quel travail. Vous dimensionnez sur le nombre d’exécutions simultanées,
pas sur le nombre d’automatisations installées.

Deux exécutions d’une même automatisation peuvent-elles se chevaucher ?

Oui, et c’est le changement de comportement le plus important de la bascule. En
fonctionnement normal, la seconde attend la fin de la première. Avec plusieurs exécutants, elles
tournent ensemble. Reprenez chaque automatisation programmée et demandez-vous ce qui se passe si
elle s’exécute deux fois en parallèle : c’est l’inventaire à faire avant, pas après.

Comment savoir quel exécutant a traité une exécution ?

L’exécution le renseigne dans son détail, et les journaux de chaque exécutant portent son
identifiant. C’est le premier réflexe de diagnostic en mode file d’attente : identifier le
processus, puis lire ses journaux — et non ceux du processus principal, qui n’a rien exécuté.

En résumé

Le mode file d’attente sépare celui qui reçoit de ceux qui exécutent. Il se justifie quand
vos exécutions attendent, pas quand elles sont lentes. Il demande trois pièces au lieu
d’une, impose PostgreSQL, et exige une clé de chiffrement déclarée à l’identique partout — c’est
l’erreur qui fait échouer neuf bascules sur dix.

Faites-le en trois temps : sauvegarde, migration de base seule, puis file et un seul
exécutant. Vérifiez qu’une automatisation utilisant un identifiant enregistré fonctionne avant
d’augmenter quoi que ce soit. Et surveillez le nombre d’exécutants vivants, parce que c’est le
seul des trois signaux qui tombe en panne sans rien dire.

Pour la suite : le fichier de configuration de base est décortiqué dans
n8n avec Docker, le fichier compose expliqué, la sauvegarde
qui précède l’opération dans sauvegarder, restaurer et
migrer n8n, et le dimensionnement de la machine dans
quel VPS choisir pour n8n.