Comment Exécuter n8n Sur Ton Propre Serveur

Tu as vu ta facture Zapier grimper pendant six mois.

Chaque nouveau workflow ajoute une ligne de plus, et chaque étape d’action réussie compte comme une tâche. La facture mensuelle coûte désormais plus que ton outil de gestion de projet.

Tu commences à chercher des alternatives sur Google et tu tombes sur n8n, une plateforme d’automatisation que tu peux auto-héberger sur ton propre serveur privé virtuel (VPS) pour le prix d’un petit serveur.

Aucun quota d’exécutions. Pas de tarification à la tâche. Pas de factures surprises quand tes automatisations décollent.

Et oui, nous te guidons tout au long du processus, commande par commande, d’un serveur Ubuntu vierge jusqu’à une instance opérationnelle avec HTTPS, des sauvegardes et une restauration testée.

Qu’est-Ce Que n8n Et Pourquoi Les Gens L’Auto-Hébergent-Ils ?

n8n est une plateforme d’automatisation de workflows qui te permet de connecter des applications, de transférer des données entre des services et de construire des automatisations complexes grâce à un éditeur visuel. Vois-le comme le moteur derrière « quand X se produit, fais Y et Z », sauf que tu glisses des nœuds et traces des connexions au lieu d’écrire du code.

Le projet a dépassé les 200 000 étoiles sur GitHub, et son image Docker officielle affiche plus de 100 millions de téléchargements. Beaucoup de serveurs font tourner n8n.

La plateforme est distribuée sous une Sustainable Use License, qu’il vaut mieux comprendre avant de s’engager. Ce n’est pas de l’open source traditionnel (n8n lui-même dit ne pas utiliser ce terme, car les licences approuvées par l’OSI ne peuvent pas restreindre l’usage), mais ce n’est pas non plus verrouillé. Tu peux l’utiliser librement pour les besoins internes de ton entreprise. Tu ne peux pas vendre un produit, un service ou un module dont la valeur provient entièrement ou en grande partie des fonctionnalités de n8n.

« En pratique, cela signifie que tout usage est autorisé, sauf si tu vends un produit, un service ou un module dont la valeur provient entièrement ou en grande partie des fonctionnalités de n8n. » — FAQ sur la licence de n8n

Les gens auto-hébergent n8n parce que l’équation économique s’inverse dès que tu dépasses un usage basique. n8n Cloud commence à 20 €/mois (facturés annuellement) pour 2 500 exécutions avec le plan Starter, et si tu gères un volume réel, ces limites se font vite sentir.

Sur ton propre VPS ? Aucun quota d’exécutions, le contrôle des données que stocke ton instance n8n, et aucune facture de licence ni d’exécution n8n, même si ton serveur, ton domaine, le stockage des sauvegardes et l’administration ont toujours un coût. Les exécutions elles-mêmes ne coûtent rien de plus ; un volume plus important consomme davantage de mémoire et de stockage, ce qui relève du dimensionnement (abordé plus bas), pas de la facturation.

Que Peux-Tu Automatiser Avec n8n ?

Les plus de 400 intégrations de n8n couvrent un large éventail, et les nœuds créés par la communauté allongent encore la liste. n8n est aussi l’une des nombreuses alternatives auto-hébergées aux outils SaaS ; la même logique s’applique à tout, du CRM à la gestion de projet.

Quelques configurations courantes :

• CRM et routage des leads. Synchronise les contacts entre ton CRM, ta plateforme d’e-mailing et Slack quand de nouveaux leads arrivent.
• Workflows déclenchés par webhook. Réagis en temps réel aux événements provenant de processeurs de paiement, de soumissions de formulaires ou de commits GitHub.
• Automatisation des pipelines de données. Récupère des données depuis des API, transforme-les et envoie-les selon un calendrier vers des bases de données ou des feuilles de calcul.
• Chaînes d’agents IA. Connecte des LLM à tes outils internes pour construire des assistants IA personnalisés capables de rechercher, de résumer et d’agir sur tes données.

(C’est avec ce dernier cas que les ressources de ton serveur commencent à compter. Plus de détails dans la section sur les spécifications.)

Combien Coûte L’Auto-Hébergement De n8n ?

L’édition Community auto-hébergée n’entraîne aucuns frais de licence ni d’exécution n8n pour les usages autorisés. Ton coût total comprend le serveur, plus l’éventuel domaine, le stockage des sauvegardes et le temps d’administration. L’analyse des coûts 2026 d’ExpressTech estime un VPS brut avec Docker à 4 à 5 $ par mois, un VPS géré avec Coolify à 5 à 8 $, et les plateformes n8n gérées en un clic à 3 à 7 $.

Ce sont les estimations d’hébergement tierces d’ExpressTech. Pour un chiffre de première main : le plan que nous recommandons plus bas, DreamHost VPS Hosting Stack 4, coûte, en date d’août 2026, 8,99 $/mois pendant les 3 premiers mois en facturation mensuelle et se renouvelle automatiquement à 15,99 $/mois ensuite, la totalité de la période plus les taxes étant facturée au paiement (les tarifs actuels figurent sur la page VPS n8n).

Compare cela aux plans hébergés et sous licence de n8n, tels qu’indiqués sur la page de tarifs de n8n. n8n affiche ses prix en euros, et voici les tarifs en facturation annuelle :

Plan	Coût mensuel	Limite d’exécutions
n8n Cloud Starter	20 €/mois	2 500 exécutions
n8n Cloud Pro	50 €/mois	10 000 exécutions
n8n Business (licence auto-hébergée)	667 €/mois	40 000 exécutions
Édition Community auto-hébergée sur un VPS	Aucuns frais de licence ni d’exécution n8n pour les usages autorisés ; des coûts de VPS, de domaine, de stockage des sauvegardes et d’administration peuvent s’appliquer	Aucun quota

