Quel VPS choisir pour n8n ? Le guide de dimensionnement

Vous avez décidé d’héberger n8n
vous-même. Reste la question que personne ne traite vraiment : quelle machine
louer ? Les tutoriels vous montrent les commandes à taper, jamais comment choisir
le serveur sur lequel les taper. Résultat : on prend le premier VPS venu, et on découvre
trois semaines plus tard qu’il est deux fois trop petit — ou qu’on paie le double de ce qu’il
fallait.

Cet article répond dans l’ordre : ce que n8n consomme réellement, quel palier vous
concerne, les six critères qui éliminent un hébergeur, ce que coûte l’année, et comment changer
de serveur si vous vous êtes trompé. Aucune connaissance d’administration système n’est
supposée : il s’agit de choisir, pas d’installer. Pour l’installation, nous avons déjà le
guide pas à pas de n8n sur un VPS avec Docker.

Ce que n8n consomme vraiment

Première surprise pour qui vient du monde du site web : n8n ne ressemble à rien de ce
que vous avez hébergé avant. Un site vitrine consomme du processeur par à-coups, à chaque
visite, et presque pas de mémoire. n8n fait exactement l’inverse. Il occupe de la mémoire en
permanence, même quand il ne fait rien, et ne sollicite le processeur que par salves très
courtes.

La raison tient à sa nature. n8n est une application qui reste allumée, en attente. Elle
garde en mémoire la liste de vos automatisations, leurs déclencheurs, les connexions ouvertes
vers vos outils, et l’interface web qu’elle sert quand vous vous connectez. Une instance qui ne
traite aucune donnée occupe déjà entre trois cents et quatre cents mégaoctets. C’est le prix
d’entrée, et il ne baisse pas.

Ce qui varie, c’est ce qui passe à travers. Chaque exécution charge des données en
mémoire — une liste de contacts, le contenu d’un fichier, la réponse d’une interface de
programmation. Une exécution qui traite trente lignes de tableur ne se remarque pas. Une
exécution qui télécharge un fichier de cent mégaoctets pour le transformer occupe, elle, bien
plus que n8n lui-même au repos.

C’est le point que presque tous les guides ratent, et il change tout le raisonnement :
le nombre d’automatisations que vous possédez ne coûte presque rien. Ce sont les
exécutions simultanées, et leur volume de données, qui décident de la taille du
serveur. Cinquante workflows qui se déclenchent une fois par jour, chacun sur trois
lignes, tiennent sur une machine minuscule. Trois workflows qui manipulent des documents
complets, en même temps, exigent bien davantage.

La mémoire vive, la seule ressource qui décide

Quand un serveur d’automatisation tombe, c’est presque toujours la mémoire qui a manqué.
Pas le processeur, pas le disque, pas le réseau. Et la panne mémoire a une signature
reconnaissable : l’application disparaît brutalement, sans message d’erreur explicite dans
ses propres journaux, parce que c’est le système d’exploitation qui l’a arrêtée pour se
sauver lui-même. Vous retrouvez une instance redémarrée, des exécutions interrompues au
milieu, et aucune trace claire de ce qui s’est passé.

C’est aussi la ressource la plus désagréable à sous-dimensionner, parce que l’incident ne
survient pas quand vous testez tranquillement, mais le jour où trois automatisations se
déclenchent ensemble sur un volume inhabituel. Autrement dit : le pire moment.

Le raisonnement utile est donc celui de la marge. Prenez la consommation de base — comptez
large, six cents mégaoctets une fois le système et Docker ajoutés — puis estimez le pic de vos
exécutions, et gardez au moins autant de libre. Sur une machine de deux gigaoctets, cela laisse
environ huit cents mégaoctets pour travailler et autant de coussin. C’est confortable pour
l’immense majorité des usages.

Un mot sur la mémoire d’échange, ce fichier que le système utilise comme rallonge quand la
mémoire vive est pleine. Beaucoup de VPS d’entrée de gamme n’en configurent aucune. En ajouter
un ou deux gigaoctets est une opération de deux minutes et transforme une panne sèche en simple
ralentissement. Ce n’est pas une excuse pour prendre trop petit — travailler dans l’échange est
très lent — mais c’est un filet qui a sauvé beaucoup d’instances.

