n8n auto-hébergé : comment exécuter n8n sur votre propre serveur

Depuis six mois, vous regardez votre facture Zapier grimper.

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

Vous cherchez des alternatives sur Google et tombez sur n8n, une plateforme d'automatisation que vous pouvez auto-héberger sur votre propre serveur privé virtuel (VPS) pour le prix d'un petit serveur.

Aucun quota d'exécution. Aucune facturation à la tâche. Aucune facture surprise quand vos automatisations décollent.

Et oui, nous vous guidons de A à Z, 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 l'auto-héberger ?

n8n est une plateforme d'automatisation de workflows qui vous permet de connecter des applications, de transférer des données entre services et de créer des automatisations complexes grâce à un éditeur visuel. Voyez-la comme le moteur derrière « quand X se produit, faire Y et Z », sauf que vous faites glisser des nœuds et tracez 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 vous engager. Ce n'est pas de l'open source au sens classique (n8n dit lui-même ne pas employer ce terme, puisque les licences approuvées par l'OSI ne peuvent pas restreindre l'usage), mais ce n'est pas verrouillé non plus. Vous pouvez l'utiliser librement pour les besoins internes de votre entreprise. Vous ne pouvez pas vendre un produit, un service ou un module dont la valeur découle entièrement ou substantiellement des fonctionnalités de n8n.

Les gens auto-hébergent n8n parce que l'équation économique s'inverse dès qu'on dépasse un usage basique. n8n Cloud démarre à 20 €/mois (facturation annuelle) pour 2 500 exécutions avec le plan Starter, et dès que votre volume devient conséquent, ces limites se font vite sentir.

Sur votre propre VPS ? Aucun quota d'exécution, le contrôle des données stockées par votre instance n8n et aucune facture de licence ou d'exécution n8n, même si le serveur, le 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 pouvez-vous 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 n'est d'ailleurs qu'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 prospects. Synchronisez les contacts entre votre CRM, votre plateforme d'e-mailing et Slack à l'arrivée de nouveaux prospects.
• Workflows déclenchés par webhook. Réagissez en temps réel aux événements des processeurs de paiement, aux envois de formulaires ou aux commits GitHub.
• Automatisation des pipelines de données. Récupérez des données depuis des API, transformez-les et envoyez-les vers des bases de données ou des tableurs selon un calendrier.
• Chaînes d'agents IA. Connectez des LLM à vos outils internes pour créer des assistants IA sur mesure capables de rechercher, de résumer et d'agir sur vos données.