L’écart se creuse quand tu prends en compte la manière dont chaque plateforme comptabilise l’utilisation. n8n facture une exécution par lancement de workflow, « quelle que soit sa complexité », et chaque plan inclut un nombre illimité d’étapes. Zapier, en revanche, compte chaque étape d’action réussie comme une tâche.

Ainsi, un workflow de quatre étapes d’action exécuté 100 fois par jour représente 3 000 exécutions n8n par mois, mais environ 12 000 tâches Zapier.

Les chiffres réels le confirment. L’analyse d’ExpressTech prend l’exemple de quatre workflows totalisant environ 7 000 exécutions par mois : cette charge dépasse n8n Cloud Starter et nécessite le niveau Pro (indiqué par ExpressTech à 60 $/mois en facturation mensuelle), tandis qu’une installation auto-hébergée à 3 à 7 $/mois l’exécute sans limites, une différence qu’ils chiffrent à 636 à 684 $ par an.

Les Coûts Cachés De L’Auto-Hébergement

Les économies en dollars sont réelles. Mais l’auto-hébergement n’est pas gratuit dans tous les sens du terme.

Voici ce que cela te coûte :

Ton temps. Le temps de maintenance varie selon ta charge de travail et ton expérience de l’exploitation, mais tu seras responsable des mises à jour, des sauvegardes, de la surveillance et des tests de restauration. Les configurations plus lourdes avec des automatisations reposant sur l’IA en demanderont davantage.

La friction de la configuration OAuth. Connecter des services comme Google Workspace ou Microsoft 365 nécessite de configurer des identifiants OAuth. Prévois du temps de configuration supplémentaire pour chaque fournisseur et suis la documentation de sa console. (Si tu as déjà regardé un indicateur de chargement tourner pendant qu’un écran de consentement décide s’il fait confiance à ton application, tu connais la sensation.)

Un TLS auquel tu fais confiance, mais que tu vérifies. Le proxy Caddy de l’installation ci-dessous obtient et renouvelle automatiquement un certificat reconnu publiquement, via un émetteur comme Let’s Encrypt ou ZeroSSL. Automatique ne veut pas dire infaillible : après des modifications du DNS ou du proxy, confirme que le certificat se renouvelle toujours.

Une phase d’apprentissage si tu débutes avec les serveurs. Le guide ci-dessous suppose que tu sais te connecter en SSH à un serveur, modifier un fichier et exécuter des commandes. Si tu ne l’as jamais fait, prévois du temps d’apprentissage en plus du déploiement lui-même.

De Quelles Spécifications Serveur n8n A-t-il Besoin ?

n8n est en soi léger. Ce qui se rapproche le plus d’un dimensionnement officiel, ce sont les chiffres d’exemple de la documentation de déploiement OEM de n8n, que n8n présente comme « uniquement à titre indicatif », basés sur n8n Cloud : une plage de mémoire de 320 Mo à 2 Go, une base de données sur SSD de 512 Mo à 4 Go, et environ 100 Mo de mémoire pour une instance au repos. Comme allocation de départ prudente plutôt que comme minimum officiel de n8n, prévois 2 Go pour les tests et 4 Go quand tu ajoutes PostgreSQL et des workflows de production. Surveille des workflows représentatifs et ajoute de la mémoire quand une pression durable apparaît.

N’oublie pas non plus que n8n est généralement plus limité par la mémoire que par le CPU. La documentation de n8n le dit clairement : la plateforme « n’est pas gourmande en CPU », et « en général, les besoins en mémoire priment sur les besoins en CPU ». Ce qui fait grimper la consommation de mémoire, ce sont tes workflows : le volume de données, les nœuds Code (qui copient les données avant et après le traitement) et les gros fichiers binaires.

Voici notre petit calcul sur un coin de table pour dimensionner la marge :

Dimensionne en fonction de la concurrence des exécutions et du volume de données que traite chaque workflow, puis surveille l’utilisation de la mémoire sous une charge de travail représentative. Les nœuds Code et les grosses charges binaires peuvent augmenter les besoins en mémoire, alors garde de la marge et fais évoluer le VPS quand la surveillance révèle une pression durable.

Tu découvres l’hébergement VPS ? Commence par le guide du débutant sur les VPS de DreamHost pour comprendre les bases avant de dimensionner ton serveur.

Quel VPS Choisir Pour n8n Auto-Hébergé ?

n8n ne publie pas de paliers de RAM fixes selon la charge de travail. Dimensionne en fonction de la concurrence des exécutions et du volume de données, garde de la marge pour Docker et PostgreSQL, puis surveille des workflows représentatifs et fais évoluer le serveur quand la pression sur la mémoire est durable.

Voici donc comment nous ferions correspondre cela aux plans DreamHost :

Plan	Spécifications	Quand le choisir
DreamHost VPS Hosting Stack 4	4 Go de RAM, 2 vCPU, 75 Go de SSD NVMe	Une allocation de départ de 4 Go, non testée par des benchmarks mais prudente, pour un premier serveur n8n.
DreamHost VPS Hosting Stack 8	8 Go de RAM, 2 vCPU, 150 Go de SSD NVMe	L’option de 8 Go pour une marge de mémoire supplémentaire quand la surveillance révèle une pression durable, avec deux fois plus de RAM et de stockage.
DreamHost VPS Hosting Stack 16	16 Go de RAM, 4 vCPU, 250 Go de SSD NVMe	L’option de 16 Go pour davantage de concurrence, des volumes de données plus importants ou l’ajout de workers Redis en mode file d’attente.

