Héberger n8n sur un VPS : combien de RAM, pourquoi il plante et comment le tenir

n8n (prononcez « n-eight-n », pour nodemation) est un outil d’automatisation de workflows open source : il connecte vos applications entre elles, déclenche des actions sur événement et orchestre des traitements de données, le tout via une interface visuelle en nœuds. C’est l’alternative auto-hébergée la plus sérieuse à Zapier et Make (ex-Integromat) — avec un avantage décisif sur le portefeuille : pas de facturation à la tâche ou à l’exécution. Là où Zapier vous compte chaque « zap » déclenché, n8n self-hosted vous laisse lancer autant d’automatisations que votre serveur peut en encaisser.

Et c’est précisément là que se joue tout l’intérêt — et toute la difficulté — de l’héberger soi-même. Le terme « héberger n8n » donne l’impression d’un simple conteneur à lancer, et c’est vrai pour démarrer. Mais la vraie question, celle qui fait planter les instances en production, n’est pas comment l’installer : c’est combien de RAM lui donner et pourquoi il finit par tomber en panne de mémoire. Ce guide répond d’abord à ça, parce que c’est ce qui sépare une instance n8n qui tourne tranquillement d’une instance qui meurt au premier gros workflow.

Configuration requise : combien de RAM pour n8n ?

C’est la question piège de n8n, et la réponse honnête est : ça dépend de ce que font vos workflows. À vide, fraîchement démarré avec deux ou trois automatisations simples, n8n est étonnamment léger — le processus Node.js tourne autour de 300 à 500 Mo de RAM. Beaucoup de gens en déduisent qu’un petit VPS à 1 Go suffira. C’est l’erreur de dimensionnement la plus fréquente.

Le problème, c’est que la consommation de n8n n’est pas proportionnelle au nombre de workflows : elle dépend du volume de données qui transite dedans. Un workflow qui interroge une API et récupère 50 000 lignes JSON charge ces 50 000 lignes en mémoire. Un nœud qui manipule un fichier binaire de 100 Mo réclame cette mémoire d’un coup. Et si plusieurs exécutions se déclenchent en même temps, ces besoins s’additionnent. La RAM ne grimpe pas doucement : elle bondit par pics, au moment précis où un workflow lourd s’exécute.

C’est pourquoi la règle est nette : 2 Go de RAM au minimum pour un usage fonctionnel et confortable sur des workflows légers, et 4 Go en production dès que vous traitez des données volumineuses, enchaînez les exécutions ou faites tourner plusieurs workflows en parallèle. Le CPU est secondaire (1 à 2 vCPU suffisent), le stockage aussi (10 à 20 Go) — c’est la mémoire qui dimensionne votre VPS. Si vous hésitez sur les ordres de grandeur plus largement, ce guide dédié détaille la question : combien de RAM pour le self-hosting.

Pourquoi n8n plante (out of memory) et comment l’éviter

Voici la section qui vaut le détour, parce que c’est le mur que tout le monde finit par rencontrer. Vous avez une instance n8n qui tourne parfaitement depuis des semaines, puis un jour un workflow s’arrête brutalement, le conteneur redémarre tout seul, et dans les logs apparaît le verdict : JavaScript heap out of memory ou un processus tué par le système (OOM killer). Que s’est-il passé ?

La cause racine est architecturale. n8n fait transiter les données d’un nœud à l’autre en mémoire vive. Chaque élément qui sort d’un nœud (chaque ligne, chaque enregistrement, chaque fichier) est gardé en RAM pour être passé au nœud suivant. Tant que les volumes sont raisonnables, tout va bien. Mais trois situations font exploser ce modèle :

• Les workflows lourds en données : un nœud qui récupère des dizaines de milliers d’enregistrements d’un coup (export d’une base, scan d’une grosse API paginée mal découpée) charge tout en mémoire avant de continuer.
• Les gros payloads binaires : télécharger, convertir ou traiter des fichiers volumineux (PDF, images, archives) consomme énormément, car le binaire entier passe par la RAM.
• Les exécutions conservées en mémoire : par défaut, n8n garde la trace des exécutions, et accumuler l’historique de workflows verbeux finit par peser.

Voici comment éviter le crash, dans l’ordre où il faut s’y prendre :

1. Passer en mode queue (Redis + workers). C’est la solution structurelle. Au lieu d’un seul processus qui fait tout, le mode queue sépare le processus principal (qui reçoit les déclenchements) des workers (qui exécutent réellement les workflows), la coordination passant par Redis. Concrètement, un gros workflow qui s’exécute dans un worker ne fait plus tomber l’interface ni les autres exécutions, et vous pouvez répartir la charge sur plusieurs workers. C’est le passage obligé pour une instance de production sérieuse.
2. Limiter les données conservées. Réglez les variables de purge pour ne pas accumuler indéfiniment l’historique : EXECUTIONS_DATA_PRUNE active le nettoyage automatique, et EXECUTIONS_DATA_MAX_AGE fixe l’âge au-delà duquel les exécutions sont supprimées. Vous gardez votre base légère et vous récupérez de l’espace.
3. Découper les traitements par lots. Au niveau du workflow lui-même, utilisez les nœuds de découpage (traiter les éléments par paquets plutôt que tout d’un coup) pour ne jamais charger des dizaines de milliers d’items en une seule passe.
4. Augmenter la RAM. Parfois la réponse est simplement matérielle : si vos workflows ont légitimement besoin de manipuler de gros volumes, passez de 2 à 4 Go (ou plus). C’est moins élégant que le mode queue, mais c’est immédiat.

