Choisir un VPS pour n8n self-hosted : RAM, CPU et dimensionnement selon votre usage

n8n tourne sur des machines très modestes — c'est l'un des arguments du self-hosted. Mais entre le VPS d'entrée de gamme qui suffit à trois synchronisations et l'instance qui encaisse des pipelines RAG et des pics de webhooks, il y a un vrai travail de dimensionnement, et les erreurs se paient en OOM kill à 3 h du matin. Ce guide répond à la question précise : de combien de RAM, de CPU et de disque n8n a réellement besoin selon votre profil, et comment choisir l'hébergeur. Il complète nos guides sur le coût réel d'un n8n self-hosted (le TCO complet) et l'installation avec Docker (la mise en place) — ici, on parle uniquement de la machine.

Pourquoi la RAM est le facteur limitant

Un point d'architecture explique presque tout le dimensionnement de n8n : une exécution de workflow charge ses données en mémoire. Chaque item qui traverse le workflow, chaque réponse d'API, chaque document découpé en chunks pour un pipeline RAG existe en RAM pendant l'exécution. Un workflow qui récupère 10 000 lignes d'une API puis les transforme sur cinq nodes en garde plusieurs copies intermédiaires en mémoire simultanément.

Les fichiers binaires aggravent le phénomène : par défaut, une pièce jointe de 50 Mo qui traverse un workflow occupe de la RAM, pas seulement du disque. La variable N8N_DEFAULT_BINARY_DATA_MODE=filesystem déporte ces données binaires sur le disque et soulage nettement la mémoire — c'est l'un des premiers réglages à connaître, détaillé dans notre guide sur la gestion des fichiers volumineux dans n8n.

Le CPU, lui, est rarement le goulot d'étranglement : un workflow passe l'essentiel de son temps à attendre des API externes (un CRM, un modèle IA, une base de données), et pendant cette attente le processeur ne travaille pas. Ce déséquilibre entre utilisation moyenne et capacité installée est documenté de longue date : l'étude de Luiz André Barroso et Urs Hölzle, « The Case for Energy-Proportional Computing » (IEEE Computer, 2007, voir sur Google Scholar), a montré à partir des serveurs de Google que les machines passent la majorité de leur temps entre 10 et 50 % d'utilisation CPU — presque jamais à pleine charge. Un serveur d'automatisation est un cas d'école de ce profil : ne payez pas des vCPU qui attendront des webhooks, investissez dans la RAM qui, elle, reste occupée.

Trois profils, trois dimensionnements

Ordres de grandeur issus de la pratique — à ajuster selon vos workflows réels, pas des seuils officiels :

• Quelques workflows simples (synchronisations CRM, notifications Slack, veille RSS, petits volumes) : 1 à 2 vCPU et 2 Go de RAM suffisent, avec PostgreSQL sur la même machine. C'est le profil de la majorité des instances de freelances et de TPE.
• Workflows IA et RAG (documents découpés en chunks, embeddings, agents avec mémoire de conversation, fichiers PDF ou images) : visez 2 vCPU et 4 Go de RAM, davantage si plusieurs workflows lourds tournent en parallèle. Les appels aux modèles se font via API (le calcul est chez le fournisseur), mais les payloads, les documents et les contextes transitent tous par la mémoire de votre instance.
• Gros volumes et pics de charge (webhooks e-commerce en rafale, exécutions simultanées nombreuses) : au-delà d'un certain point, la réponse n'est plus un VPS plus gros mais le mode queue avec Redis et des workers — on y revient plus bas.

Côté disque, 20 à 40 Go couvrent largement le système, Docker et la base — à condition de purger l'historique des exécutions (voir les erreurs classiques ci-dessous).

SQLite ou PostgreSQL selon la taille

Sur un VPS de test, le SQLite par défaut fonctionne sans configuration. Dès que l'instance devient un maillon de production — historique d'exécutions qui grossit, sauvegardes sérieuses, et a fortiori mode queue, qui exige PostgreSQL — partez sur PostgreSQL directement : la migration après coup est le chantier qu'on repousse jusqu'à l'incident. Le docker-compose.yml complet est dans notre guide d'installation Docker, et la stratégie de sauvegarde dans le guide sauvegarde et restauration PostgreSQL. Comptez simplement que PostgreSQL sur la même machine consomme quelques centaines de Mo de RAM.

Choisir l'hébergeur : les critères qui comptent