Quelques spécifications méritent ton attention au-delà de la RAM : n8n cite le stockage SSD parmi les bonnes pratiques pour la base de données. Les besoins en mémoire dépassent généralement les besoins en CPU, mais le véritable goulot d’étranglement dépend de la concurrence des workflows, du volume de données et des nœuds que tu utilises. La bande passante non mesurée compte si tu gères des charges de travail riches en webhooks avec un flux constant de requêtes HTTP entrantes.

Choisis un environnement d’hébergement qui te permet d’exécuter Docker et de configurer la base de données, le réseau, le stockage persistant et le proxy inverse. L’hébergement mutualisé classique n’offre généralement pas ce niveau de contrôle.

Les plans d’hébergement VPS de DreamHost cochent les cases essentielles (stockage SSD NVMe, bande passante non mesurée, accès root complet et prise en charge de Docker), et n8n figure dans la bibliothèque d’applications en un clic, préinstallé avec PostgreSQL et le SSL automatique si tu préfères éviter l’installation manuelle ci-dessous.

Notre choix pour un premier serveur n8n est Stack 4. En août 2026, il coûte 8,99 $/mois pendant les 3 premiers mois en facturation mensuelle et se renouvelle automatiquement à 15,99 $/mois, la totalité de la période plus les taxes étant facturée au paiement ; la page VPS n8n affiche toujours les tarifs actuels. C’est ce prix de renouvellement qu’il est honnête de comparer aux 20 €/mois de n8n Cloud Starter.

Oh, et une chose à garder dans un coin de ta tête pour plus tard : à mesure que ton utilisation augmente, n8n prend en charge le mode file d’attente, une architecture de mise à l’échelle qui sépare l’instance principale (interface, déclencheurs, webhooks) de l’exécution des workflows, en utilisant Redis comme courtier de messages et des instances worker pour exécuter les tâches. La documentation de n8n le présente comme le mode qui « offre la meilleure évolutivité ».

Comment Configurer n8n Sur Un VPS ?

Déployer une instance n8n auto-hébergée prend 11 étapes : le DNS, le renforcement de SSH, un pare-feu, Docker, les secrets, un fichier Compose pour la pile de trois conteneurs (n8n, PostgreSQL et Caddy), le Caddyfile, le lancement et la vérification, les mises à jour, les sauvegardes et un test de restauration. Caddy est notre proxy inverse : le serveur qui se place entre Internet et ton application, et gère le TLS et le routage. Nous fournissons les commandes pour le déploiement principal et pour un test manuel de sauvegarde et de restauration.

Les commandes ciblent Ubuntu 22.04 ou plus récent, mais remplace le domaine d’exemple, les valeurs secrètes, le nom du volume et les noms des fichiers de sauvegarde datés là où c’est indiqué. La documentation Docker Compose de n8n couvre le même terrain avec un proxy Traefik si tu préfères suivre le modèle de n8n.

Ce Dont Tu Auras Besoin Avant De Commencer

• Un VPS avec accès root sous Ubuntu 22.04 ou plus récent, avec au moins 2 Go de RAM (4 Go est notre recommandation prudente pour la production)
• Un nom de domaine que tu peux faire pointer vers l’adresse IP de ton serveur (pour le TLS et l’accès à l’éditeur n8n)
• Une aisance de base avec le terminal : tu dois savoir te connecter en SSH à un serveur, modifier un fichier et exécuter des commandes

Encore un prérequis qui ne figure sur aucune liste officielle : sauvegarde ta N8N_ENCRYPTION_KEY dès que tu la génères. C’est pourquoi l’étape 5 te fait créer la clé avec openssl rand -hex 32 avant le premier lancement, au lieu de laisser n8n en générer une sans rien dire. Cette clé chiffre tous tes identifiants stockés, y compris chaque clé API, jeton OAuth et mot de passe de base de données que tu as connecté. La documentation Docker de n8n avertit que si la clé est introuvable au démarrage, n8n en crée une nouvelle et les identifiants existants ne peuvent plus être déchiffrés, ce qui veut dire que tu reconstruis chaque intégration depuis le début (et que tu regrettes tes choix de vie). Copie-la dans un endroit sûr, séparé de tes sauvegardes de base de données.

Si ton fournisseur ne t’a donné qu’un accès root, crée d’abord un utilisateur de déploiement, depuis la console du fournisseur ou une session SSH en root, avant les commandes SSH locales de l’étape 2 :

adduser deploy
usermod -aG sudo deploy

Tout ce qui suit s’exécute avec cet utilisateur, avec sudo si nécessaire.

Étape 1 : Faire pointer ton domaine vers le serveur

Crée un enregistrement DNS A pour un sous-domaine dédié (n8n.example.com dans tout ce guide) pointant vers l’adresse IP de ton serveur, exactement comme le décrit le guide Docker Compose de n8n. Fais-le en premier : si le DNS ne s’est pas propagé, Caddy ne peut pas obtenir de certificat, et ton navigateur risque d’afficher une erreur de sécurité au lieu de l’éditeur n8n.

Étape 2 : Renforcer l’accès SSH

Sur ta machine locale, génère une paire de clés (la documentation OpenSSH d’Ubuntu recommande ed25519) et copie-la sur le serveur :

ssh-keygen -t ed25519
ssh-copy-id deploy@your_server_ip

Vérifie que tu peux te connecter avec la clé. Ensuite, sur le serveur, désactive les connexions par mot de passe et en root, et vérifie ce que sshd appliquera réellement :

