Vous avez goûté à n8n en local (sur votre ordinateur) et compris ses atouts : exécutions illimitées, données chez vous. Une limite demeure : votre ordinateur s’éteint, vos workflows aussi — et les webhooks ne peuvent pas vous joindre. Ce tutoriel franchit le cap qui sépare l’amateur de l’expert : installer n8n sur un VPS, accessible en HTTPS sur votre domaine, qui tourne 24/7 pour le prix de deux cafés par mois.
Prérequis : le module 3 acquis, ~45 minutes, un VPS bien dimensionné (5-10 €/mois chez la plupart des hébergeurs) et un nom de domaine. Aucune compétence d’administrateur système requise : on suit, on colle, on comprend.
L’architecture cible (comprendre avant de taper)
- Le VPS : un petit serveur Linux loué (2 Go de RAM suffisent largement pour démarrer).
- Le reverse proxy (Caddy, le plus simple) : il reçoit le trafic et fournit le HTTPS automatiquement — indispensable pour les webhooks et la sécurité.
- Le conteneur n8n : le même Docker qu’en local (terrain connu !).
- Le volume : vos workflows et identifiants, qui survivent à tout redémarrage.
Étape 1 — Le VPS et le domaine (10 min)
- Commandez un VPS Linux (Ubuntu LTS) chez votre hébergeur — l’offre d’entrée suffit.
- Chez votre registrar, créez un enregistrement DNS A :
n8n.votredomaine.fr→ l’adresse IP du VPS. - Connectez-vous en SSH :
ssh root@IP_DU_VPS(l’hébergeur fournit la commande exacte).
Étape 2 — Docker + le fichier magique (15 min)
Installez Docker (la plupart des hébergeurs proposent une image « Docker » prête ; sinon, le script officiel get.docker.com fait l’affaire). Puis créez le fichier docker-compose.yml — dont nous expliquons chaque ligne dans un guide dédié si vous voulez comprendre ce que vous collez :
mkdir n8n && cd n8n
nano docker-compose.yml # collez la configuration
nano Caddyfile # 2 lignes : votre domaine -> n8n:5678
docker compose up -d # tout démarre
docker compose ps # vérifier : 2 services « running »Le Caddyfile tient en deux lignes — c’est lui qui obtient et renouvelle vos certificats HTTPS sans que vous y pensiez jamais :
n8n.votredomaine.fr {
reverse_proxy n8n:5678
}WEBHOOK_URL du docker-compose est LE détail qui change tout par rapport au local : c’est elle qui fait que vos webhooks affichent votre domaine public. Oubliée, vos webhooks pointeraient vers localhost — et rien ne fonctionnerait depuis l’extérieur.Étape 3 — Premier démarrage et vérifications (5 min)
- Ouvrez https://n8n.votredomaine.fr : le cadenas est vert, l’écran « Set up owner account » vous attend (comme en local — module 3).
- Créez le compte propriétaire avec un mot de passe fort : cette page est désormais sur Internet.
- Testez un webhook : créez un workflow déclenché par webhook, appelez l’URL depuis votre téléphone en 4G — exécution instantanée. Vos webhooks sont vivants. 🎉
Étape 4 — Les sauvegardes (non négociable)
Votre serveur contient maintenant des choses précieuses. Deux lignes dans la crontab du VPS exportent chaque nuit le volume vers une archive datée, et un petit workflow n8n (oui, n8n peut se sauvegarder lui-même !) pousse l’archive vers votre Drive. Serveur perdu = vingt minutes pour tout restaurer ailleurs : docker compose up -d + restauration du volume. La méthode complète — quoi copier, à quelle fréquence, où déposer les copies et comment tester la restauration — est détaillée dans sauvegarder, restaurer et migrer n8n.
docker compose pull && docker compose up -d, 30 secondes) : les mises à jour incluent les correctifs de sécurité. Et ne sautez JAMAIS l’étape sauvegarde — le seul vrai risque du self-host, c’est de se croire dispensé des précautions de base. La suite logique : l’article sécurité de ce module.| Poste | Coût mensuel | Comparaison |
|---|---|---|
| VPS 2 Go | 5-10 € | ≈ plan d’entrée cloud |
| Domaine | ~1 €/mois (12 €/an) | souvent déjà possédé |
| Exécutions | illimitées | facturées partout ailleurs |
| Total | ~6-11 €/mois fixes | quel que soit le volume |
📘 Ebook offert : « Débuter dans l’automatisation no-code »
Les modules 1 & 2 compilés en PDF + une newsletter utile chaque semaine.
Dimensionner son serveur : ce qui consomme réellement
La question revient toujours en premier, et la réponse dépend moins du nombre d’automatisations que de ce qu’elles font. Nous la traitons en détail — paliers, hébergeurs, coût sur un an — dans quel VPS choisir pour n8n ; voici l’essentiel.
Les trois postes de consommation
La mémoire vive est la ressource critique. L’application au repos en occupe quelques centaines de mégaoctets. Chaque exécution en cours en ajoute, et le pic dépend surtout de la taille des données manipulées : un traitement qui charge un fichier de cinquante mégaoctets a besoin de place pour lui.
Le processeur intervient peu. Une automatisation passe l’essentiel de son temps à attendre des réponses extérieures, pas à calculer. Deux cœurs suffisent très largement pour un usage de petite structure.
Le disque croît lentement, presque uniquement à cause de l’historique des exécutions. C’est le poste le plus facile à maîtriser : une durée de conservation raisonnable et le problème disparaît.
Les ordres de grandeur
| Usage | Mémoire | Disque | Remarque |
|---|---|---|---|
| Découverte, quelques automatisations | 1 à 2 Go | 20 Go | Largement suffisant |
| Production, une dizaine d’automatisations | 2 à 4 Go | 40 Go | Le cas le plus courant |
| Volume, traitements par lots | 4 à 8 Go | 80 Go | Surveiller les pics |
| Manipulation de fichiers lourds | 8 Go et plus | Selon les fichiers | La mémoire décide |
Le conseil pratique : commencez petit. Un serveur se redimensionne en quelques minutes chez la plupart des hébergeurs, sans perdre de données. Payer d’avance pour une capacité que vous n’utilisez pas est un gaspillage ; l’inverse se corrige en un après-midi.
Le signal qui doit vous alerter
Une application qui redémarre seule, sans erreur explicite, manque presque toujours de mémoire : le système la coupe pour se protéger. Si vous observez des redémarrages inexpliqués, regardez la mémoire avant toute autre chose — vous perdriez sinon des heures à chercher un bogue qui n’existe pas.
Sécuriser le serveur lui-même
Point souvent traité après coup, alors qu’il devrait venir avant l’application. Un serveur exposé à internet est balayé en permanence par des recherches automatiques de machines vulnérables : ce n’est pas de la paranoïa, c’est la réalité de tout serveur public.
L’accès administrateur
Passez aux clés plutôt qu’aux mots de passe. Une clé ne se devine pas, et l’authentification par mot de passe peut être désactivée entièrement. C’est la mesure la plus efficace de toutes.
Interdisez la connexion directe du compte administrateur. Créez un compte ordinaire et utilisez l’élévation de privilèges quand c’est nécessaire. Cela supprime la cible la plus évidente.
Changez le port d’écoute si vous le souhaitez. Cela ne protège de rien contre une attaque ciblée, mais réduit considérablement le bruit dans vos journaux — ce qui rend les vraies anomalies visibles.
Le pare-feu
La règle est simple : tout fermer, puis ouvrir uniquement ce qui doit l’être. En pratique, trois ports : celui de l’administration, et les deux du trafic web. Rien d’autre.
Le piège le plus fréquent : laisser le port de l’application accessible directement, en plus du passage par le serveur web. On se retrouve alors avec une porte non chiffrée qui contourne toutes les protections mises en place devant. Vérifiez explicitement que seul le serveur web est joignable de l’extérieur.
Les mises à jour du système
Activez les mises à jour de sécurité automatiques. Elles s’installent seules, ne redémarrent rien d’important, et vous protègent des failles connues — qui représentent l’écrasante majorité des compromissions réelles.
La protection contre les tentatives répétées
Un outil qui bloque temporairement une adresse après plusieurs échecs d’authentification supprime en pratique toutes les attaques par essais successifs. Il s’installe en quelques minutes et se configure une fois.
Ces quatre mesures prennent une heure au total, la première fois. C’est le prix d’entrée de l’hébergement autonome, et il n’est pas négociable : votre instance détient les accès à votre messagerie, votre comptabilité et vos fichiers clients.
Le certificat et le renouvellement
Une instance de production doit être joignable en HTTPS avec un certificat valide. Ce n’est pas une question de confort : sans chiffrement, vos identifiants circulent en clair à chaque connexion.
Ce qu’il faut mettre en place
Un serveur web placé devant l’application joue le rôle d’intermédiaire : il reçoit le trafic chiffré, le déchiffre et le transmet à l’application en local. C’est l’architecture standard, et plusieurs solutions courantes obtiennent et renouvellent le certificat automatiquement.
Le point de vigilance : le renouvellement
Les certificats gratuits ont une durée de vie courte — quelques mois — et doivent être renouvelés automatiquement. Le renouvellement fonctionne en général tout seul ; il échoue silencieusement quand la configuration change, quand le domaine est déplacé, ou quand un pare-feu bloque la vérification.
Le symptôme est brutal : du jour au lendemain, votre navigateur affiche un avertissement de sécurité, et surtout les appels entrants échouent. Les services extérieurs refusent en général de contacter une adresse au certificat expiré. Vos automatisations déclenchées de l’extérieur s’arrêtent toutes en même temps.
La parade : une surveillance qui vérifie la date d’expiration une fois par semaine et vous prévient trente jours avant. C’est trois modules, et cela évite une panne générale un dimanche matin.
Les réglages d’une instance de production
Une installation par défaut fonctionne ; elle n’est pas prête pour la production. Six réglages font la différence.
L’adresse publique. L’application doit connaître sa propre adresse pour construire correctement les adresses de réception. Mal réglée, elle génère des adresses en local que personne ne peut appeler — et le symptôme est déroutant, puisque tout semble fonctionner de l’intérieur.
Le fuseau horaire. Sans réglage, tout raisonne en temps universel. Une automatisation planifiée à 8 h se déclenchera à 9 h ou 10 h selon la saison.
La clé de chiffrement. Définissez-la explicitement et conservez-la dans votre gestionnaire de mots de passe. Sans elle, une sauvegarde restaurée ne pourra jamais redonner accès à vos identifiants enregistrés.
L’authentification. Un compte, un mot de passe long et unique, et la double authentification si elle est disponible. Une instance ouverte donne accès à toutes vos connexions.
La conservation de l’historique. Quelques semaines suffisent. C’est le seul poste qui fait croître la base indéfiniment.
Le redémarrage automatique. Le service doit se relancer après un redémarrage du serveur et après un plantage. Sans ce réglage, une coupure d’électricité chez l’hébergeur arrête vos automatisations jusqu’à ce que vous vous en aperceviez.
Écrivez tous ces réglages dans un fichier de configuration versionné plutôt que dans une longue ligne de commande. Vous le relirez dans un an, et vous serez content qu’il existe.
Changer de base de données : quand et pourquoi
Une installation par défaut range tout dans une base légère, tenue dans un seul fichier. C’est parfait pour commencer, et cela devient insuffisant à un certain point.
Ce qui fonctionne très bien avec la base légère
Un usage individuel, quelques dizaines d’automatisations, quelques milliers d’exécutions mensuelles. La simplicité est un avantage réel : sauvegarder revient à copier un fichier.
Les trois signaux de bascule
Des exécutions simultanées nombreuses. La base légère supporte mal les écritures concurrentes : on observe des lenteurs et parfois des erreurs de verrouillage.
Un historique volumineux. Au-delà de quelques centaines de milliers d’enregistrements, les consultations deviennent lentes.
Un besoin de robustesse. Une base relationnelle complète offre de meilleures garanties en cas d’arrêt brutal, et des outils de sauvegarde à chaud — sans arrêter le service.
Comment procéder
La bascule n’est pas anodine : elle suppose de migrer les données existantes. Si vous savez dès le départ que votre usage sera soutenu, installez directement la base complète : c’est quelques lignes de configuration en plus, et cela vous évite une migration.
Si vous êtes déjà installé, ne basculez pas « par précaution ». Attendez d’observer l’un des trois signaux : la simplicité de la base légère a de la valeur tant que vous n’en atteignez pas les limites.
Mettre à jour sans rien casser
La procédure tient en cinq étapes et prend un quart d’heure. Elle n’est pas facultative.
1. Lisez les notes de version. Uniquement la section des changements de comportement. Cinq minutes, et vous saurez si cette version demande une attention particulière.
2. Sauvegardez. La base, la clé de chiffrement, le fichier de configuration. C’est votre retour arrière ; sans lui, une mise à jour problématique devient une soirée difficile.
3. Notez la version actuelle. Le détail qu’on oublie systématiquement, et sans lequel le retour arrière est impossible : on ne sait plus vers quoi revenir.
4. Mettez à jour et redémarrez. Quelques minutes d’indisponibilité. Choisissez un moment creux : les appels entrants reçus pendant cette fenêtre seront perdus, sauf si le service émetteur réessaie.
5. Vérifiez. L’interface répond, la liste des automatisations est complète, une connexion fonctionne, et une exécution de test aboutit. Deux minutes, et vous savez que tout va bien.
À quelle fréquence ?
Une fois par mois pour les versions courantes, immédiatement pour les correctifs de sécurité. Éviter les mises à jour n’est pas une stratégie : l’écart s’accumule, et une mise à jour après un an de retard est infiniment plus risquée que douze mises à jour mensuelles.
Restaurer : le test que personne ne fait
Une sauvegarde jamais restaurée est une hypothèse, pas une protection. Voici comment la vérifier.
La procédure. Une fois par trimestre, montez une seconde instance temporaire — sur le même serveur avec un port différent, ou sur une machine jetable. Restaurez-y votre sauvegarde. Vérifiez trois choses : les automatisations sont là, une connexion répond, et une exécution de test aboutit. Puis supprimez l’instance de test.
Un quart d’heure, quatre fois par an. C’est le prix de la certitude, et c’est ce qui distingue une sauvegarde d’une intention.
Les trois découvertes classiques
Ce test révèle presque toujours quelque chose. La sauvegarde ne contenait pas la clé de chiffrement — les automatisations reviennent, les identifiants restent illisibles. La tâche de sauvegarde avait cessé de fonctionner il y a trois mois sans que personne ne le remarque. Ou les sauvegardes étaient stockées sur le serveur lui-même, ce qui ne protège de rien en cas de perte du serveur.
Ces trois situations sont fréquentes, et chacune transforme une panne ordinaire en perte définitive. Le test trimestriel est le seul moyen de les découvrir avant qu’il ne soit trop tard.
Surveiller son instance : quatre signaux
Un serveur autonome ne vous prévient de rien. Voici le minimum à mettre en place, par ordre d’importance — et pour les pannes qui touchent une automatisation plutôt que le serveur, la marche à suivre est dans une exécution n8n qui échoue, la méthode de diagnostic.
1. L’instance répond-elle ? Une vérification extérieure toutes les cinq minutes, depuis un service gratuit ou depuis une autre automatisation. C’est la surveillance la plus importante : si l’adresse ne répond plus, tout est à l’arrêt.
2. Les automatisations produisent-elles quelque chose ? Un contrôle quotidien qui vérifie qu’il y a bien eu de l’activité. C’est ce qui attrape la panne silencieuse — celle qui ne lève aucune erreur.
3. Le disque se remplit-il ? Une alerte à 80 % d’occupation. Un disque plein arrête tout, et la cause est presque toujours l’historique ou d’anciennes images inutilisées.
4. Le certificat expire-t-il ? Une vérification hebdomadaire, avec alerte trente jours avant. Un certificat expiré coupe tous vos appels entrants d’un coup.
Ces quatre surveillances se construisent en une heure et coûtent quelques dizaines d’unités par mois. Elles transforment un serveur dont vous découvrez les pannes après coup en un serveur qui vous prévient — ce qui est toute la différence entre une infrastructure et un pari.
Les erreurs de mise en production les plus fréquentes
Laisser le port de l’application ouvert. Une porte non chiffrée à côté de celle qu’on a sécurisée. Vérifiez explicitement ce qui est joignable de l’extérieur.
Oublier de définir la clé de chiffrement. Tout fonctionne, jusqu’au jour de la restauration où les identifiants restent inaccessibles.
Sauvegarder sur le serveur lui-même. Une sauvegarde qui disparaît avec ce qu’elle protégeait ne protège rien.
Ne pas configurer le redémarrage automatique. Le serveur redémarre à trois heures du matin, le service ne se relance pas, et vous le découvrez le lundi.
Négliger le fuseau horaire. Des automatisations planifiées qui se déclenchent à côté, et des dates enregistrées avec un décalage qu’on découvre des semaines plus tard.
Migrer un vendredi. Le classique de tous les métiers techniques. Si quelque chose se passe mal, vous y passerez le week-end.
Aucune de ces erreurs n’est difficile à éviter : elles viennent toutes de la même chose — avoir voulu que l’instance « marche » sans prendre l’heure supplémentaire pour qu’elle tienne.
Le coût réel d’un serveur d’automatisation
Le chiffre qui circule — quelques euros par mois — est exact et incomplet. Voici le budget complet, tel qu’il se présente réellement sur une année.
Ce qui se paie en euros
Le serveur. Une machine correctement dimensionnée pour une petite structure coûte l’équivalent de deux ou trois cafés par mois chez la plupart des hébergeurs européens. C’est le poste le plus visible et le plus faible.
Le nom de domaine. Un sous-domaine de votre domaine existant ne coûte rien de plus. Si vous en achetez un dédié, comptez une dizaine d’euros par an.
Les sauvegardes externes. Un espace de stockage ailleurs que sur le serveur, indispensable. Quelques euros par an pour le volume concerné, parfois inclus dans un espace que vous payez déjà.
Les services appelés. Le poste qui surprend : modèles de langage, envois d’e-mails en volume, enrichissement de données. Il n’a rien à voir avec l’hébergement et il dépasse fréquemment le coût du serveur.
Ce qui se paie en temps
La mise en place : deux à quatre heures la première fois, en comptant la sécurisation et les sauvegardes. Moins d’une heure la fois suivante, parce que vous saurez.
L’entretien : une dizaine d’heures par an — mises à jour mensuelles, tests de restauration trimestriels, imprévus.
La montée en compétence : difficile à chiffrer, et ce n’est pas une perte. Ce que vous apprenez en administrant une instance vous servira pour tout ce que vous hébergerez ensuite.
La comparaison honnête
Face à une offre hébergée, l’arbitrage se pose ainsi : vous échangez un abonnement contre une dizaine d’heures annuelles. Valorisez ces heures à votre taux réel et comparez.
Pour beaucoup d’indépendants, le calcul penche vers l’offre hébergée — et il faut avoir l’honnêteté de le dire. L’hébergement autonome devient franchement gagnant dans trois cas seulement : un volume élevé qui ferait exploser une facturation à l’exécution, une contrainte de confidentialité qui interdit le transit par un tiers, ou un goût réel pour ce type de travail. Ce dernier critère n’est pas anecdotique : quelqu’un que le sujet intéresse fera l’entretien ; quelqu’un que cela ennuie le repoussera, et une instance non entretenue devient exactement le risque qu’elle devait écarter.
Vos trois premiers mois, mois par mois
Une mise en production réussie ne se joue pas le jour de l’installation. Voici le rythme qui produit une instance sur laquelle on peut compter.
Mois 1 — installer, sécuriser, sauvegarder
L’installation elle-même prend une soirée. Consacrez la seconde à ce qui compte vraiment : le pare-feu, les clés d’accès, le certificat, et surtout la sauvegarde automatique vers un espace extérieur.
Ne construisez encore aucune automatisation critique. Faites tourner deux ou trois choses sans enjeu, le temps de vérifier que l’instance tient une semaine sans intervention.
Mois 2 — surveiller, puis migrer
Mettez en place les quatre surveillances : disponibilité, activité, disque, certificat. Une heure de travail, et vous cessez de découvrir les problèmes après coup.
Migrez ensuite vos automatisations existantes, une par une, en gardant l’ancienne version désactivée. N’y consacrez pas plus de deux ou trois soirées : une migration précipitée est la première cause d’incident.
Mois 3 — éprouver
Le mois le plus important, et le plus négligé. Faites votre premier test de restauration complet. Faites votre première mise à jour en suivant la procédure. Provoquez volontairement une panne — arrêtez le service — et vérifiez que votre surveillance vous prévient.
À l’issue de ces trois exercices, vous saurez que votre instance tient. C’est une certitude très différente de « ça marche depuis deux mois » : la première se vérifie, la seconde s’espère.
Ensuite
Un quart d’heure par mois, un quart d’heure par trimestre. L’instance devient une infrastructure : quelque chose qui fonctionne sans qu’on y pense, et sur quoi on peut construire.
C’est là tout l’objectif. Un serveur d’automatisation réussi n’est pas celui qui a les meilleurs réglages : c’est celui dont vous n’entendez plus parler, et qui vous prévient de lui-même le jour où quelque chose ne va pas.
FAQ — vos questions fréquentes
Quel hébergeur VPS choisir ?
Tous les acteurs sérieux conviennent (Hostinger, Hetzner, OVH, Scaleway…). Critères utiles : datacenter en Europe (RGPD et latence), snapshots inclus, et une offre Docker prête à l’emploi pour gagner dix minutes. Évitez simplement les offres « mutualisées web » : il faut un vrai VPS.
2 Go de RAM, ça tient jusqu’à quel volume ?
Très loin pour un usage solo/PME : des dizaines de workflows et des milliers d’exécutions quotidiennes. Le jour où ça coince (files d’attente qui s’allongent), montez à 4 Go en deux clics chez l’hébergeur — sans réinstaller quoi que ce soit, c’est l’avantage de Docker.
Puis-je migrer mes workflows du n8n local vers le VPS ?
Oui, en cinq minutes : chaque workflow s’exporte en JSON (menu ⋯ → Download) et se réimporte sur le serveur. Les credentials se recréent (ils ne s’exportent pas, par sécurité — c’est une bonne chose).
n8n Cloud ne serait-il pas plus simple ?
Si, et c’est un excellent choix si vous ne voulez aucune maintenance (voir le comparatif cloud/self-host du module 3). Le VPS gagne sur trois tableaux : coût fixe à volume illimité, confidentialité totale, et contrôle complet. À vous de peser — vous avez maintenant les deux compétences.
Puis-je héberger d’autres services sur le même serveur ?
Techniquement oui, et c’est souvent une fausse économie. Le risque n’est pas la performance mais la contagion : un service qui consomme toute la mémoire fait tomber le vôtre, et une mise à jour de l’un peut casser l’autre. Si vous le faites, isolez chaque service dans son conteneur et fixez explicitement une limite de mémoire à chacun. Pour ce dont dépend votre facturation, un serveur dédié à quelques euros par mois reste le meilleur rapport tranquillité/prix.
Que se passe-t-il si mon hébergeur a une panne ?
Vos automatisations s’arrêtent, et les appels entrants reçus pendant la panne sont perdus si le service émetteur ne réessaie pas. C’est le risque assumé de l’hébergement autonome — les hébergeurs sérieux affichent des disponibilités très élevées, mais jamais totales. Deux atténuations : une surveillance extérieure pour être prévenu immédiatement, et pour les flux critiques, un rattrapage périodique qui va rechercher ce qui aurait pu manquer.
Faut-il un nom de domaine dédié ?
Un sous-domaine de votre domaine existant suffit parfaitement, et c’est la solution que nous recommandons : rien à acheter, et l’adresse reste cohérente avec votre identité. Évitez en revanche d’utiliser directement l’adresse numérique du serveur : vous ne pourriez pas obtenir de certificat valide, et changer de serveur vous obligerait à mettre à jour toutes les adresses déclarées chez vos partenaires.
Combien de temps faut-il vraiment consacrer à l’entretien ?
Comptez un quart d’heure par mois pour la mise à jour, un quart d’heure par trimestre pour le test de restauration, et une heure par an pour les imprévus. Soit une dizaine d’heures annuelles. Ce n’est pas énorme ; c’est un engagement régulier, ce qui n’est pas la même chose. Si vous savez que vous ne le tiendrez pas, l’offre hébergée est objectivement le meilleur choix — et il n’y a aucune honte à le reconnaître avant plutôt qu’après.
En résumé
Un VPS, un domaine, deux fichiers, quatre commandes : votre n8n de production tourne en HTTPS, webhooks compris, pour un coût fixe dérisoire. Prochaine étape du module : concevoir des workflows complexes qui restent maintenables.
Le Blueprint de l'automatisation no-code (37 pages) offert, puis un e-mail par semaine : une erreur qui coûte cher, un outil au banc d'essai, ou un cas réel décortiqué. Gratuit, désinscription en 1 clic.