n8n Self-Hosted : Guide Complet pour Installer sur VPS (2026)

n8n Self-Hosted : Guide Complet pour Installer sur VPS (2026)

Reprenez le contrôle de vos automatisations : vos données, vos workflows, votre infrastructure.

Héberger n8n self-hosted sur un VPS est le choix des équipes qui refusent de confier leurs automatisations critiques à un SaaS qu'elles ne contrôlent pas. À la place d'un abonnement cloud qui grimpe avec le volume, vous obtenez des exécutions illimitées, des données 100 % privées et un coût fixe que vous maîtrisez au centime près. Ce guide vous accompagne du choix du serveur jusqu'à la mise en production sécurisée : installation Docker, reverse proxy, HTTPS, sauvegardes, montée en charge et maintenance quotidienne.

L'objectif n'est pas de vous vendre une solution miracle, mais de vous donner une procédure réaliste, testée sur le terrain, avec ses avantages et ses contraintes. À la fin, vous saurez si le self-hosting est pertinent pour votre cas, et comment le déployer proprement.

Pourquoi héberger n8n self-hosted sur un VPS ?

n8n est un outil d'automatisation « fair-code » : son code source est ouvert et son édition Community peut être auto-hébergée gratuitement. Cette particularité change tout par rapport à un Zapier ou un Make, facturés à la tâche. En self-hosting, vous ne payez que votre serveur, quel que soit le nombre d'exécutions.

Quel est l'intérêt économique du self-hosting ?

C'est l'argument le plus immédiat. Sur le cloud officiel, la facture suit votre volume d'exécutions. En self-hosted, elle suit la puissance de votre VPS — et un petit serveur encaisse déjà beaucoup.

Tarifs cloud indicatifs mi-2026, à vérifier sur n8n.io ; le modèle évolue régulièrement.

La logique est simple : le VPS facture une capacité, pas un usage. Tant que votre serveur tient la charge, ajouter 10 000 exécutions ne coûte rien de plus. Sur trois ans, l'écart se chiffre en milliers d'euros pour une équipe qui automatise sérieusement. Pour une comparaison détaillée des modèles tarifaires entre outils, consultez notre analyse prix de l'automatisation n8n et Make en 2026.

À 100 000 exécutions/mois, le self-hosted coûte ~10 € contre 400 €+ pour n8n Cloud — soit un ordre de grandeur de 40x moins cher

Quels autres avantages au-delà du prix ?

Le coût n'est que la partie visible. Le self-hosting débloque surtout des capacités qu'aucune offre cloud ne propose facilement :

• Aucune limite d'exécutions — vous traitez des milliers d'opérations par heure sans surcoût et sans throttling imposé.
• Souveraineté des données — vos identifiants, vos payloads, vos logs restent sur votre serveur. Un argument décisif pour le RGPD et les secteurs régulés (santé, finance, juridique).
• Latence réduite — si votre VPS est dans la même région que vos APIs, les allers-retours réseau fondent.
• Connexion aux systèmes internes — base de données interne, serveur de fichiers, API privée non exposée sur Internet : votre instance auto-hébergée peut les atteindre, contrairement au cloud public.
• Liberté de configuration — variables d'environnement, nodes communautaires, exécution de code personnalisé : vous décidez de tout.

Quelles sont les limites à connaître ?

Soyons honnêtes : le self-hosting n'est pas gratuit en temps. Vous devenez responsable des mises à jour, des sauvegardes, de la sécurité et de la disponibilité. Une instance mal configurée exposée sans authentification, c'est une porte ouverte sur vos identifiants. Un VPS sous-dimensionné qui tombe en pleine nuit, c'est des workflows manqués. Le self-hosting demande donc une rigueur minimale d'exploitation — que ce guide vise précisément à vous transmettre.

n8n self-hosted ou n8n Cloud : comment décider ?

La bonne réponse dépend de votre volume, de votre sensibilité aux données et de votre capacité technique. Plutôt qu'un débat idéologique, suivez un arbre de décision concret.