(C'est avec ce dernier cas que les ressources de votre serveur commencent à compter. Nous y revenons dans la section sur les caractéristiques techniques.)

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

L'édition Community auto-hébergée n'entraîne ni licence ni frais d'exécution n8n pour les usages autorisés. Votre coût total comprend le serveur, ainsi que l'éventuel domaine, le stockage des sauvegardes et le temps d'administration. L'analyse des coûts 2026 d'ExpressTech estime un VPS brut sous 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 des estimations d'hébergement tierces, établies par ExpressTech. Pour un chiffre de première main : le plan que nous recommandons plus bas, l'hébergement VPS DreamHost Stack 4, coûte 8,99 $/mois pendant les 3 premiers mois en facturation mensuelle, puis se renouvelle automatiquement à 15,99 $/mois, en date d'août 2026, la totalité de la période plus les taxes étant facturée au paiement (les tarifs actuels figurent sur la page VPS n8n).

Comparez avec les plans hébergés et sous licence de n8n, tels qu'indiqués sur la page des tarifs de n8n. n8n affiche ses prix en euros, et voici les tarifs en facturation annuelle :

L'écart se creuse quand on tient compte de la façon dont chaque plateforme comptabilise l'usage. n8n facture une exécution par lancement de workflow – regardless of complexity, et tous les plans incluent des étapes illimitées. Zapier, en revanche, compte chaque étape d'action réussie comme une tâche.

Ainsi, un workflow à 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 exige le palier Pro (affiché à 60 $/mois en facturation mensuelle), tandis qu'une installation auto-hébergée à 3–7 $/mois l'exécute sans limite, soit une différence qu'ils estiment à 636–684 $ par an.

Les coûts cachés de l'auto-hébergement

Les économies sont réelles. Mais l'auto-hébergement n'est pas gratuit à tous points de vue.

Voici ce qu'il vous coûte :

Votre temps. Le temps de maintenance varie selon votre charge de travail et votre expérience d'exploitation, mais les mises à jour, les sauvegardes, la surveillance et les tests de restauration vous incombent. Les configurations plus lourdes, avec des automatisations basées sur l'IA, en demanderont davantage.

La configuration OAuth, source de friction. Connecter des services comme Google Workspace ou Microsoft 365 nécessite de configurer des identifiants OAuth. Prévoyez du temps supplémentaire pour chaque fournisseur et suivez la documentation de sa console. (Si vous avez déjà fixé une icône de chargement pendant qu'un écran de consentement décidait s'il faisait confiance à votre application, vous voyez de quoi on parle.)

Un TLS fiable, mais à vérifier. Le proxy Caddy de la configuration ci-dessous obtient et renouvelle automatiquement un certificat reconnu publiquement, auprès d'un émetteur comme Let’s Encrypt ou ZeroSSL. Automatique ne veut pas dire infaillible : après toute modification du DNS ou du proxy, vérifiez que le certificat se renouvelle toujours.

Un temps d'apprentissage si vous débutez avec les serveurs. Le guide ci-dessous suppose que vous savez vous connecter à un serveur en SSH, modifier un fichier et exécuter des commandes. Si vous n'avez jamais fait tout cela, prévoyez du temps d'apprentissage en plus du déploiement lui-même.

De quelles caractéristiques serveur n8n a-t-il besoin ?

n8n est léger en soi. 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 for illustrative purposes only, et qui reposent sur n8n Cloud : une plage 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 inactive. En guise d'allocation de départ prudente, et non de minimum officiel de n8n, comptez 2 Go pour les tests et 4 Go lorsque vous ajoutez PostgreSQL et des workflows de production. Surveillez des workflows représentatifs et ajoutez de la mémoire lorsqu'une pression durable apparaît.

Rappelez-vous aussi que n8n est généralement plus limité par la mémoire que par le CPU. La documentation de n8n est claire au sujet de la plateforme : isn’t CPU intensive, et usually, memory requirements supersede CPU requirements. Ce qui fait grimper la consommation de mémoire, ce sont vos workflows : le volume de données, les nœuds Code (qui copient les données avant et après traitement) et les fichiers binaires volumineux.

Voici notre petit calcul sur un coin de table pour prévoir de la marge :

Dimensionnez en fonction de la simultanéité des exécutions et du volume de données traité par chaque workflow, puis surveillez l'utilisation de la mémoire sous une charge représentative. Les nœuds Code et les charges binaires volumineuses peuvent augmenter les besoins en mémoire : gardez de la marge et faites évoluer le VPS lorsque la surveillance révèle une pression durable.

Vous débutez avec l'hébergement VPS ? Commencez par le guide du VPS pour débutants de DreamHost pour comprendre les bases avant de dimensionner votre serveur.

Quel VPS choisir pour un n8n auto-hébergé ?

n8n ne publie pas de paliers de RAM fixes selon la charge. Dimensionnez en fonction de la simultanéité des exécutions et du volume de données, gardez de la marge pour Docker et PostgreSQL, puis surveillez des workflows représentatifs et faites évoluer le serveur quand la pression sur la mémoire persiste.

Voici donc comment nous transposerions cela aux plans DreamHost :

Au-delà de la RAM, quelques caractéristiques méritent votre attention : n8n cite le stockage SSD parmi les bonnes pratiques pour la base de données. Les besoins en mémoire l'emportent généralement sur les besoins en CPU, mais le véritable goulot d'étranglement dépend de la simultanéité des workflows, du volume de données et des nœuds que vous utilisez. La bande passante illimitée compte si vous exécutez des charges riches en webhooks, avec un flux constant de requêtes HTTP entrantes.

Choisissez un environnement d'hébergement qui vous permet d'exécuter Docker et de configurer la base de données, le réseau, le stockage persistant et le reverse proxy. Un hébergement partagé 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 illimité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 un SSL automatique, si vous préférez éviter la configuration manuelle ci-dessous.

Pour un serveur n8n exécutant des workflows de production, nous recommandons le Stack 8, le plan que nos pages présentent comme adapté aux applications en production. Le Stack 4 respecte l'allocation de départ de 4 Go pour un premier serveur léger. En date d'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 en vigueur. C'est ce prix de renouvellement qu'il faut honnêtement comparer aux 20 €/mois de n8n Cloud Starter.

Ah, et un point à garder dans un coin de votre tête pour plus tard : à mesure que votre usage augmente, n8n prend en charge le mode file d'attente, une architecture évolutive qui sépare l'instance principale (interface, déclencheurs, webhooks) de l'exécution des workflows, avec Redis comme courtier de messages et des instances workers pour exécuter les tâches. La documentation de n8n le décrit ainsi : provides the best scalability.

Comment installer n8n sur un VPS ?

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

Les commandes visent Ubuntu 22.04 ou version ultérieure ; remplacez toutefois le domaine d'exemple, les valeurs secrètes, le nom du volume et les noms de fichiers de sauvegarde datés lorsque c'est indiqué. La documentation Docker Compose de n8n couvre le même terrain avec un proxy Traefik, si vous préférez suivre le modèle de n8n.

Ce dont vous aurez besoin avant de commencer

• Un VPS avec accès root sous Ubuntu 22.04 ou version ultérieure, avec au moins 2 Go de RAM (par prudence, nous recommandons 4 Go pour la production)
• Un nom de domaine que vous pouvez faire pointer vers l'adresse IP de votre serveur (pour TLS et l'accès à l'éditeur n8n)
• Une aisance de base avec le terminal : vous devez savoir vous connecter à un serveur en SSH, modifier un fichier et exécuter des commandes

Un prérequis de plus, qui ne figure sur aucune liste officielle : sauvegardez votre N8N_ENCRYPTION_KEY dès que vous la générez. C'est pourquoi l'étape 5 vous 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 vos identifiants enregistrés, y compris chaque clé API, jeton OAuth et mot de passe de base de données que vous avez connectés. La documentation Docker de n8n elle-même prévient 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. Autrement dit, vous devez reconstruire chaque intégration de zéro (en regrettant amèrement vos choix de vie). Copiez-la en lieu sûr, séparément des sauvegardes de votre base de données.

Si votre fournisseur ne vous a donné qu'un accès root, créez d'abord un utilisateur de déploiement, depuis la console du fournisseur ou une session SSH root, avant de lancer 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 : pointez votre domaine vers le serveur

Créez un enregistrement DNS A pour un sous-domaine dédié (n8n.example.com dans tout ce guide) qui pointe vers l'adresse IP de votre serveur, exactement comme le décrit le guide Docker Compose de n8n. Faites-le en premier : si la propagation DNS n'est pas terminée, Caddy ne peut pas obtenir de certificat, et votre navigateur risque d'afficher une erreur de sécurité au lieu de l'éditeur n8n.

Étape 2 : renforcez l'accès SSH

Sur votre machine locale, générez une paire de clés (la documentation OpenSSH d'Ubuntu recommande ed25519) et copiez-la sur le serveur :

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

Vérifiez que vous pouvez vous connecter avec la clé. Ensuite, sur le serveur, désactivez les connexions par mot de passe et en root, puis vérifiez 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 volontaire. D'après le manuel de sshd_config, OpenSSH utilise la première valeur qu'il lit pour chaque mot-clé, et les images de serveurs cloud incluent souvent, dans le même répertoire, des fichiers de configuration complémentaires lus plus tôt (cloud-init, par exemple, écrit ses paramètres SSH dans 50-cloud-init.conf). Si vous nommez votre fichier 99-hardening.conf, l'un de ces fragments peut l'emporter sans prévenir. 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érifiez que la dernière commande affiche passwordauthentication no et permitrootlogin no avant d'aller plus loin. Ensuite, redémarrez sshd :

sudo systemctl restart ssh.service

La documentation d'Ubuntu prévient qu'une mauvaise configuration de sshd sur un serveur distant peut vous bloquer l'accès. Gardez votre session actuelle ouverte et testez une nouvelle connexion dans un second terminal avant de fermer quoi que ce soit.

Étape 3 : activez le pare-feu

Ubuntu fournit UFW (Uncomplicated Firewall) désactivé par défaut. Autorisez SSH avant de l'activer, pour que le pare-feu ne puisse pas couper votre 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 de plus. Un avertissement propre à Docker, tiré de la documentation d'installation de Docker elle-même : 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 hôte que pour Caddy : 80 et 443 sont les seuls ports de conteneur publiés par Compose (SSH sur le port 22 est également ouvert), et n8n comme PostgreSQL n'ont aucun port hôte publié.

Étape 4 : installez Docker et Docker Compose

Installez 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. Commencez par 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, enregistrez 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 votre 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 installez et vérifiez :

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éez le répertoire du projet et les secrets

Créez le répertoire du projet, puis générez votre clé de chiffrement — ne laissez pas n8n en inventer une en douce au premier démarrage :

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

Copiez immédiatement le résultat en lieu sûr, hors du serveur. Ensuite, placez-le, avec un mot de passe de base de données robuste, dans un fichier .env protégé à côté de votre fichier compose (Docker Compose le lit automatiquement). Remplacez les deux valeurs d'exemple par les vôtres :

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 a son importance : 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 le même principe à l'intérieur du conteneur : d'après la référence des variables de sécurité de n8n, cette variable fait en sorte que n8n tente d'appliquer les permissions 0600 à son propre fichier de paramètres.

Étape 6 : rédigez le fichier Docker Compose

Créez /opt/n8n-compose/docker-compose.yml (par exemple avec sudo nano /opt/n8n-compose/docker-compose.yml) et collez-y le contenu suivant, en remplaçant n8n.example.com par votre propre domaine dans les deux lignes d'URL et en indiquant votre 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 méritent qu'on s'y attarde :

• L'image est épinglée à une version précise (2.36.7 est la version stable actuelle au moment où nous écrivons ces lignes, selon la documentation d'installation de n8n) : les mises à jour n'ont donc lieu que lorsque vous le décidez.
• n8n ne publie aucun port hôte. Les conteneurs du réseau Compose, dont Caddy, peuvent le joindre, mais pas via un port hôte publié : l'éditeur n'est donc accessible que par le reverse proxy, jamais directement depuis Internet.
• Grâce au healthcheck, n8n attend 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 provient directement de l'exemple de fichier compose Postgres de n8n, qui déploie lui aussi PostgreSQL 18.
• La paire N8N_WEBHOOK_URL / N8N_PROXY_HOPS est importante derrière un proxy. Normalement, n8n construit les URL de webhook à partir de son protocole, de son hôte et de son port ; or, selon la documentation de n8n, cela ne fonctionne pas derrière un reverse proxy. Vous définissez donc manuellement l'URL des webhooks, dans ce but : register the correct webhook URLs with external services, puis vous réglez N8N_PROXY_HOPS sur 1 et vous vérifiez 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. D'après 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 (celui qu'indiquent des commandes comme date). Donnez-leur la même valeur.

(Utilisez PostgreSQL dès le premier jour. Par défaut, n8n utilise SQLite, ce qui convient pour les tests, mais les modèles d'hébergement de n8n recommandent PostgreSQL en production, et migrer plus tard est pénible, du genre « j'aurais dû faire ça correctement dès le départ ».)

Étape 7 : rédigez le Caddyfile

Créez /opt/n8n-compose/Caddyfile avec votre domaine (là encore, remplacez n8n.example.com) :

n8n.example.com {
    reverse_proxy n8n:5678
}

C'est toute la configuration du reverse proxy. D'après la documentation de Caddy sur le HTTPS automatique, Caddy obtient et renouvelle automatiquement un certificat reconnu publiquement, auprès d'un émetteur comme Let’s Encrypt ou ZeroSSL, et redirige HTTP vers HTTPS, à condition que votre 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 reverse proxies des exemples d'hébergement officiels de n8n.

Étape 8 : lancez et vérifiez

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

Attendez que ps indique que le conteneur postgres est sain (healthy) et que n8n tourne, puis vérifiez 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 terminé la connexion TLS et que n8n a répondu ; si curl se termine plutôt par une erreur, il faut examiner le DNS, le certificat ou les conteneurs (commencez par sudo docker compose logs caddy et sudo docker compose logs n8n). Ouvrez https://n8n.example.com dans un navigateur et créez votre compte propriétaire.

Étape 9 : mettez à jour n8n de façon maîtrisée

n8n publie une nouvelle version mineure presque chaque semaine, et ses instructions de mise à jour vous demandent de consulter le changelog des changements incompatibles avant toute mise à niveau. Le moment venu : modifiez 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 vous qui choisissez chaque mise à niveau en modifiant le tag, et c'est tout l'intérêt de l'épinglage. Lancez une sauvegarde (étape 10) avant les mises à jour de version majeure.

Étape 10 : planifiez 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 N8N_ENCRYPTION_KEY. La documentation Docker de n8n est explicite : même si vous utilisez PostgreSQL, le dossier /home/node/.n8n (notre volume n8n_data) contient toujours des données essentielles, dont les éléments de la clé de chiffrement. Sauvegardez les trois, et conservez docker-compose.yml et Caddyfile pour pouvoir reconstruire la stack. Le script ci-dessous s'occupe de la base de données et du volume ; la copie des fichiers de configuration hors du serveur vient juste après. Créez le script dans un 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érifiez le vôtre avec sudo docker volume ls et adaptez-le s'il est différent. Les deux lignes find conservent 30 jours de sauvegardes ; choisissez une autre durée de conservation selon votre espace de stockage et vos besoins de restauration.

Planifiez-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 à 600), jamais un fichier qu'un autre utilisateur peut modifier. Lancez sudo crontab -e et ajoutez une ligne pour une exécution quotidienne à 3 h :

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. Copiez hors du serveur le .env (qui contient votre clé de chiffrement) ainsi que les fichiers Compose et Caddy, dès maintenant puis à chaque modification. Sur le serveur, créez 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 votre machine locale, récupérez l'archive de configuration ainsi que les sauvegardes, puis supprimez 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 : testez une restauration sur un VPS de test

Il s'agit d'une procédure de sauvegarde et de restauration qui vous permet de vérifier que vos sauvegardes sont utilisables. Testez cette restauration sur un nouveau VPS de test, jamais sur votre serveur de production. Provisionnez un serveur jetable, répétez-y l'étape 4 (Docker), puis copiez vos fichiers de projet (docker-compose.yml, Caddyfile, .env) et vos dernières sauvegardes datées aux mêmes emplacements.

Commencez par changer le nom d'hôte : indiquez un nom d'hôte de test (par exemple n8n-restore-test.example.com, avec un enregistrement A pointant vers le VPS de test) dans N8N_HOST, N8N_WEBHOOK_URL et le Caddyfile. Ensuite, en remplaçant les noms de fichiers datés par les vôtres :

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 CLI serveur 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 s'exécutent pas contre vos systèmes de production depuis la machine de test. Terminez par la même vérification curl qu'à l'étape 8, sur le nom d'hôte de test.

Soyez lucide sur ce que signifie une vérification réussie : elle confirme que la base de données et le volume ont été restaurés et que la stack démarre correctement. Elle ne teste pas vos workflows dans l'éditeur : connectez-vous donc à l'instance de test et vérifiez ponctuellement ceux que vous ne pouvez pas vous permettre de perdre.

Comment sécuriser une instance n8n auto-hébergée ?

Une instance n8n auto-hébergée est aussi sûre que le serveur sur lequel elle tourne, et c'est vous qui contrôlez ce serveur.

La sécurité repose sur six points. Aucun n'est compliqué en soi, mais en négliger un seul laisse une vraie faille. La configuration ci-dessus applique déjà les trois premiers.

1. HTTPS via un reverse proxy. N'accédez jamais à l'éditeur n8n en HTTP simple. La configuration Caddy de l'étape 7 obtient et renouvelle automatiquement un certificat reconnu publiquement, auprès d'un émetteur comme Let’s Encrypt ou ZeroSSL, et redirige HTTP vers HTTPS.
2. Pare-feu verrouillé. UFW n'autorise que SSH (22), HTTP (80) et HTTPS (443). N'exposez jamais directement le port par défaut de n8n, 5678, sur Internet. Le fichier compose ci-dessus l'impose en ne donnant à n8n aucun port hôte publié : seuls les conteneurs du réseau Compose peuvent le joindre.
3. Isolation du réseau Docker. PostgreSQL et n8n communiquent via le réseau Compose interne. Le port de votre base de données n'est jamais publié sur l'hôte : il n'est donc jamais accessible de l'extérieur.
4. Authentification forte. Utilisez un mot de passe propriétaire robuste et activez 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. Modifiez le tag de version dans votre fichier compose, puis faites un pull et redémarrez (étape 9). Lisez d'abord le changelog, car les mises à jour de n8n peuvent inclure des changements incompatibles.
6. Des sauvegardes que vous avez réellement restaurées. Les étapes 10 et 11 vous donnent la planification et le test. Une sauvegarde jamais testée est un espoir, pas un plan.

Encore un point à surveiller, qui ne relève pas strictement de la sécurité mais 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. Le nettoyage est activé par défaut : n8n supprime les exécutions de plus de 336 heures (14 jours), ou dès que vous dépassez 10 000 exécutions stockées. Une instance très sollicitée peut tout de même faire gonfler PostgreSQL entre-temps.

Si vos workflows sont bavards, resserrez ces réglages : définissez EXECUTIONS_DATA_MAX_AGE=168 pour supprimer les données d'exécution de plus de sept jours (le fichier compose ci-dessus le fait déjà), ou n'enregistrez plus du tout les exécutions réussies avec EXECUTIONS_DATA_SAVE_ON_SUCCESS=none.

Auto-hébergement ou n8n Cloud : quels compromis ?

Auto-héberger n8n vous offre 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 votre propre travail d'administration. n8n Cloud vous évite toute maintenance de serveur, avec des plafonds d'exécutions selon la formule. Le choix revient à savoir si vous voulez maîtriser votre infrastructure d'automatisation ou payer quelqu'un d'autre pour la gérer.

La documentation de n8n le formule ainsi : n8n recommends self-hosting for expert users. Mistakes can lead to data loss, security issues, and downtime. If you aren’t experienced at managing servers, n8n recommends n8n Cloud.

Voici comment les deux options se comparent :

Il existe aussi une solution intermédiaire à connaître. Des plateformes gérées comme PikaPods (environ 3,80 $/mois) et Elestio (environ 17 $/mois, selon le comparatif d’ExpressTech) font tourner n8n auto-hébergé sans que vous ayez à gérer le serveur vous-même. Ces services peuvent alléger l’administration du serveur, mais vérifiez qui se charge des mises à jour de n8n, des sauvegardes, de la surveillance et de la sécurité.

Mais prenons un peu de recul. Sur toute offre hébergée, votre 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 alors que vos workflows sont déjà en place.

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

Prendre la décision finale

L’auto-hébergement est pertinent quand trois conditions sont réunies :

1. Vous exécutez assez d’automatisations pour que les plafonds d’exécution du cloud deviennent gênants
2. Vous voulez que les données de vos workflows restent sur une infrastructure que vous contrôlez
3. Vous (ou un membre de votre équipe) êtes prêt à prendre en charge les mises à jour, les sauvegardes et la surveillance

Sinon, n8n Cloud est un choix raisonnable. Payer l’offre Starter pour ne jamais avoir à vous soucier des logs Docker est un compromis honnête, surtout pour une petite équipe qui veut simplement que ses automatisations tournent.

Mais une fois prêt à franchir le pas de l’auto-hébergement, le calcul devient vite sans appel. Un VPS de 4 Go est un point de départ pratique, même s’il n’a pas été testé en benchmark ; la capacité en production dépend de la concurrence, du volume de données et des nœuds que vous utilisez : surveillez donc l’instance et faites-la évoluer à mesure que la demande augmente. Commencez petit, montez en gamme au rythme de vos workflows et gardez le contrôle total de votre stack.

Ce dernier point compte plus qu’il n’y paraît. Vous pouvez toujours passer à un serveur plus puissant. Il est bien plus difficile de vous dégager d’une plateforme SaaS une fois qu’elle a modifié ses tarifs alors que vos workflows sont déjà en place.

Questions fréquentes sur l'auto-hébergement de n8n