sudo tee /etc/ssh/sshd_config.d/00-hardening.conf > /dev/null <<'EOF'
PasswordAuthentication no
PermitRootLogin no
EOF
sudo sshd -t
sudo sshd -T | grep -E '^(passwordauthentication|permitrootlogin) '

Le préfixe 00- est délibéré. OpenSSH utilise la première valeur qu’il lit pour chaque mot-clé, selon le manuel de sshd_config, et les images de serveurs cloud incluent souvent des fichiers complémentaires antérieurs dans le même répertoire (cloud-init, par exemple, écrit ses paramètres SSH dans 50-cloud-init.conf). Nomme ton fichier 99-hardening.conf et l’un de ces fragments peut l’emporter sans rien dire. sshd -t vérifie que la configuration ne contient pas d’erreurs ; sshd -T affiche les paramètres effectifs une fois tous les fichiers fusionnés. Vérifie que la dernière commande affiche passwordauthentication no et permitrootlogin no avant d’aller plus loin. Puis redémarre sshd :

sudo systemctl restart ssh.service

La documentation d’Ubuntu avertit qu’une mauvaise configuration de sshd sur un serveur distant peut te bloquer l’accès. Garde ta session actuelle ouverte et teste une nouvelle connexion dans un second terminal avant de fermer quoi que ce soit.

Étape 3 : Activer le pare-feu

Ubuntu est livré avec UFW (Uncomplicated Firewall) désactivé par défaut. Autorise SSH avant de l’activer, pour que le pare-feu ne puisse pas couper ta propre session :

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw --force enable
sudo ufw status

Trois ports, rien d’autre. Un avertissement propre à Docker, tiré de la documentation d’installation de Docker : les ports que Docker publie sur l’hôte contournent entièrement les règles UFW. C’est pourquoi le fichier Compose de l’étape 6 ne publie des ports sur l’hôte que pour Caddy : 80 et 443 sont les seuls ports de conteneur publiés par Compose (SSH sur le port 22 est aussi ouvert), et n8n et PostgreSQL n’ont aucun port publié sur l’hôte.

Étape 4 : Installer Docker et Docker Compose

Installe Docker Engine depuis le dépôt apt officiel de Docker, et non avec le script pratique get.docker.com, que la documentation de Docker ne recommande que pour les tests et le développement. D’abord, les prérequis et la clé de signature de Docker :

sudo apt update
sudo apt install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

Ensuite, enregistre le dépôt lui-même. Cette commande écrit le fichier de dépôt tiré du guide d’installation de Docker pour Ubuntu, en renseignant automatiquement ta version d’Ubuntu :

sudo tee /etc/apt/sources.list.d/docker.sources > /dev/null <<EOF
Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}")
Components: stable
Signed-By: /etc/apt/keyrings/docker.asc
EOF

Puis installe et vérifie :

sudo apt update
sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
sudo docker run hello-world

Si hello-world affiche son message de confirmation, Docker et le plugin Compose sont prêts.

Étape 5 : Créer le répertoire du projet et les secrets

Crée le répertoire du projet, puis génère ta clé de chiffrement ; ne laisse pas n8n en inventer une sans rien dire au premier démarrage :

sudo mkdir -p /opt/n8n-compose
cd /opt/n8n-compose
openssl rand -hex 32

Copie immédiatement la sortie dans un endroit sûr, hors du serveur. Ensuite, place-la, avec un mot de passe de base de données robuste, dans un fichier .env protégé à côté de ton fichier compose (Docker Compose le lit automatiquement). Remplace les deux valeurs d’exemple par les tiennes :

sudo tee /opt/n8n-compose/.env > /dev/null <<'EOF'
POSTGRES_PASSWORD=choose_a_strong_password
N8N_ENCRYPTION_KEY=paste_the_64_character_key_you_just_generated
EOF
sudo chmod 600 /opt/n8n-compose/.env

Le chmod 600 est important : ce fichier contient des secrets, donc seul son propriétaire (root) doit pouvoir le lire. Dans le fichier compose, N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true applique la même idée à l’intérieur du conteneur : selon la référence des variables de sécurité de n8n, il fait en sorte que n8n tente d’appliquer les permissions 0600 à son propre fichier de paramètres.

Étape 6 : Écrire le fichier Docker Compose

Crée /opt/n8n-compose/docker-compose.yml (par exemple avec sudo nano /opt/n8n-compose/docker-compose.yml) et colle ce qui suit, en remplaçant n8n.example.com par ton propre domaine dans les deux lignes d’URL et en définissant ton fuseau horaire :

services:
  caddy:
    image: caddy:2
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - caddy_data:/data
      - caddy_config:/config

  n8n:
    image: docker.n8n.io/n8nio/n8n:2.36.7
    restart: unless-stopped
    expose:
      - "5678"
    environment:
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_DATABASE=n8n
      - DB_POSTGRESDB_USER=n8n
      - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - N8N_HOST=n8n.example.com
      - N8N_PORT=5678
      - N8N_PROTOCOL=https
      - N8N_WEBHOOK_URL=https://n8n.example.com/
      - N8N_PROXY_HOPS=1
      - N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true
      - GENERIC_TIMEZONE=America/New_York
      - TZ=America/New_York
      - EXECUTIONS_DATA_MAX_AGE=168
    depends_on:
      postgres:
        condition: service_healthy
    volumes:
      - n8n_data:/home/node/.n8n

  postgres:
    image: postgres:18
    restart: unless-stopped
    environment:
      - POSTGRES_USER=n8n
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
      - POSTGRES_DB=n8n
      - PGDATA=/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U n8n -d n8n"]
      interval: 5s
      timeout: 5s
      retries: 10
    volumes:
      - postgres_data:/var/lib/postgresql/data