Les quatre paliers, et lequel vous concerne

Il n’existe en pratique que quatre cas. Identifier le vôtre prend trente secondes, et vous
évite aussi bien la machine étranglée que celle payée deux fois trop cher.

Un gigaoctet ou moins : pour essayer, rien de plus

n8n démarre sur une machine d’un gigaoctet, et beaucoup de gens s’arrêtent à ce constat. Il
faut aller plus loin : il démarre, mais il ne laisse presque aucune marge. La première
exécution un peu grasse, la première mise à jour, le premier import d’un gros fichier, et
l’application s’arrête. C’est un palier de découverte, pas de production. Si votre facturation
en dépend, n’y mettez rien.

Et il existe un meilleur endroit pour découvrir : votre propre ordinateur. Le guide
installer n8n en local vous met une instance complète
entre les mains en une soirée, gratuitement, sans rien exposer sur internet.

Deux gigaoctets : le vrai point de départ

C’est le palier qui convient à l’écrasante majorité des indépendants, des artisans et des
petites structures. Des dizaines d’automatisations actives, plusieurs milliers d’exécutions par
jour, la base de données incluse, l’interface fluide. Vous pouvez y ajouter des appels à des
modèles de langage sans difficulté : le calcul se fait chez le fournisseur, votre serveur
ne fait qu’envoyer et recevoir du texte.

Si vous hésitez entre deux paliers et que rien dans la liste ci-dessous ne vous concerne,
prenez celui-ci. Vous pourrez monter plus tard en quelques minutes.

Quatre gigaoctets : quand une de ces cases est cochée

• Vous faites tourner une base PostgreSQL sur la même machine.
• Vos automatisations manipulent des fichiers volumineux — documents, images,
  exports complets.
• Vous utilisez des nœuds qui pilotent un navigateur pour lire des pages web.
  C’est de loin le poste le plus gourmand : un navigateur, même sans interface, coûte plus
  cher que n8n tout entier.
• Plusieurs personnes se connectent à l’interface en même temps.
• Vous hébergez autre chose sur la même machine — un site, une base, un outil
  interne.

Huit gigaoctets et plus : le mode file d’attente

À partir d’un certain volume, faire tout traiter par un seul processus ne suffit plus. n8n
propose alors un fonctionnement où les exécutions sont mises en file et distribuées à plusieurs
processus exécutants, coordonnés par un intermédiaire. C’est nettement plus robuste et cela
encaisse les pics, mais cela ajoute des pièces à surveiller.

Ne partez pas là-dessus par anticipation. C’est une réponse à un problème constaté — des files qui s’allongent, des exécutions qui attendent — pas une précaution. La très grande majorité des instances n’y arrivent jamais. Si vous avez justement constaté ce problème, l’opération complète est décrite dans n8n en mode file d’attente, passer à plusieurs exécutants.

Le processeur : pourquoi il compte moins qu’on ne croit

Les pages d’hébergeurs mettent le nombre de cœurs en avant parce que c’est le chiffre le
plus lisible. Pour n8n, c’est rarement lui qui vous limitera. Un ou deux cœurs virtuels
suffisent au démarrage, et deux couvrent déjà des usages sérieux.

Le processeur devient un sujet dans trois situations précises. D’abord les transformations
lourdes : boucler sur des dizaines de milliers de lignes, effectuer des calculs dans un
nœud de code. Ensuite le pilotage d’un navigateur, encore lui, qui consomme sans retenue.
Enfin le chiffrement et la compression, si vous manipulez des archives.

Il y a en revanche un point de vigilance que les fiches techniques ne mentionnent jamais.
Certains hébergeurs vendent des cœurs partagés : vous disposez de la pleine
puissance par courtes rafales, puis vous êtes bridé si vous dépassez un quota. Pour un site web
qui répond en cent millisecondes, c’est invisible. Pour une automatisation qui traite un gros
lot pendant dix minutes, le bridage arrive en plein travail et rallonge tout. Si vos traitements
sont longs, cherchez la mention de ressources dédiées, pas seulement le nombre de cœurs.