Retenez l’ordre : architecture (mode queue) d’abord, hygiène (purge des données) ensuite, matériel (RAM) en complément. Les trois se combinent.

SQLite ou PostgreSQL pour n8n en production ?

n8n a besoin d’une base de données pour stocker vos workflows, vos identifiants (chiffrés) et l’historique des exécutions. Deux options s’offrent à vous, et le choix dépend entièrement de votre niveau d’usage.

SQLite est la base par défaut, et c’est un excellent choix pour démarrer. Tout tient dans un simple fichier, il n’y a strictement rien à configurer, et les performances sont largement suffisantes pour un usage personnel ou modéré : quelques dizaines de workflows, des exécutions espacées, un seul processus n8n. Si vous découvrez l’outil ou si vos automatisations restent tranquilles, restez sur SQLite — inutile de se compliquer la vie.

PostgreSQL devient le bon choix dès que vous montez en charge. Le moment où SQLite atteint ses limites, c’est quand les écritures concurrentes se multiplient : beaucoup d’exécutions rapprochées, plusieurs workers en mode queue qui écrivent en même temps, un historique volumineux. SQLite, qui verrouille le fichier à l’écriture, devient alors un goulot d’étranglement. PostgreSQL gère la concurrence nativement et reste fluide sous charge. C’est d’ailleurs indispensable en pratique avec le mode queue : faire travailler plusieurs workers contre une base SQLite n’a pas de sens.

Le conseil pragmatique : si vous lancez n8n pour un vrai projet de production que vous savez amené à grossir, partez directement sur PostgreSQL. La migration de SQLite vers Postgres est possible, mais elle se fait dans de meilleures conditions quand on l’anticipe plutôt qu’en urgence une fois la base saturée. Pour un usage perso ou un test, SQLite est parfait — vous migrerez le jour où ce sera nécessaire.

Sauvegarder ses workflows et identifiants

C’est le point sur lequel beaucoup se font surprendre, parce qu’il y a un piège spécifique à n8n. Sauvegarder n8n, ce n’est pas seulement copier ses workflows — c’est protéger trois choses, et l’une d’elles n’est pas un fichier de données.

La base de données d’abord : c’est elle qui contient vos workflows, leur configuration et l’historique des exécutions. Avec SQLite, c’est le fichier de base situé dans le volume de données n8n (monté sur /home/node/.n8n) ; avec PostgreSQL, c’est un pg_dump de la base. Sauvegardez régulièrement ce volume ou cette base, idéalement de façon automatisée et hors du serveur.

La clé de chiffrement ensuite — et c’est le point critique. n8n chiffre vos identifiants (tokens d’API, mots de passe, clés de connexion aux services tiers) avec une clé, la fameuse N8N_ENCRYPTION_KEY. Si vous ne la définissez pas, n8n en génère une automatiquement au premier démarrage et la stocke dans son volume. Le danger est limpide : si vous perdez cette clé, vos identifiants enregistrés deviennent définitivement illisibles, même si vous avez une sauvegarde parfaite de la base. Vous restaureriez vos workflows, mais toutes leurs connexions seraient cassées, à reconfigurer une par une.

La bonne pratique est donc de définir explicitement N8N_ENCRYPTION_KEY (par exemple avec openssl rand -hex 32) dès l’installation, et de conserver cette valeur en lieu sûr, hors du serveur — dans votre gestionnaire de mots de passe. Vous pourriez justement la ranger dans un coffre-fort de mots de passe (un Vaultwarden auto-hébergé, par exemple) plutôt que sur le serveur lui-même. Ainsi, en cas de restauration sur un nouveau VPS, vous réinjectez la même clé et tout redevient lisible. Une sauvegarde n8n sans sa clé de chiffrement n’est qu’une demi-sauvegarde.

Combien coûte l’auto-hébergement de n8n ?

Soyons honnêtes sur la comparaison, parce qu’elle penche clairement d’un côté mais avec une contrepartie réelle. n8n existe en deux versions : n8n Cloud, l’offre hébergée par l’éditeur, facturée à l’abonnement avec des paliers selon le volume d’exécutions ; et la version self-hosted (Community Edition), que vous installez sur votre serveur, gratuite et sans limite d’exécutions.

C’est l’argument massue de l’auto-hébergement ici : sur n8n Cloud comme sur Zapier ou Make, plus vous automatisez, plus la facture grimpe — vous payez à la tâche, à l’opération, au volume. Sur une instance self-hosted, le nombre d’exécutions n’a aucune incidence sur le prix. Que vous lanciez 100 ou 100 000 automatisations dans le mois, vous payez la même chose : votre VPS. Un modèle 2 vCPU / 4 Go adapté à n8n coûte environ 5 à 8 €/mois chez les hébergeurs sérieux. Pour quiconque a un volume d’automatisations conséquent, l’économie face à un Zapier facturé à l’usage est spectaculaire.