Au-delà de 2 500 exécutions/mois, avec des données sensibles ou une connexion à des systèmes internes, le self-hosted sur VPS devient le choix rationnel

En résumé : choisissez le self-hosted si vos volumes dépassent quelques milliers d'exécutions par mois, si vos données sont sensibles, si vous avez besoin d'atteindre des systèmes internes, ou si vous disposez d'un minimum de compétences DevOps. Restez sur le cloud si vous débutez, si votre volume est faible et si vous préférez ne gérer aucune infrastructure. Beaucoup d'équipes commencent d'ailleurs sur le cloud, puis migrent vers un VPS dès que la facture mensuelle dépasse le coût d'un serveur.

Quel VPS choisir pour héberger n8n ?

Le dimensionnement dépend surtout de vos workflows. Des automatisations légères (webhooks, appels d'API, transformations de données) consomment peu. Des agents IA, des traitements de fichiers volumineux ou un mode file d'attente avec workers demandent davantage de ressources.

Quelle configuration minimale prévoir ?

• CPU : 1 vCPU pour démarrer, 2 vCPU dès que vous utilisez des agents IA ou plusieurs workers.
• RAM : 1 Go au strict minimum, 2 Go recommandés pour respirer. Le navigateur de l'éditeur n8n et Node.js apprécient la marge.
• Stockage : 20 Go SSD suffisent au départ. Surveillez la croissance des logs d'exécution et des données binaires.
• OS : Ubuntu 22.04 LTS ou 24.04 LTS — distributions stables, bien documentées, support long terme.

Un conseil : commencez petit, mais choisissez un fournisseur qui permet d'augmenter les ressources en quelques clics. La montée en gamme d'un VPS est généralement bien plus simple qu'une migration de serveur.

Quels fournisseurs de VPS recommander ?

Prix indicatifs mi-2026, hors promotions ; vérifiez les grilles actuelles, elles changent souvent.

Notre recommandation pour une équipe européenne : Hetzner, pour son rapport performance/prix difficile à battre et ses datacenters allemands conformes au RGPD. OVH reste un excellent choix si vous voulez un datacenter français. Contabo offre beaucoup de RAM pour le prix, au prix d'une régularité de performance parfois moins constante d'après les retours communautaires.

À quoi ressemble l'architecture d'une instance n8n self-hosted ?

Avant de taper la moindre commande, visualisez la cible. Une instance n8n de production ne se résume jamais au seul conteneur n8n. Il vous faut un reverse proxy pour le HTTPS, une base PostgreSQL pour la persistance, des volumes pour les données, et idéalement Redis si vous passez en mode file d'attente.

Le navigateur passe par le reverse proxy (HTTPS), qui relaie vers le conteneur n8n ; n8n s'appuie sur PostgreSQL, un volume persistant et, en option, Redis pour la file d'attente

Cette séparation des responsabilités est la clé d'une instance robuste. Le reverse proxy gère le chiffrement TLS et n'expose que les ports 80 et 443. n8n écoute en interne sur le port 5678, jamais directement sur Internet. PostgreSQL stocke workflows, exécutions et identifiants chiffrés. Le volume conserve la clé de chiffrement et les fichiers. Chaque brique est remplaçable indépendamment — c'est exactement ce qui rend l'ensemble maintenable.

Comment installer n8n sur un VPS pas à pas ?

Voici la procédure recommandée, basée sur Docker Compose. Docker isole n8n et ses dépendances, rend les mises à jour triviales et garantit la reproductibilité. Les commandes ci-dessous sont des exemples simplifiés : adaptez les noms d'utilisateur, domaines et mots de passe à votre contexte.

Quatre étapes vers une instance production-ready : sécuriser le VPS, installer Docker, déployer n8n derrière un reverse proxy, puis automatiser le monitoring

1. Comment sécuriser le VPS avant d'installer n8n ?

La toute première étape n'est pas n8n, c'est le durcissement du serveur. Mettez le système à jour, créez un utilisateur non-root, désactivez la connexion SSH par mot de passe au profit des clés, et fermez tout sauf l'essentiel avec le pare-feu.

# Exemple simplifié — à adapter
apt update && apt upgrade -y

# Utilisateur dédié avec droits sudo
adduser n8nadmin
usermod -aG sudo n8nadmin

# Durcir SSH : pas de login root direct
sed -i 's/#PermitRootLogin yes/PermitRootLogin no/' /etc/ssh/sshd_config
systemctl restart ssh

# Pare-feu : on n'ouvre que SSH, HTTP et HTTPS
ufw allow OpenSSH
ufw allow 80
ufw allow 443
ufw enable

Pour aller plus loin, installez fail2ban pour bloquer les tentatives de connexion répétées, et privilégiez l'authentification SSH par clé plutôt que par mot de passe. Ces deux mesures réduisent drastiquement la surface d'attaque.

2. Comment installer Docker et Docker Compose ?

n8n se déploie idéalement en conteneur. Le script officiel de Docker installe le moteur et le plugin Compose en une commande.

# Exemple simplifié
curl -fsSL https://get.docker.com | sh
usermod -aG docker n8nadmin
systemctl enable docker

Déconnectez-vous puis reconnectez-vous pour que l'appartenance au groupe docker prenne effet. Vérifiez avec docker compose version que le plugin Compose répond bien.

3. Comment configurer le domaine et le reverse proxy ?

Faites pointer un enregistrement DNS A (par exemple n8n.votre-domaine.com) vers l'adresse IP de votre VPS. Le reverse proxy se chargera ensuite d'obtenir un certificat TLS et de relayer le trafic vers n8n.

Caddy est le plus simple : il gère le HTTPS automatiquement via Let's Encrypt, sans configuration manuelle de certificats. Un Caddyfile minimal suffit :

# Exemple simplifié — Caddyfile
n8n.votre-domaine.com {
    reverse_proxy n8n:5678
}

Caddy demande, renouvelle et installe le certificat tout seul. Si vous préférez Nginx ou Traefik, les deux fonctionnent parfaitement, mais demandent une configuration plus verbeuse (avec Certbot pour Nginx, ou les labels Docker pour Traefik). Pour un premier déploiement, Caddy fait gagner un temps précieux.

4. Comment déployer n8n avec docker-compose ?

Voici un docker-compose.yml d'exemple combinant n8n, PostgreSQL et Caddy. Il illustre la structure ; adaptez les secrets et le domaine.

# Exemple simplifié — docker-compose.yml
services:
  postgres:
    image: postgres:16
    restart: always
    environment:
      - POSTGRES_USER=n8n
      - POSTGRES_PASSWORD=motdepasse_robuste
      - POSTGRES_DB=n8n
    volumes:
      - postgres_data:/var/lib/postgresql/data

  n8n:
    image: docker.n8n.io/n8nio/n8n
    restart: always
    environment:
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_USER=n8n
      - DB_POSTGRESDB_PASSWORD=motdepasse_robuste
      - N8N_HOST=n8n.votre-domaine.com
      - N8N_PROTOCOL=https
      - WEBHOOK_URL=https://n8n.votre-domaine.com/
      - N8N_ENCRYPTION_KEY=cle_de_chiffrement_longue_et_unique
      - GENERIC_TIMEZONE=Europe/Paris
    volumes:
      - n8n_data:/home/node/.n8n
    depends_on:
      - postgres

  caddy:
    image: caddy:2
    restart: always
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - caddy_data:/data

volumes:
  postgres_data:
  n8n_data:
  caddy_data:

Lancez l'ensemble avec docker compose up -d, puis surveillez le démarrage via docker compose logs -f n8n. Une fois le certificat émis, votre instance est accessible en HTTPS. Pour une configuration Docker plus détaillée (variables avancées, healthcheck, options de réseau), notre guide complet d'installation n8n avec Docker approfondit chaque paramètre.

Quelles variables d'environnement sont essentielles pour n8n ?

La configuration de n8n passe presque entièrement par des variables d'environnement. En maîtriser quelques-unes vous évite la plupart des erreurs de mise en production. Référez-vous toujours à la documentation officielle pour la liste à jour, mais voici les incontournables :

• N8N_ENCRYPTION_KEY — la clé qui chiffre vos identifiants en base. Sauvegardez-la précieusement : sans elle, vos credentials sont irrécupérables après une restauration.
• DB_TYPE / DB_POSTGRESDB_* — basculent n8n de SQLite (par défaut) vers PostgreSQL, recommandé en production.
• N8N_HOST, N8N_PROTOCOL, WEBHOOK_URL — indiquent à n8n son adresse publique. Une WEBHOOK_URL incorrecte est la cause numéro un des webhooks qui ne se déclenchent pas.
• GENERIC_TIMEZONE — fixe le fuseau horaire des nodes planifiés (Cron, Schedule). Indispensable pour des déclenchements à la bonne heure.
• N8N_SECURE_COOKIE — à true derrière HTTPS pour sécuriser les cookies de session.
• EXECUTIONS_MODE — regular par défaut, ou queue pour activer le mode file d'attente avec Redis et workers (voir plus bas).

Un principe de base : ne jamais coder les secrets en dur dans le docker-compose.yml versionné. Utilisez un fichier .env exclu du dépôt Git, ou un gestionnaire de secrets.

Comment sauvegarder et restaurer une instance n8n self-hosted ?

C'est le point que trop d'équipes négligent — jusqu'au jour où elles perdent leurs workflows. Une stratégie de sauvegarde correcte couvre trois éléments :

1. La base PostgreSQL — workflows, exécutions, identifiants chiffrés. Sauvegardez-la avec pg_dump.
2. Le volume de données n8n (/home/node/.n8n) — contient notamment la clé de chiffrement et certains fichiers.
3. La clé N8N_ENCRYPTION_KEY — conservez-la hors du serveur, dans un gestionnaire de secrets. Sans elle, une base restaurée affichera des identifiants illisibles.

Un script de sauvegarde quotidien, simple mais efficace :

# Exemple simplifié — backup-n8n.sh
DATE=$(date +%F)
docker compose exec -T postgres pg_dump -U n8n n8n > ~/backups/n8n-db-$DATE.sql
tar czf ~/backups/n8n-data-$DATE.tar.gz -C ~/n8n n8n_data
# Conserver 14 jours de sauvegardes
find ~/backups -type f -mtime +14 -delete

Automatisez-le via cron (0 3 * * * /bin/bash ~/backup-n8n.sh) et, idéalement, répliquez les sauvegardes vers un stockage externe (S3, Backblaze, autre VPS). Une sauvegarde qui reste sur le même serveur ne vous protège pas d'une panne disque. Testez régulièrement une restauration : une sauvegarde jamais restaurée est une sauvegarde dont vous ignorez si elle fonctionne.

Comment gérer la montée en charge avec les workers n8n ?

Par défaut, n8n exécute tout dans un seul processus (mode regular). Cela suffit pour des dizaines de workflows légers. Mais si vous lancez beaucoup d'exécutions simultanées ou des traitements longs, ce processus unique devient un goulot d'étranglement.

n8n propose alors le mode file d'attente (EXECUTIONS_MODE=queue). Le principe : l'instance principale reçoit les déclencheurs et pousse les exécutions dans une file Redis ; des conteneurs « workers » dédiés consomment cette file et exécutent les workflows en parallèle. Vous pouvez ajouter ou retirer des workers selon la charge.

Concrètement, cela implique d'ajouter un service Redis à votre docker-compose.yml, de configurer les variables de file d'attente, et de lancer un ou plusieurs services n8n worker. C'est une fonctionnalité native et documentée de n8n, particulièrement utile pour les workflows à fort débit ou les agents IA gourmands en ressources. Tant que votre charge reste modeste, restez en mode regular : n'ajoutez la complexité des workers que lorsque les métriques le justifient.

Comment monitorer et maintenir n8n au quotidien ?

Une instance auto-hébergée doit être surveillée. La bonne nouvelle : n8n expose un endpoint de santé (/healthz) qui répond 200 quand tout va bien. Un simple script cron peut le vérifier et redémarrer le conteneur en cas de souci.

# Exemple simplifié — healthcheck-n8n.sh
STATUS=$(curl -s -o /dev/null -w "%{http_code}" https://n8n.votre-domaine.com/healthz)
if [ "$STATUS" != "200" ]; then
    cd ~/n8n && docker compose restart n8n
    curl -X POST "https://hooks.slack.com/..." -d '{"text":"⚠️ n8n redémarré"}'
fi

Planifié toutes les 5 minutes (*/5 * * * * /bin/bash ~/healthcheck-n8n.sh), ce contrôle attrape la plupart des incidents avant vos utilisateurs. Pour une supervision plus complète, surveillez aussi l'espace disque, la mémoire et la taille de la base. Des outils comme Uptime Kuma (auto-hébergeable) ou un monitoring externe gratuit ajoutent une alerte indépendante du serveur lui-même.

Côté mises à jour, la routine reste légère :

# Exemple simplifié — mise à jour mensuelle
./backup-n8n.sh                # toujours sauvegarder avant
docker compose pull n8n        # récupérer la dernière image
docker compose up -d n8n       # redémarrer sur la nouvelle version
docker compose logs n8n | tail -50

Lisez les notes de version avant chaque montée de version majeure : n8n documente clairement les éventuelles ruptures de compatibilité. Une mise à jour mensuelle, sauvegarde en amont, suffit à garder une instance saine et à jour côté sécurité.

Dépannage : quelles sont les erreurs fréquentes ?

Quelques pièges reviennent systématiquement lors d'un premier déploiement self-hosted :

• Les webhooks ne se déclenchent pas — presque toujours une WEBHOOK_URL mal configurée. Elle doit correspondre exactement à votre domaine public en HTTPS.
• « Encryption key mismatch » après restauration — vous avez restauré la base sans la clé N8N_ENCRYPTION_KEY d'origine. Remettez la bonne clé dans la configuration.
• L'éditeur ne charge pas / erreurs de cookie — vérifiez N8N_SECURE_COOKIE et que N8N_PROTOCOL=https correspond bien à votre reverse proxy.
• Certificat TLS non émis — le DNS ne pointe pas (encore) vers le VPS, ou les ports 80/443 sont bloqués par le pare-feu. Let's Encrypt a besoin du port 80 pour la validation.
• Conteneur qui redémarre en boucle — souvent un manque de RAM. Consultez docker compose logs et envisagez un VPS plus généreux.

Quand vous bloquez, docker compose logs -f n8n est votre meilleur allié : la cause y est presque toujours écrite noir sur blanc.

Comment renforcer la sécurité de votre instance n8n ?

Une instance n8n contient des secrets précieux : clés d'API, jetons OAuth, identifiants de bases de données. La compromettre, c'est offrir un accès direct à tous les services connectés. La sécurité n'est donc pas optionnelle, elle est structurante.

Verrouillez l'accès à l'éditeur. n8n exige la création d'un compte propriétaire (Owner) au premier démarrage : choisissez un mot de passe long et unique, et activez la double authentification si votre version la propose. Ne laissez jamais une instance accessible sans authentification — un scan automatisé la trouvera en quelques heures.

N'exposez que le strict nécessaire. Grâce au reverse proxy, seul le port 443 (HTTPS) doit être ouvert sur Internet. Le port 5678 de n8n et le port 5432 de PostgreSQL restent internes au réseau Docker, invisibles depuis l'extérieur. Vérifiez votre pare-feu UFW : si 5678 ou 5432 apparaissent dans ufw status, fermez-les.

Maintenez tout à jour. Les failles de sécurité touchent autant n8n que le système, Docker ou les images de base. Au-delà de la mise à jour mensuelle de n8n, appliquez les correctifs système (apt upgrade) régulièrement et reconstruisez vos conteneurs pour récupérer les dernières images patchées. Un serveur jamais mis à jour devient une cible facile.

Isolez l'exécution de code. Si vos workflows utilisent le node Code, sachez que n8n propose des mécanismes d'isolation (task runners) pour exécuter le code dans un environnement séparé. Activez-les selon la documentation officielle si vous exécutez du code non maîtrisé, et limitez l'usage des nodes communautaires aux sources de confiance.

Chiffrez et tournez vos secrets. La variable N8N_ENCRYPTION_KEY protège vos identifiants en base. Stockez-la dans un gestionnaire de secrets, jamais dans un dépôt Git. En cas de fuite suspectée, révoquez les clés d'API tierces concernées et régénérez les jetons depuis les services d'origine.

Ces mesures ne demandent qu'une poignée d'heures à mettre en place et vous épargnent l'écrasante majorité des incidents. La sécurité d'une instance auto-hébergée n'est pas un projet ponctuel mais une hygiène : quelques bons réflexes, appliqués régulièrement.

Quelle checklist suivre avant la mise en production ?

Avant d'ouvrir votre instance aux utilisateurs, validez ces points :

• VPS durci : utilisateur non-root, SSH par clé, fail2ban, pare-feu UFW actif.
• Domaine pointé en DNS et HTTPS fonctionnel (certificat valide).
• PostgreSQL en base de données (pas SQLite) pour la production.
• N8N_ENCRYPTION_KEY définie et sauvegardée hors du serveur.
• WEBHOOK_URL, N8N_HOST, N8N_PROTOCOL cohérents avec votre domaine.
• Sauvegardes quotidiennes automatisées et restauration testée au moins une fois.
• Healthcheck cron + alerte (Slack, e-mail) configurés.
• Authentification activée (compte Owner protégé par un mot de passe fort).
• Plan de mise à jour mensuel acté.

Cochez tout, et vous disposez d'une instance digne de la production. Si vous prévoyez d'y faire tourner des agents IA connectés à des outils externes, notre guide pour connecter n8n à un serveur MCP complète idéalement ce socle.

Combien coûte réellement n8n self-hosted ?

Au-delà du seul prix du VPS (5 à 10 €/mois pour démarrer), comptez le coût caché : votre temps. La maintenance d'une instance bien automatisée représente, d'après notre expérience, moins d'une heure par mois en régime de croisière — mises à jour, vérification des sauvegardes, coup d'œil aux logs. Le déploiement initial, lui, demande une demi-journée à une journée pour quelqu'un d'à l'aise avec un terminal.

L'arbitrage est donc clair. Si votre facture n8n Cloud dépasse régulièrement le prix d'un VPS et que vous avez un minimum de compétences techniques, le self-hosting devient rentable en quelques mois. Si vous valorisez le « zéro maintenance » et que votre volume reste faible, le cloud garde tout son sens. Beaucoup d'équipes adoptent une approche hybride : cloud pour prototyper vite, VPS auto-hébergé une fois le besoin stabilisé.

Conclusion : faut-il se lancer dans le self-hosting ?

Héberger n8n self-hosted sur un VPS est aujourd'hui à la portée de toute équipe disposant d'un développeur à l'aise avec Docker. Vous gagnez des exécutions illimitées, la souveraineté de vos données et un coût fixe imbattable, en échange d'une rigueur d'exploitation modeste mais réelle : sauvegardes, mises à jour, monitoring. Suivez la procédure de ce guide — sécurisation, Docker, reverse proxy, persistance Postgres, sauvegardes testées — et votre instance tiendra la production sans surprise.

Si vous voulez aller plus loin dans la conception de workflows intelligents, notre tutoriel complet pour bâtir un agent IA avec n8n prend le relais une fois votre serveur en place.

Vous préférez déléguer le déploiement et la configuration ? L'équipe BOVO Digital installe, sécurise et documente votre instance n8n self-hosted, formation incluse, pour que vous puissiez vous concentrer sur vos automatisations plutôt que sur l'infrastructure.