Le disque : ce n’est pas n8n qui le remplit

L’application elle-même, avec son environnement, occupe quelques centaines de mégaoctets.
Vos automatisations, quelques mégaoctets tout au plus. Un disque de vingt gigaoctets paraît
donc surdimensionné. Il l’est — jusqu’au jour où il est plein.

Le coupable est toujours le même : l’historique des exécutions. Par
défaut, n8n conserve le détail de chaque passage, y compris les données qui ont transité. C’est
précieux pour déboguer et c’est ce qui rend l’outil agréable. Mais mille exécutions par jour
qui manipulent chacune quelques dizaines de kilooctets font plusieurs gigaoctets par mois. Le
disque se remplit lentement, sans que rien n’alerte, et le jour où il est plein l’application
ne peut plus rien écrire du tout.

La parade est un réglage à poser dès le premier démarrage, pas après l’incident :
activez l’élagage automatique de l’historique et fixez une durée de conservation. Deux semaines
suffisent à peu près à tout le monde ; un mois si vous êtes prudent. Vous pouvez aussi
plafonner le nombre d’exécutions conservées. Ces réglages se passent par variables d’environnement, dans le même fichier que le reste de la configuration — nous les détaillons dans le fichier compose expliqué.

Deuxième consommateur, plus discret : les images Docker périmées. Chaque mise à jour
télécharge une nouvelle image sans supprimer l’ancienne. Après six mois de mises à jour
mensuelles, plusieurs gigaoctets dorment sans servir. Un nettoyage trimestriel règle la
question définitivement.

Sur la nature du disque : prenez du stockage à mémoire flash, pas du disque mécanique.
Ce n’est plus vraiment un choix aujourd’hui, mais quelques offres très bon marché en proposent
encore, et la différence de confort à l’usage est considérable.

SQLite ou PostgreSQL : la bascule qui change le dimensionnement

n8n stocke ses données dans une base SQLite par défaut : un simple fichier, aucune
installation, aucune configuration. C’est un excellent choix, et il faut résister à l’idée
répandue selon laquelle « une vraie production a besoin de PostgreSQL ». Pour la plupart des
instances, SQLite tient très bien, très longtemps.

Deux situations justifient la bascule. La première est la concurrence : SQLite gère mal
plusieurs écritures au même instant, ce qui devient sensible quand beaucoup d’exécutions
s’exécutent en parallèle. La seconde est le mode file d’attente évoqué plus haut, qui la rend obligatoire puisque plusieurs processus doivent écrire ensemble.

Le point qui nous intéresse ici est le coût en ressources. Une base PostgreSQL installée sur
la même machine consomme sa propre mémoire, entre deux et quatre cents mégaoctets pour une
configuration modeste. Sur une machine de deux gigaoctets, cela mange la marge que vous veniez
de vous réserver. Si vous prévoyez PostgreSQL en local, prenez quatre gigaoctets, pas
deux. L’alternative est une base gérée chez l’hébergeur : elle ne consomme rien
chez vous, mais elle se facture à part.

Les six critères qui éliminent un hébergeur

Avant de comparer les prix, il faut éliminer. Ces six points ne se négocient pas : si
un seul manque, l’offre ne convient pas, quel qu’en soit le tarif.

L’accès administrateur complet

Vous devez pouvoir installer ce que vous voulez, Docker en premier lieu. Cela paraît évident,
mais beaucoup d’offres bon marché sont en réalité des hébergements mutualisés déguisés, où vous
n’avez accès qu’à un panneau. Le mot à chercher est « serveur privé virtuel »,
éventuellement « serveur dédié ». Pas « hébergement web ».

Une adresse IPv4 dédiée