La contrepartie, qu’il faut assumer franchement : la maintenance est à vous. Personne ne met à jour l’instance à votre place, ne surveille la RAM, ne gère les sauvegardes ni ne remet le service debout après un plantage. C’est le vrai « coût » caché du self-hosting — non pas en euros, mais en temps et en compétences. Si vous êtes à l’aise avec un VPS et Docker, ce coût est marginal et l’économie largement gagnante. Si l’idée de déboguer un out of memory un dimanche soir vous rebute, n8n Cloud facture précisément ce confort. Pour la cible de ce site — des gens qui veulent maîtriser leur infra et leurs données —, le self-hosted gagne presque toujours.

Quel hébergeur choisir pour n8n ?

Le réflexe à avoir : ne sous-dimensionnez pas la RAM. n8n trompe son monde par sa légèreté apparente au repos, et le petit VPS à 1 Go qui semble suffisant vous lâchera au premier gros workflow. Visez d’emblée un palier 4 Go si vous comptez faire de la production. Pensez aussi à la marge pour les briques annexes : si vous passez en mode queue, vous ferez tourner Redis (et souvent PostgreSQL) à côté de n8n, ce qui consomme un peu plus. Chez les trois hébergeurs ci-dessus, un VPS 4 Go reste très abordable et vous épargnera des plantages incompréhensibles au pire moment. Tous trois disposent de datacenters en Europe, ce qui garde vos workflows et vos données — souvent sensibles, puisqu’ils contiennent des accès à vos autres services — sur le sol européen.

Installer n8n sur un VPS avec Docker

L’installation de base est simple. Sur un VPS à jour avec Docker et le plugin Compose installés, générez d’abord votre clé de chiffrement et conservez-la :

openssl rand -hex 32

Créez ensuite un dossier puis un fichier docker-compose.yml. Voici une configuration réaliste, avec les variables essentielles à renseigner :

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n:latest
    container_name: n8n
    restart: unless-stopped
    ports:
      - "5678:5678"
    environment:
      # --- Domaine public et webhooks ---
      N8N_HOST: "n8n.mondomaine.fr"
      N8N_PORT: "5678"
      N8N_PROTOCOL: "https"
      WEBHOOK_URL: "https://n8n.mondomaine.fr/"
      # --- Clé de chiffrement des identifiants (openssl rand -hex 32) ---
      # À CONSERVER HORS DU SERVEUR : sans elle, les identifiants sont illisibles.
      N8N_ENCRYPTION_KEY: "REMPLACEZ_PAR_VOTRE_CLE_32_OCTETS_HEX"
      # --- Fuseau horaire ---
      GENERIC_TIMEZONE: "Europe/Paris"
      TZ: "Europe/Paris"
      # --- Purge des exécutions (évite l'accumulation en base) ---
      EXECUTIONS_DATA_PRUNE: "true"
      EXECUTIONS_DATA_MAX_AGE: "336"
    volumes:
      - n8n-data:/home/node/.n8n

volumes:
  n8n-data:

Quelques points de vigilance après le docker compose up -d :

• Le volume n8n-data monté sur /home/node/.n8n contient la base SQLite, vos workflows et la clé générée : c’est lui qu’il faut sauvegarder. Tant qu’il existe, vous pouvez détruire et recréer le conteneur sans rien perdre.
• Le port 5678 est le port d’écoute standard de n8n. Ne le laissez jamais exposé en clair sur Internet : placez un reverse proxy devant pour le HTTPS. Avec Caddy, quelques lignes suffisent à obtenir un certificat automatique :

n8n.mondomaine.fr {
    reverse_proxy localhost:5678
}

• WEBHOOK_URL est crucial si vos workflows utilisent des déclencheurs webhook : cette variable doit contenir l’URL publique HTTPS de votre instance, sinon les services tiers ne sauront pas où envoyer leurs notifications entrantes.
• Pour la production, ajoutez un service PostgreSQL (variables DB_TYPE: postgresdb et la connexion associée) et, si vous traitez de gros volumes, configurez le mode queue avec un service Redis et des workers dédiés.

Ouvrez ensuite http://IP_DU_VPS:5678 (ou votre domaine en HTTPS) : au premier lancement, n8n vous demande de créer le compte propriétaire. Vous arrivez alors sur l’éditeur visuel, prêt à construire votre premier workflow.

n8n est l’un des outils d’automatisation les plus puissants à s’auto-héberger, à condition de ne pas se tromper sur le dimensionnement : léger à l’installation, mais affamé de RAM dès que les workflows sérieux arrivent. Anticipez les 4 Go, prévoyez le mode queue pour la montée en charge, et n’oubliez jamais votre clé de chiffrement. Si vous hésitez encore sur la machine à louer, lisez d’abord quel VPS choisir pour le self-hosting, et pour surveiller que votre instance reste bien debout, pensez à coupler n8n avec Uptime Kuma.