Pour un public francophone, les hébergeurs européens — OVHcloud, Hetzner, Scaleway, entre autres — cochent les cases essentielles, avec des VPS d'entrée et de milieu de gamme à quelques euros par mois (les prix exacts évoluent trop vite pour être recopiés ici). Les critères à vérifier, dans l'ordre :

• Localisation UE et RGPD : des datacenters en France ou en Allemagne, opérés par une société européenne, simplifient la conformité quand les workflows traitent des données personnelles — souvent la raison même du choix self-hosted, comme le détaille notre comparatif self-hosted vs n8n Cloud ;
• Snapshots et sauvegardes intégrés : un snapshot du VPS avant chaque mise à jour de n8n est un filet de sécurité précieux — il complète, sans les remplacer, les sauvegardes applicatives de la base ;
• Montée en gamme sans réinstallation : vérifiez qu'on peut augmenter RAM et CPU du VPS existant plutôt que de migrer vers une nouvelle machine ;
• IPv4 dédiée et reverse DNS propres : nécessaires pour exposer vos webhooks en HTTPS avec un nom de domaine ;
• Trafic sortant : largement couvert par la plupart des offres, mais vérifiez les limites si vos workflows déplacent de gros fichiers.

Les erreurs de dimensionnement classiques

Trois pannes reviennent sans cesse sur les instances mal dimensionnées :

1. L'instance qui swap : la RAM déborde, le système compense sur le disque, et tout devient lent — l'éditeur rame, les webhooks répondent en plusieurs secondes. Le swap masque le problème au lieu de le résoudre : ajoutez de la RAM ou allégez les workflows (traitement par lots, mode filesystem pour le binaire).
2. L'OOM kill du conteneur : le noyau Linux tue le processus n8n quand la mémoire manque vraiment. Signature typique : le conteneur redémarre seul avec un code de sortie 137, et l'exécution en cours est perdue. Un healthcheck externe et une alerte, comme décrit dans notre guide de supervision d'une instance n8n, transforment ce crash silencieux en information exploitable.
3. Le disque plein à cause des exécutions sauvegardées : par défaut, n8n conserve les données de chaque exécution en base. Sur une instance active, cet historique se compte vite en gigaoctets. La parade tient en quelques variables d'environnement :

# Purge automatique de l'historique des exécutions
EXECUTIONS_DATA_PRUNE=true
EXECUTIONS_DATA_MAX_AGE=168            # conserve 7 jours (en heures)
EXECUTIONS_DATA_PRUNE_MAX_COUNT=10000  # et au plus 10 000 exécutions

# Optionnel : ne pas stocker le détail des exécutions réussies
EXECUTIONS_DATA_SAVE_ON_SUCCESS=none

Ces réglages — et les autres variables utiles au dimensionnement — sont passés en revue dans notre guide des variables d'environnement n8n. Ajustez la rétention à vos besoins réels de débogage : sept jours suffisent souvent.

Grossir le VPS ou passer en mode queue ?

Le scaling vertical (plus de RAM, plus de vCPU) est la bonne réponse tant que le problème est la taille des exécutions individuelles : un fichier plus gros, un contexte RAG plus long. Il atteint ses limites quand le problème devient le nombre d'exécutions simultanées : dans le mode d'exécution par défaut, tout tourne dans le même processus, et un pic de webhooks ou trois workflows IA longs qui se chevauchent se disputent la même mémoire.

À ce stade, le mode queue change l'architecture : une instance principale reçoit les déclencheurs, Redis fait la file d'attente, et des workers — sur la même machine ou sur d'autres — absorbent la charge en parallèle. Deux VPS modestes avec des workers offrent alors plus de résilience qu'une seule grosse machine, point de défaillance unique. Règle pratique : si vous envisagez de doubler la RAM pour la deuxième fois à cause de la concurrence (et non de la taille des payloads), c'est le signal d'étudier le mode queue.

En résumé

Dimensionnez un VPS n8n par la RAM, pas par le CPU : 2 Go pour des workflows simples, 4 Go et plus dès que l'IA et les fichiers s'en mêlent, PostgreSQL d'emblée si l'instance vise la production. Choisissez un hébergeur européen sur la localisation des données, les snapshots et la montée en gamme sans réinstallation — le tarif, à quelques euros par mois, est rarement décisif. Configurez EXECUTIONS_DATA_PRUNE dès le premier jour, surveillez le swap et les codes de sortie 137, et quand la concurrence devient le problème plutôt que la taille des exécutions, passez au mode queue plutôt que d'acheter un VPS toujours plus gros.