volumes:
  caddy_data:
  caddy_config:
  n8n_data:
  postgres_data:

Cinq détails y méritent leur place :

• L’image est épinglée à une version précise (2.36.7 est la version stable actuelle au moment où nous écrivons, selon la documentation d’installation de n8n), donc les mises à niveau n’ont lieu que lorsque tu le décides.
• n8n ne publie aucun port sur l’hôte. Il est joignable par les conteneurs du réseau Compose, y compris Caddy, mais pas via un port publié sur l’hôte, de sorte que l’éditeur n’est jamais accessible qu’à travers le proxy inverse, jamais directement depuis Internet.
• Le healthcheck oblige n8n à attendre PostgreSQL. Un simple depends_on attend seulement que le conteneur démarre, pas que la base de données accepte les connexions. Le modèle condition: service_healthy vient directement du fichier compose Postgres d’exemple de n8n, qui déploie lui aussi PostgreSQL 18.
• La paire N8N_WEBHOOK_URL / N8N_PROXY_HOPS est importante derrière un proxy. n8n construit normalement les URL de webhook à partir de son protocole, de son hôte et de son port, et la documentation de n8n indique que cela ne fonctionne pas derrière un proxy inverse ; tu définis donc l’URL de webhook manuellement pour que n8n puisse « enregistrer les bonnes URL de webhook auprès des services externes », tu règles N8N_PROXY_HOPS sur 1, et tu t’assures que le proxy transmet les en-têtes X-Forwarded-For, X-Forwarded-Host et X-Forwarded-Proto. (La même page précise que N8N_WEBHOOK_URL remplace l’ancienne WEBHOOK_URL, obsolète depuis n8n 2.35.0.)
• TZ et GENERIC_TIMEZONE ont des rôles différents. Selon la documentation Docker de n8n, GENERIC_TIMEZONE pilote les nœuds de planification comme Schedule, tandis que TZ définit le fuseau horaire système du conteneur (ce que renvoient des commandes comme date). Donne-leur la même valeur.

(Commence avec PostgreSQL dès le premier jour. n8n utilise SQLite par défaut, ce qui fonctionne pour les tests, mais les modèles d’hébergement de n8n recommandent PostgreSQL pour la production, et migrer plus tard est douloureux, façon « j’aurais dû faire ça correctement dès le début ».)

Étape 7 : Écrire le Caddyfile

Crée /opt/n8n-compose/Caddyfile avec ton domaine (là encore, remplace n8n.example.com) :

n8n.example.com {
    reverse_proxy n8n:5678
}

C’est toute la configuration du proxy inverse. Selon la documentation HTTPS automatique de Caddy, Caddy obtient et renouvelle automatiquement un certificat reconnu publiquement, via un émetteur comme Let’s Encrypt ou ZeroSSL, et redirige HTTP vers HTTPS, à condition que ton enregistrement DNS A pointe vers le serveur et que les ports 80 et 443 soient ouverts (étapes 1 et 3). Caddy fait aussi partie des proxys inverses des exemples d’hébergement officiels de n8n.

Étape 8 : Lancer et vérifier

cd /opt/n8n-compose
sudo docker compose up -d
sudo docker compose ps

Attends que ps indique que le conteneur postgres est à l’état healthy et que n8n tourne, puis vérifie la porte d’entrée depuis n’importe quelle machine :

curl -fsS -o /dev/null -w '%{http_code}' https://n8n.example.com/

Un code 2xx (ou une redirection 3xx) signifie que Caddy a assuré la terminaison TLS et que n8n a répondu ; si curl se termine plutôt par une erreur, c’est le DNS, le certificat ou les conteneurs qu’il faut examiner (sudo docker compose logs caddy et sudo docker compose logs n8n sont les premiers endroits à vérifier). Ouvre https://n8n.example.com dans un navigateur et crée ton compte propriétaire.

Étape 9 : Mettre à jour n8n de façon réfléchie

n8n publie une nouvelle version mineure presque chaque semaine, et ses instructions de mise à jour te demandent de consulter le journal des changements incompatibles avant de mettre à niveau. Quand tu es prêt : modifie le tag de version dans docker-compose.yml, puis

cd /opt/n8n-compose
sudo docker compose pull
sudo docker compose up -d

Avec un tag épinglé, un simple pull ne change rien : c’est toi qui choisis chaque mise à niveau en modifiant le tag, et c’est tout l’intérêt de l’épinglage. Lance une sauvegarde (étape 10) avant les mises à jour de version majeure.

Étape 10 : Planifier les sauvegardes

Trois éléments sont indispensables pour une restauration exploitable : la base de données PostgreSQL, le volume n8n_data et le fichier .env qui fournit la N8N_ENCRYPTION_KEY. La documentation Docker de n8n indique explicitement que, même si tu utilises PostgreSQL, le dossier /home/node/.n8n (notre volume n8n_data) contient toujours des données essentielles, y compris les éléments de la clé de chiffrement. Sauvegarde les trois, et conserve docker-compose.yml et Caddyfile pour pouvoir reconstruire la pile. Le script ci-dessous s’occupe de la base de données et du volume ; la copie des fichiers de configuration hors de l’hôte vient juste après. Crée le script sous forme de fichier appartenant à root :

