De combien de RAM le n8n auto-hébergé a-t-il besoin ?

Environ 2 Go est le point idéal confortable pour n8n plus sa base de données Postgres et des workflows normaux. Il tourne en 1 Go si les workflows sont légers, mais vous le sentirez lors de plus grosses exécutions. Exécutions parallèles lourdes ou gros payloads — passez à 4 Go.

Ai-je besoin de Docker pour auto-héberger n8n ?

C'est de loin la façon la plus simple — un fichier compose vous donne n8n, une base de données et un stockage persistant, et les mises à niveau se font en un seul pull. Vous pouvez installer via npm à la place, mais Docker vous épargne les maux de tête de dépendances et de mise à niveau.

Auto-héberger n8n est-il moins cher que n8n cloud ?

Si vous faites tourner un flux constant d'automatisations, oui — un VPS mensuel fixe bat la tarification à l'exécution, et il n'y a aucun plafond de workflow ou d'exécution. Pour une poignée d'exécutions par mois, un siège hébergé peut être plus simple. L'autre raison pour laquelle les gens auto-hébergent, c'est le contrôle : vos données et clés API ne quittent jamais votre serveur.

Ai-je besoin d'un domaine pour n8n ?

Pour les nœuds basés sur OAuth (Google, etc.) et un HTTPS propre, oui — pointez un domaine vers le serveur et placez n8n derrière un reverse proxy avec un certificat. Pour un usage purement interne, vous pouvez l'atteindre via un tunnel SSH sans domaine.

n8n peut-il tourner sur un VPS NAT ou ai-je besoin d'une IP dédiée ?

L'usage interne/par tunnel SSH fonctionne sur une machine NAT. Si vous voulez une URL publique avec votre propre domaine et HTTPS (nécessaire pour certains callbacks OAuth et webhooks), une offre à IP dédiée est le choix plus propre puisque vous contrôlez tous les ports.

Auto-hébergez n8n sur un VPS avec Docker

n8n est le genre d'outil que vous commencez à utiliser légèrement, puis à travers lequel vous routez discrètement la moitié de vos opérations. À ce moment-là, « il tourne sur le siège cloud de quelqu'un, facturé à l'exécution, avec mes clés API vivant sur leurs serveurs » commence à sembler moins génial. L'auto-hébergement corrige les trois — coût fixe, pas de plafond d'exécution, et vos clés restent sur une machine que vous possédez. Avec Docker, c'est l'affaire de quinze minutes.

De combien de serveur il a réellement besoin

Des chiffres honnêtes d'abord, pour ne pas acheter trop ou trop peu :

~2 Go de RAM est le point idéal — n8n plus sa base de données Postgres plus des workflows normaux y sont confortables.
1 Go fonctionne si vos workflows sont légers, mais vous le remarquerez sur de plus grosses exécutions.
4 Go si vous faites des exécutions parallèles lourdes ou poussez de gros payloads.

n8n n'est pas gourmand en CPU au repos ; il pointe pendant les exécutions. Une machine à 2 cœurs convient à la plupart des configurations. (Plus sur l'adéquation specs/charge dans le guide de dimensionnement.)

La configuration Docker

Sur une machine Ubuntu/Debian neuve, installez Docker :

curl -fsSL https://get.docker.com | sudo sh

Créez un dossier et un docker-compose.yml — n8n avec un volume persistant et Postgres :

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n
    restart: always
    ports:
      - "127.0.0.1:5678:5678"
    environment:
      - N8N_HOST=n8n.yourdomain.com
      - N8N_PROTOCOL=https
      - WEBHOOK_URL=https://n8n.yourdomain.com/
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=db
      - DB_POSTGRESDB_PASSWORD=change-me
    volumes:
      - ./n8n-data:/home/node/.n8n
    depends_on: [db]
  db:
    image: postgres:16
    restart: always
    environment:
      - POSTGRES_PASSWORD=change-me
      - POSTGRES_DB=n8n
    volumes:
      - ./db-data:/var/lib/postgresql/data

sudo docker compose up -d

Deux choses à souligner : les volumes (n8n-data, db-data) sont ce qui garde vos workflows en vie à travers les redémarrages et les mises à niveau — ne les sautez pas. Et n8n est lié à 127.0.0.1, pas 0.0.0.0 — il n'est pas exposé directement à Internet. C'est délibéré ; l'étape suivante gère l'accès en toute sécurité.

Accès : HTTPS ou un tunnel

URL publique (nécessaire pour les nœuds OAuth et les webhooks) : pointez un sous-domaine vers le serveur et faites tourner un reverse proxy (Caddy est le moins coûteux — HTTPS automatique) devant 127.0.0.1:5678. C'est là qu'une offre à IP dédiée convient, puisque vous contrôlez les ports et le DNS.
Juste pour vous, sans domaine : sautez le proxy et atteignez-le via un tunnel SSH — ssh -L 5678:127.0.0.1:5678 user@server, puis ouvrez localhost:5678. Fonctionne très bien sur un VPS NAT.

Verrouillez-le et gardez-le debout

n8n détient vos clés API et vos identifiants, la machine doit donc être bien serrée : faites la checklist de sécurité (clés SSH, pare-feu, pas de connexion par mot de passe) avant d'y mettre de vrais identifiants. restart: always dans le fichier compose signifie déjà que Docker relance n8n après un plantage ou un redémarrage — votre disponibilité est gérée.

En vaut-il la peine ?

Soyez honnête avec vous-même sur le volume. Si vous faites tourner des automatisations en permanence, l'auto-hébergement l'emporte sur le coût (fixe vs à l'exécution) et supprime tout plafond de workflow/exécution. Si vous déclenchez quelques flux par mois, un siège hébergé est moins de tracas. Mais l'argument du contrôle tient de toute façon : vos workflows, vos données, vos clés — sur votre serveur, pas loués. Pour la plupart des gens qui sont devenus sérieux avec n8n, c'est le facteur décisif.

Une machine de 2 Go, un fichier compose, un domaine (ou un tunnel), et vous faites tourner votre propre hub d'automatisation — payable en crypto sans KYC, en ligne en quelques minutes.

Configuration prête à l'emploi : voir VPS pour n8n — l'offre recommandée et un déploiement crypto d'une minute.