Vos webhooks — les adresses que vos autres outils appellent pour déclencher vos
automatisations — doivent être joignables depuis internet, et votre nom de domaine doit pointer
quelque part. Une adresse partagée ou uniquement en IPv6 vous compliquera durablement la vie,
car certains services n’appellent encore qu’en IPv4.

Un centre de données en Europe

Deux raisons, l’une juridique et l’autre pratique. Si vos automatisations manipulent des
données personnelles — et elles en manipulent presque toujours, ne serait-ce que des adresses
de courriel — les héberger dans l’Union européenne vous évite tout le sujet des transferts hors
Union. Et pour un usage francophone, la latence est plus faible, donc l’interface plus
agréable.

Des instantanés inclus

Un instantané est une photographie complète de votre machine, restaurable en quelques
minutes. C’est votre filet quand une mise à jour se passe mal ou qu’une fausse manœuvre efface
quelque chose. Certains hébergeurs les incluent, d’autres les facturent, d’autres n’en
proposent pas du tout. Cette dernière catégorie est éliminatoire. Attention : un instantané
n’est pas une sauvegarde — il vit sur la même infrastructure. Il vous faut aussi une copie
ailleurs, mais c’est un autre sujet.

Le redimensionnement à chaud

Pouvoir passer de deux à quatre gigaoctets sans réinstaller quoi que ce soit change
entièrement la manière d’aborder le choix initial. Avec cette possibilité, prendre petit n’est
plus un risque : c’est une décision réversible en dix minutes. Sans elle, vous devez viser
juste du premier coup, ce qui pousse à surpayer. Vérifiez aussi le sens inverse : certains
hébergeurs permettent de monter mais pas de redescendre.

La facturation à l’heure

Elle vous autorise à monter une machine, à la tester une journée réelle et à la détruire pour
quelques centimes si elle ne convient pas. C’est la manière la plus honnête de choisir, et elle
vaut mieux que n’importe quel comparatif — le nôtre compris. Fuyez les engagements de douze mois
tant que vous n’avez pas mesuré votre propre consommation.

Le tour des hébergeurs, par profil

Nous ne donnerons pas de tarifs précis : ils changent trop souvent pour qu’un article
reste juste, et les promotions faussent toute comparaison. Ce qui ne change pas, en revanche,
c’est le positionnement de chaque acteur et le type d’utilisateur auquel il convient.

Une remarque qui vaut pour tous : méfiez-vous du prix de la première année. Beaucoup
d’offres affichent un tarif d’appel très bas qui double ou triple au renouvellement. Regardez
toujours le prix de reconduction, c’est celui que vous paierez pendant des années.

Deuxième remarque, sur les offres dites « à vie » ou vendues une fois pour toutes,
qu’on voit passer régulièrement. Un serveur coûte de l’électricité et de la maintenance chaque
mois ; personne ne peut absorber cela indéfiniment contre un paiement unique. Ces offres
finissent par fermer, et votre automatisation avec elles.

ARM ou x86 : le pari qui divise la facture

Les hébergeurs proposent de plus en plus de machines à processeur ARM, la même famille que
celle des téléphones et des ordinateurs portables récents. À prix égal, elles offrent souvent
plus de mémoire, ou la même pour nettement moins cher.

La bonne nouvelle : les images Docker officielles de n8n existent pour cette
architecture. L’application tourne donc sans adaptation ni astuce.

La réserve, et elle est réelle : tout ce qui gravite autour n’est pas systématiquement
disponible. Certains outils annexes, certains nœuds communautaires qui embarquent des
composants compilés, ou le pilotage de navigateur, peuvent demander du travail supplémentaire —
voire ne pas fonctionner. Si votre usage se limite à n8n et à une base de données, l’ARM est un
très bon calcul. Si vous prévoyez d’installer des briques exotiques à côté, restez sur du x86 et
dormez tranquille.

Ce qu’il ne faut pas prendre

Autant que le bon choix, il est utile de nommer les mauvais — ce sont ceux qu’on retrouve le
plus souvent dans les demandes d’aide.

• Un hébergement web mutualisé. Pas d’accès administrateur, donc pas de
  Docker, donc rien à faire. C’est l’erreur la plus fréquente, parce que c’est l’offre la plus
  visible et la moins chère.