sudo tee /opt/n8n-compose/backup.sh > /dev/null <<'EOF'
#!/bin/bash
set -euo pipefail
cd /opt/n8n-compose
STAMP=$(date +%Y-%m-%d)
mkdir -p /opt/n8n-backups
docker compose exec -T postgres pg_dump -U n8n -d n8n > "/opt/n8n-backups/n8n-db-${STAMP}.sql"
docker run --rm -v n8n-compose_n8n_data:/data -v /opt/n8n-backups:/backup alpine \
  tar czf "/backup/n8n-data-${STAMP}.tar.gz" -C /data .
find /opt/n8n-backups -name 'n8n-db-*.sql' -mtime +30 -delete
find /opt/n8n-backups -name 'n8n-data-*.tar.gz' -mtime +30 -delete
EOF
sudo chmod 700 /opt/n8n-compose/backup.sh
sudo /opt/n8n-compose/backup.sh

Remarques sur le script : n8n-compose_n8n_data est le nom de volume que Compose crée pour un répertoire de projet nommé n8n-compose ; vérifie le tien avec sudo docker volume ls et ajuste-le s’il diffère. Les deux lignes find conservent 30 jours de sauvegardes ; définis une autre durée de rétention selon ton stockage et tes besoins de récupération.

Planifie-le depuis la crontab de root. Le cron de root ne doit jamais exécuter qu’un script appartenant à root (chmod 700, avec le .env en 600), jamais un fichier qu’un autre utilisateur peut modifier. Exécute sudo crontab -e et ajoute une ligne pour une exécution quotidienne à 3 h du matin :

0 3 * * * /opt/n8n-compose/backup.sh

Le script sauvegarde la base de données PostgreSQL et le volume n8n_data de façon planifiée. Copie le .env (qui contient ta clé de chiffrement) ainsi que les fichiers Compose et Caddy hors de l’hôte dès maintenant, puis à chaque modification. Sur le serveur, crée une archive temporaire protégée :

sudo tar -C /opt/n8n-compose -czf /home/deploy/n8n-config.tar.gz .env docker-compose.yml Caddyfile
sudo chown deploy:deploy /home/deploy/n8n-config.tar.gz
chmod 600 /home/deploy/n8n-config.tar.gz

Ensuite, depuis ta machine locale, récupère l’archive de configuration avec les sauvegardes, puis supprime la copie temporaire sur le serveur :

scp deploy@your_server_ip:/home/deploy/n8n-config.tar.gz .
scp -r deploy@your_server_ip:/opt/n8n-backups .
ssh deploy@your_server_ip 'rm /home/deploy/n8n-config.tar.gz'

Une sauvegarde qui n’existe que sur le serveur qu’elle protège disparaît avec lui.

Étape 11 : Tester une restauration sur un VPS jetable

Cette procédure de sauvegarde et de restauration te permet de vérifier que tes sauvegardes sont exploitables. Teste cette restauration sur un nouveau VPS jetable, jamais sur ton serveur de production. Provisionne un serveur jetable, répètes-y l’étape 4 (Docker), et copie tes fichiers de projet (docker-compose.yml, Caddyfile, .env) et tes dernières sauvegardes datées aux mêmes emplacements.

D’abord, change le nom d’hôte : mets un nom d’hôte de test (par exemple n8n-restore-test.example.com, avec un enregistrement A pointant vers le VPS jetable) dans N8N_HOST, N8N_WEBHOOK_URL et le Caddyfile. Ensuite, en remplaçant les noms de fichiers datés par les tiens :

cd /opt/n8n-compose
sudo docker compose create
sudo docker run --rm -v n8n-compose_n8n_data:/data -v /opt/n8n-backups:/backup alpine \
  sh -c "cd /data && tar xzf /backup/n8n-data-2026-08-25.tar.gz"
sudo docker compose up -d --wait postgres
sudo docker compose exec -T postgres psql -U n8n -d n8n < /opt/n8n-backups/n8n-db-2026-08-25.sql
sudo docker compose run --rm n8n unpublish:workflow --all
sudo docker compose up -d

La ligne unpublish:workflow --all utilise la Server CLI intégrée de n8n pour dépublier chaque workflow restauré avant le démarrage de l’instance, afin que les planifications et déclencheurs restaurés ne se lancent pas contre tes systèmes de production depuis la machine de test. Termine par la même vérification curl qu’à l’étape 8, sur le nom d’hôte de test.

Sois honnête avec toi-même sur ce que signifie une vérification au vert : elle confirme que la base de données et le volume ont été restaurés et que la pile démarre proprement. Elle ne fait pas tourner tes workflows dans l’éditeur, alors connecte-toi à l’instance de test et contrôle ponctuellement ceux que tu ne peux pas te permettre de perdre.

Comment Sécuriser Une Instance n8n Auto-Hébergée ?

Une instance n8n auto-hébergée est aussi sécurisée que le serveur sur lequel elle tourne, et c’est toi qui contrôles ce serveur.

La sécurité repose sur six éléments. Aucun d’eux n’est compliqué individuellement, mais en négliger un seul crée une véritable faille. L’installation ci-dessus met déjà en œuvre les trois premiers.

