Configuration requise pour n8n

Combien de machine une instance n8n auto-hébergée nécessite réellement, ce qu'ajoute la base de données, et le point à partir duquel une instance unique ne suffit plus. La plupart des conseils de dimensionnement trouvés en ligne sont écrits pour le mode file d'attente, dont la plupart des gens n'ont jamais besoin, si bien qu'ils paraissent une exigence bien plus grande qu'elle ne l'est.

En bref

Une instance n8n unique qui fait tourner des workflows ordinaires n'est pas un logiciel exigeant. Deux vCPU et 2 GB de RAM suffisent confortablement pour une charge réelle de tâches planifiées, de webhooks et d'appels API, car n8n passe l'essentiel de son temps à attendre les services d'autrui plutôt qu'à calculer. Le processus principal de n8n reste autour de 300 MB au repos.

Ce qui fait réellement monter le chiffre n'est pas le nombre de workflows définis. C'est la quantité de données qu'une seule exécution garde en mémoire à la fois, et le nombre d'exécutions simultanées.

Ce qui consomme la mémoire dans n8n

n8n fait circuler les données entre les nœuds sous forme d'éléments conservés en mémoire pendant toute la durée de l'exécution. Pour le dimensionnement, cela a une conséquence importante : un workflow qui récupère dix mille lignes et les fait passer par cinq nœuds est un locataire bien plus lourd que cent workflows qui déplacent chacun une charge de webhook.

• Taille des données par exécution. Les grosses réponses HTTP, les imports de tableurs et les fichiers binaires sont la cause habituelle d'une instance qui allait bien et qui, soudain, ne va plus.
• Concurrence. Dix exécutions tournant en même temps occupent chacune leur propre jeu de données de travail. Une planification qui déclenche plusieurs workflows à la même minute est un pic que vous n'avez pas prévu.
• Historique d'exécution. Les données d'exécution sauvegardées s'accumulent dans la base de données. C'est une question de disque et de base de données plutôt que de RAM, mais c'est ce qui grossit discrètement pendant des mois avant de compter.

Conséquence pratique : si vous traitez de gros volumes, découpez-les. Répartir un grand jeu de données en lots fait davantage pour la stabilité que n'importe quelle quantité de RAM supplémentaire, car cela modifie le pic au lieu d'élever le plafond.

La base de données est une exigence, pas une optimisation

n8n utilise SQLite par défaut, ce qui convient à un essai mais est une mauvaise idée en production. Il gère mal les exécutions simultanées et se sauvegarde et se restaure de façon peu fiable. PostgreSQL est la réponse pour la production, et il n'est pas gratuit en ressources : prévoyez environ 500 MB à 1 GB, qui grandissent avec votre historique d'exécution.

Ce chiffre est celui que la plupart des guides de dimensionnement intègrent discrètement dans la même case que n8n lui-même. Sur un VPS en DIY, il sort de la même RAM que vos workflows, à côté du runtime de conteneurs, d'un reverse proxy et du système d'exploitation. Sur nos offres, le cluster PostgreSQL est un composant haute disponibilité distinct, avec sa propre mémoire, si bien que la RAM indiquée dans le nom de l'offre est la RAM de n8n.

CPU : généralement pas la contrainte

n8n est dominé par l'attente. Une exécution passe son temps en allers-retours réseau vers des API, et non en calcul, donc deux cœurs suffisent largement. Les exceptions existent mais sont précises : transformation de données lourde dans les nœuds de code, analyse de gros JSON, et workflows IA qui font un vrai travail local plutôt que d'appeler une API de modèle. Si vos workflows sont surtout des intégrations, ajoutez de la RAM avant des cœurs.

Quand vous avez besoin du mode file d'attente

Par défaut, n8n exécute tout dans un seul processus. Le mode file d'attente le scinde : une instance principale reçoit les déclencheurs et confie les exécutions à des processus workers séparés via Redis, si bien que le processus principal reste réactif quelle que soit la durée d'un travail. C'est la réponse standard pour faire passer n8n à l'échelle, et c'est aussi la raison pour laquelle la plupart des conseils de dimensionnement publiés semblent aussi lourds.

Vous en avez besoin lorsque l'une de ces conditions est vraie, et pas avant :

• Les longues exécutions bloquent les courtes. Un workflow qui prend cinq minutes fera attendre un webhook entrant derrière lui en mode processus unique. En mode file d'attente, l'instance principale accuse réception immédiatement et un worker effectue le travail.
• Vous voyez un retard visible. Le signal le plus clair est la présence d'exécutions en attente depuis plus de quelques secondes dans l'interface n8n. Cela signifie qu'une file se forme, et aucune quantité de RAM supplémentaire sur un seul processus ne la supprime.
• Un seul gros travail peut faire tomber l'instance avec lui. L'isolation est souvent la vraie motivation, plutôt que le débit.

Le mode file d'attente ajoute deux éléments à vos besoins. Redis, petit, autour de 128 MB, mais un composant de plus à faire tourner ; et la RAM par worker : chaque processus worker consomme environ 200 à 500 MB selon ce que transportent vos workflows. Deux workers constituent le point de départ raisonnable, et vous n'en ajoutez que lorsque la file d'attente le justifie. Les workers réclament bien plus de RAM que de cœurs, ce qui explique pourquoi la montée en charge habituelle ajoute deux ou trois fois plus de mémoire avant d'ajouter du CPU.

Soyons francs : un déploiement en mode file d'attente à plusieurs workers nécessite un composant Redis et plus de mémoire que ne le proposent les offres ci-dessus. Ce n'est donc pas ce que ces offres sont. Elles sont conçues pour une instance n8n unique avec une base haute disponibilité, ce qui correspond à la grande majorité des instances auto-hébergées. Si vous avez mesuré un retard et avez réellement besoin de workers, vous avez dépassé un déploiement en un clic et devriez dimensionner une pile dédiée.

Stockage, et ce qui grossit

n8n lui-même a très peu besoin de disque. C'est l'historique d'exécution qui grossit, et il grossit proportionnellement à la fréquence d'exécution de vos workflows plutôt qu'à leur nombre. Un workflow qui interroge une API toutes les dix minutes génère à lui seul environ 4,300 exécutions par mois. Purgez les données d'exécution sauvegardées selon une politique de rétention plutôt que d'attendre que le disque décide à votre place, et conservez les exécutions en échec plus longtemps que les réussies, car ce sont les seules que vous lirez jamais.

Exigences qui ne sont pas du matériel

Deux d'entre elles comptent plus que toute spécification. Les webhooks ont besoin d'une URL HTTPS publique stable, ce qui suppose un vrai domaine, un certificat valide et un reverse proxy devant n8n ; une instance auto-hébergée sans cela peut exécuter des planifications mais ne peut rien recevoir. Et une plateforme d'automatisation doit être active au moment où le déclencheur se produit, ce qui exclut un ordinateur portable et fait de la disponibilité une exigence au même titre que la RAM.

Questions fréquentes