• Une offre gratuite qui met l’application en veille. Plusieurs plateformes
  endorment un service inactif et le réveillent à la première visite. Pour un site, c’est
  acceptable. Pour n8n, c’est rédhibitoire : une instance endormie ne déclenche aucune tâche
  programmée et ne répond à aucun webhook. Vous découvrirez le problème quand une facture ne
  sera pas partie.
• Un serveur hors d’Europe pour économiser deux euros. Le gain ne compense
  jamais la complexité réglementaire ajoutée dès qu’il y a des données personnelles.
• Une machine domestique exposée sur internet. Excellent pour apprendre,
  risqué pour ce dont dépend votre activité : votre connexion tombe, vos automatisations
  tombent ; une coupure de courant vous arrête ; et ouvrir une machine de votre réseau
  personnel demande des précautions que peu de gens prennent réellement.

Tester avant de s’engager

Voici la méthode qui remplace avantageusement toute lecture de comparatif, y compris
celui-ci. Elle prend une journée et coûte moins d’un euro.

1. Créez la plus petite machine qui vous semble plausible, facturée à l’heure.
2. Installez n8n en suivant le guide pas à pas.
3. Importez vos automatisations réelles, ou les trois plus lourdes si vous en avez beaucoup.
4. Laissez tourner une journée ouvrée complète, sans rien surveiller.
5. Le lendemain, regardez deux choses seulement : la mémoire utilisée au pic, et le
   nombre d’exécutions qui ont échoué.

Si le pic reste sous soixante-dix pour cent de la mémoire disponible et qu’aucune exécution
n’a échoué faute de ressources, votre machine convient. Si le pic frôle les quatre-vingt-dix
pour cent, montez d’un palier. Si l’instance a redémarré toute seule, vous avez votre
réponse.

Cette mesure vaut infiniment mieux qu’une estimation, parce qu’elle porte sur
vos automatisations, avec vos volumes. Deux entreprises de taille identique
peuvent avoir des besoins qui varient d’un facteur cinq.

Le coût réel sur un an

Le prix du serveur n’est pas le prix de la solution. Voici les postes à additionner pour
comparer honnêtement avec une offre gérée.

Le poste que personne ne chiffre est le dernier, et c’est pourtant le plus lourd. Une
instance auto-hébergée demande, réalistement, une à deux heures par trimestre : mises à
jour, vérification des sauvegardes, coup d’œil aux journaux. Ce n’est pas énorme, mais ce n’est
pas zéro, et cela doit entrer dans la comparaison si vous hésitez avec une formule gérée où tout
cela est fait pour vous.

Notre position est simple : l’auto-hébergement devient rentable dès que vous dépassez
quelques milliers d’exécutions par mois, et il l’est massivement au-delà, puisque le prix ne
dépend plus du volume. En dessous, la formule gérée reste défendable — surtout si votre temps
vaut cher. Nous avons développé cette comparaison dans
n8n Cloud ou auto-hébergé.

Changer de serveur plus tard

Dernière raison de ne pas se torturer sur le choix initial : se tromper coûte peu. Une
migration d’un hébergeur à un autre se fait en une soirée si vous avez pris deux précautions dès
le départ.

La première est de définir vous-même la clé de chiffrement plutôt que de
laisser n8n en générer une. Cette clé protège vos identifiants enregistrés. Si vous la
connaissez et la reportez sur le nouveau serveur, tout se rebranche. Si vous l’avez laissée
générer sans la conserver, vous devrez reconnecter chaque service à la main — ce qui, sur
trente automatisations, occupe une soirée entière.

La seconde est de garder votre fichier de configuration sous la main,
ailleurs que sur le serveur. C’est lui qui décrit toute l’installation ; avec lui et une
copie des données, remonter ailleurs prend le temps de télécharger les images.