1. HTTPS via un proxy inverse. N’accède jamais à l’éditeur n8n en HTTP simple. La configuration Caddy de l’étape 7 obtient et renouvelle automatiquement un certificat reconnu publiquement, via un émetteur comme Let’s Encrypt ou ZeroSSL, et redirige HTTP vers HTTPS.
2. Verrouillage par pare-feu. UFW n’autorise que SSH (22), HTTP (80) et HTTPS (443). N’expose jamais le port par défaut de n8n, 5678, directement sur Internet. Le fichier compose ci-dessus l’impose en ne donnant à n8n aucun port publié sur l’hôte, de sorte que seuls les conteneurs du réseau Compose peuvent l’atteindre.
3. Isolation du réseau Docker. PostgreSQL et n8n communiquent via le réseau Compose interne. Le port de ta base de données n’est jamais publié sur l’hôte, il n’est donc jamais accessible depuis l’extérieur.
4. Authentification forte. Utilise un mot de passe propriétaire robuste et active l’authentification à deux facteurs ; le guide de sécurité de n8n cite la 2FA parmi les protections recommandées pour les instances auto-hébergées.
5. Mises à jour régulières. Modifie le tag de version dans ton fichier compose, puis fais un pull et redémarre (étape 9). Lis d’abord le journal des modifications, car les mises à jour de n8n peuvent inclure des changements incompatibles.
6. Des sauvegardes que tu as réellement restaurées. Les étapes 10 et 11 te donnent la planification et le test. Une sauvegarde que tu n’as jamais testée est un espoir, pas un plan.

Encore une chose à surveiller qui ne relève pas strictement de la sécurité, mais qui fera une grande différence. Par défaut, n8n enregistre dans sa base de données l’entrée et la sortie de chaque exécution. L’élagage est activé par défaut : n8n supprime les exécutions de plus de 336 heures (14 jours), ou dès que tu dépasses 10 000 exécutions stockées. Une instance très sollicitée peut malgré tout faire gonfler PostgreSQL entre-temps.

Si tes workflows sont bavards, resserre ces réglages : définis EXECUTIONS_DATA_MAX_AGE=168 pour élaguer les données d’exécution de plus de sept jours (le fichier compose ci-dessus le fait déjà), ou ne stocke plus du tout les exécutions réussies avec EXECUTIONS_DATA_SAVE_ON_SUCCESS=none.

Quels Sont Les Compromis Entre L’Auto-Hébergement Et n8n Cloud ?

Auto-héberger n8n te donne une instance sans quota d’exécutions et le contrôle des données qu’elle stocke, pour le prix d’un petit VPS plus ta propre administration. n8n Cloud te dispense de toute maintenance de serveur, avec des plafonds d’exécutions selon le palier. Tout dépend de ce que tu préfères : posséder ton infrastructure d’automatisation ou payer quelqu’un d’autre pour la gérer.

La documentation de n8n le dit ainsi : « n8n recommande l’auto-hébergement aux utilisateurs experts. Les erreurs peuvent entraîner une perte de données, des problèmes de sécurité et des interruptions de service. Si tu n’as pas l’expérience de la gestion de serveurs, n8n recommande n8n Cloud. »

Voici comment les deux options se comparent :

Facteur	Auto-hébergé	n8n Cloud
Coût mensuel	Ta facture VPS plus l’éventuel domaine, le stockage des sauvegardes et les coûts d’administration (DreamHost Stack 4 : 8,99 $/mois pendant 3 mois, puis 15,99 $/mois, tarifs d’août 2026 ; estimations tierces 2026 d’ExpressTech : 4 à 8 $/mois)	20 à 50 € (facturés annuellement), selon le palier
Exécutions	Aucun quota ; la capacité dépend des ressources de ton serveur	2 500 (Starter) ou 10 000 (Pro)
Installation	Le guide en 11 étapes ci-dessus	Quelques minutes
Maintenance	Les mises à jour, les sauvegardes et la surveillance sont à ta charge	Gérée par n8n
Emplacement des données	Ton serveur	Infrastructure de n8n
Mises à jour	Manuelles (modifier le tag, pull, redémarrage)	Automatiques
TLS	Caddy obtient et renouvelle automatiquement les certificats (émetteur comme Let’s Encrypt ou ZeroSSL)	Géré pour toi
Mise à l’échelle	Ajouter de la RAM, ou utiliser le mode file d’attente avec des workers Redis	Passer à un palier supérieur

Il existe aussi un juste milieu à connaître. Des plateformes gérées comme PikaPods (environ 3,80 $/mois) et Elestio (environ 17 $/mois, selon la comparaison d’ExpressTech) font tourner n8n auto-hébergé sans que tu aies à gérer le serveur toi-même. Ces services peuvent réduire le travail d’administration du serveur, mais vérifie qui s’occupe des mises à jour de n8n, des sauvegardes, de la surveillance et de la sécurité.

Mais voici la vision d’ensemble. Sur n’importe quel plan hébergé, ta capacité d’exécution est un palier de facturation, et c’est la plateforme qui fixe les paliers. Les prix, les quotas et les fonctionnalités peuvent changer autour des workflows que tu as déjà construits.

Avec l’auto-hébergement, l’instance et les données qu’elle stocke se trouvent sur une infrastructure que tu contrôles (les services connectés reçoivent toujours ce que tes workflows leur envoient). Contrôle total, responsabilité totale.

Prendre La Décision Finale

L’auto-hébergement est logique quand trois éléments s’alignent :

1. Tu exécutes suffisamment d’automatisations pour que les plafonds d’exécutions du cloud deviennent contraignants
2. Tu veux que tes données de workflow soient sur une infrastructure que tu contrôles
3. Toi (ou quelqu’un de ton équipe), tu es prêt à prendre en charge les mises à jour, les sauvegardes et la surveillance

Sinon, n8n Cloud est un choix raisonnable. Payer le plan Starter pour ne jamais avoir à penser aux logs Docker est un échange équitable, surtout pour une petite équipe qui veut simplement que ses automatisations fonctionnent.

Mais une fois que tu es prêt à franchir le seuil de l’auto-hébergement, les calculs deviennent vite décisifs. Un VPS de 4 Go est un point de départ pratique, bien que non testé par des benchmarks ; la capacité en production dépend de la concurrence, du volume de données et des nœuds que tu utilises, alors surveille l’instance et fais-la évoluer à mesure que la demande augmente. Commence petit, monte en gamme à mesure que tes workflows se développent, et garde le contrôle total de ta pile.

Cette dernière partie compte plus qu’il n’y paraît. Tu peux toujours passer à un serveur plus puissant. Il est bien plus difficile de te dépêtrer d’une plateforme SaaS une fois qu’elle a modifié ses tarifs autour des workflows que tu as déjà construits.

Questions Fréquentes Sur L’Auto-Hébergement De n8n

n8n est-il vraiment gratuit à auto-héberger ?

Le logiciel n8n est gratuit à exécuter sur ton propre serveur sous la Sustainable Use License. L’édition Community auto-hébergée (la version standard que n8n publie sur GitHub) n’entraîne aucuns frais de licence ni d’exécution n8n pour les usages autorisés, comme l’automatisation interne de ton entreprise. La partie « gratuite » concerne le logiciel ; tu paieras quand même ton serveur, ainsi que l’éventuel domaine, le stockage des sauvegardes et le temps d’administration.

La licence interdit de vendre un produit, un service ou un module dont la valeur provient entièrement ou en grande partie des fonctionnalités de n8n. Consulte la FAQ sur la licence de n8n si ton usage prévu consiste à proposer à des clients des fonctionnalités reposant sur n8n.

Quelles sont les exigences système minimales pour n8n ?

n8n publie un dimensionnement d’exemple plutôt qu’un minimum strict, et présente ces chiffres comme indicatifs (ils proviennent de sa documentation de déploiement OEM) : environ 100 Mo de mémoire au repos, une plage de mémoire d’exemple de 320 Mo à 2 Go, et une base de données sur SSD de 512 Mo à 4 Go. Comme allocation de départ prudente plutôt que comme minimum officiel de n8n, prévois 2 Go pour les tests et 4 Go quand tu ajoutes PostgreSQL et des workflows de production, puis surveille l’instance et ajoute de la mémoire quand une pression durable apparaît.

Le plan DreamHost VPS Hosting Stack 4 offre 4 Go de RAM avec un stockage SSD NVMe et un accès root complet pour exécuter des applications auto-hébergées comme n8n. Consulte les plans d’hébergement VPS pour plus de détails.

Utilise PostgreSQL plutôt que SQLite en production, et privilégie le stockage SSD, car n8n le cite parmi les bonnes pratiques pour la base de données.

Puis-je exécuter n8n en local plutôt que sur un VPS ?

Oui, une seule commande Docker lance n8n sur ta propre machine, et c’est un excellent moyen de tester des workflows avant de t’engager sur un serveur. Le hic, ce sont les webhooks : les workflows déclenchés par des services externes ont besoin que ton instance soit joignable depuis Internet, ce qui n’est pas le cas par défaut d’un ordinateur portable derrière une box domestique. La redirection de ports, les VPN et les tunnels permettent de contourner ce problème, chacun avec ses propres compromis en matière de configuration et de sécurité.

n8n propose un service de tunnel pour relayer les webhooks vers une instance locale, mais sa documentation Docker dit sans détour que le tunnel est « uniquement destiné au développement et aux tests en local » et ne doit pas être utilisé en production. Pour tout ce qui tourne en continu, utilise un VPS.

Puis-je migrer de Zapier à n8n ?

Ne t’attends pas à une importation en un clic. Prévois de reconstruire tes workflows dans l’éditeur visuel de n8n plutôt que de les importer depuis Zapier.

La bonne nouvelle : n8n propose plus de 400 intégrations, mais vérifie chaque application, déclencheur et action qu’utilisent tes workflows actuels avant de planifier la migration. Les workflows simples se reconstruisent rapidement ; les séquences complexes en plusieurs étapes prennent plus de temps.

Comment mettre à jour une instance n8n auto-hébergée ?

Modifie le tag de version dans ton docker-compose.yml pour indiquer la version souhaitée, puis exécute docker compose pull suivi de docker compose up -d. Avec un tag épinglé comme docker.n8n.io/n8nio/n8n:2.36.7, un simple pull ne change rien : c’est toi qui choisis chaque mise à niveau en modifiant le tag, et c’est tout l’intérêt de l’épinglage. (Si tu utilises plutôt le tag latest, un pull suivi d’un redémarrage suffit, mais chaque redémarrage devient une mise à niveau surprise.)

Sauvegarde ta base de données PostgreSQL avant les mises à jour de version majeure. Le script de sauvegarde du guide ci-dessus s’en charge, ou exécute directement pg_dump dans le conteneur PostgreSQL.

Les mises à jour imprudentes cassent des choses, et n8n publie une nouvelle version mineure presque chaque semaine. Les instructions de mise à jour de n8n te demandent de consulter le journal des changements incompatibles avant de mettre à niveau, alors lis-le avant de faire un pull. Le redémarrage lui-même est rapide ; c’est la lecture du journal des changements qui mérite ton temps.

n8n auto-hébergé est-il suffisamment sécurisé pour les données d’entreprise ?

L’auto-hébergement te donne le contrôle de l’endroit où n8n stocke les définitions de workflows, les identifiants et les données d’exécution. Cependant, les services connectés reçoivent toujours les données que tes workflows leur envoient, et la sécurisation du serveur reste ta responsabilité.

Suis la liste de contrôle en six points de la section sécurité ci-dessus : HTTPS, pare-feu, isolation Docker, authentification forte avec 2FA, mises à jour régulières et sauvegardes testées. L’équipe n8n maintient un guide de sécurité qui couvre d’autres points à prendre en compte en production, des audits de sécurité à l’authentification à deux facteurs.