La procédure complète, avec le test de restauration qui la valide, est décrite dans sauvegarder, restaurer et migrer n8n. La méthode reste toujours la même : montez la nouvelle instance à côté, importez, testez sur une destination sans conséquence, puis basculez le nom de domaine.
Gardez l’ancienne machine allumée une semaine — un retour en arrière gratuit vaut mieux qu’une
nuit blanche.

FAQ — vos questions fréquentes

Deux gigaoctets, ça tient jusqu’à combien d’automatisations ?

La question est mal posée, et c’est le cœur du sujet. Le nombre d’automatisations n’a
quasiment pas d’incidence : elles dorment tant qu’elles ne se déclenchent pas. Ce qui
compte est le nombre d’exécutions simultanées et le volume de données qu’elles
transportent. Cinquante automatisations légères tiennent sans peine ; trois automatisations
qui traitent chacune un gros fichier au même moment peuvent saturer la même machine.

Un cœur de processeur suffit-il ?

Pour démarrer, oui, dans la plupart des cas. Deux cœurs apportent surtout du confort quand
vous utilisez l’interface pendant qu’une exécution tourne. Le processeur ne devient réellement
limitant que si vous bouclez sur de très gros volumes ou pilotez un navigateur.

Faut-il prendre PostgreSQL dès le départ ?

Non. SQLite convient très bien et vous évite une pièce à administrer. Basculez le jour où
vous constatez des blocages d’écriture, ou si vous passez en mode file d’attente. Retenez
simplement que PostgreSQL sur la même machine consomme sa propre mémoire : si vous
l’installez, montez d’un palier.

Combien de disque prévoir ?

Vingt gigaoctets suffisent largement, à une condition : activer l’élagage de
l’historique d’exécution dès le premier jour. Sans lui, n’importe quelle taille finit par être
insuffisante, c’est seulement une question de délai.

Une machine ARM, est-ce risqué ?

Pour n8n seul, non : les images officielles existent pour cette architecture. Le risque
concerne les briques que vous ajouteriez à côté — certains nœuds communautaires et le pilotage
de navigateur, en particulier. Usage simple : excellent rapport qualité-prix. Usage
exotique : restez sur du x86.

Puis-je héberger n8n sur le même serveur que mon site ?

Techniquement oui, si vous avez l’accès administrateur et de la mémoire disponible. En
pratique, nous le déconseillons pour une raison simple : une automatisation qui consomme
trop fera tomber votre site, et vous perdrez les deux d’un coup. Si vous le faites malgré tout,
prenez quatre gigaoctets et posez des limites de mémoire sur le conteneur n8n.

Et si je me trompe de taille ?

Chez tout hébergeur sérieux, le redimensionnement prend quelques minutes et ne demande
aucune réinstallation : c’est justement l’intérêt d’une installation en conteneur. C’est
pourquoi nous conseillons de commencer petit : un surdimensionnement se paie tous les
mois, un sous-dimensionnement se corrige en dix minutes.

Faut-il un nom de domaine ?

Oui, et un sous-domaine de celui que vous possédez déjà suffit parfaitement. Il vous faut une
adresse stable en HTTPS pour que vos webhooks soient joignables et pour que le certificat se
génère automatiquement. Travailler sur l’adresse IP brute fonctionne pour un essai, jamais en
production.

En résumé

Deux gigaoctets de mémoire, un ou deux cœurs, vingt gigaoctets de disque chez un hébergeur
européen qui propose instantanés, redimensionnement à chaud et facturation à l’heure :
c’est la réponse pour la grande majorité des cas, et elle coûte le prix de deux cafés par mois.
Montez d’un palier si vous ajoutez PostgreSQL, si vous manipulez de gros fichiers ou si vous
pilotez un navigateur. Activez l’élagage de l’historique dès le premier jour, et notez votre
clé de chiffrement quelque part : ces deux gestes vous éviteront les deux incidents les
plus fréquents.

La machine choisie, la suite est balisée : le montage complet est décrit pas à pas dans
installer n8n sur un VPS avec Docker. Et si vous
hésitez encore entre héberger vous-même et prendre une formule gérée, nous avons pesé les deux
options dans n8n Cloud ou auto-hébergé.