Comment installer n8n avec Docker dans Plesk ?

Si vous déployez n8n via Plesk, vous associez la gestion de serveur con­vi­viale de Plesk à une solution d’au­to­ma­ti­sa­tion auto-hébergée et flexible. Vous pouvez ainsi connecter des outils, des in­ter­faces et des tâches ré­cur­rentes sans dé­ve­lop­pe­ment spé­ci­fique classique.

Étape 1 : vérifier les prérequis et choisir le serveur adapté

Avant de commencer l’ins­tal­la­tion pro­pre­ment dite, vous devez préparer soig­neu­se­ment deux éléments : d’une part, la base technique de votre serveur et, d’autre part, le bon di­men­sion­ne­ment de votre en­vi­ron­ne­ment. Avec n8n, une pla­ni­fi­ca­tion ri­gou­reuse est par­ti­cu­liè­re­ment im­por­tante, car les exigences peuvent fortement varier selon le nombre de workflows, de webhooks actifs, de services connectés et d’exé­cu­tions si­mul­ta­nées. Pour de petites au­to­ma­ti­sa­tions, une con­fi­gu­ra­tion compacte suffit souvent, tandis que les en­vi­ron­ne­ments de pro­duc­tion avec de nombreux processus né­ces­si­tent davantage de CPU, de RAM et de stockage.

Pour l’ins­tal­la­tion avec Plesk, vous avez prin­ci­pa­le­ment besoin des com­po­sants suivants :

• Un serveur Linux avec une ins­tal­la­tion Plesk fonc­tion­nelle
• Un domaine ou sous-domaine pour l’accès ultérieur à n8n
• Un cer­ti­fi­cat SSL valide
• L’extension Docker dans Plesk ; Plesk prend en charge Docker sur les systèmes Linux récents comme Debian 10 à 12 ainsi qu’Ubuntu 18.04 à 24.04
• Sous Linux, Plesk utilise NGINX comme serveur frontal, ce qui est également utile pour con­fi­gu­rer le reverse proxy de n8n

Cas d’usage 1 : uti­li­sa­teurs privés et petites startups

Si vous souhaitez utiliser n8n d’abord pour vous-même, pour un projet annexe ou pour une très petite équipe, une con­fi­gu­ra­tion de départ avec 4 vCores, 4 Go de RAM et 120 Go NVMe suffit gé­né­ra­le­ment. Cette con­fi­gu­ra­tion convient bien si vous n’exécutez que quelques workflows, par exemple des no­ti­fi­ca­tions issues de for­mu­laires, de simples au­to­ma­ti­sa­tions pour les réseaux sociaux ou de petits trans­ferts de données entre deux à quatre services. Cette taille est per­ti­nente pour l’ap­pren­tis­sage et les tests, car elle vous permet de tra­vail­ler dans des con­di­tions proches de la réalité sans sur­di­men­sion­ner inu­ti­le­ment l’in­fras­truc­ture.

Cas d’usage 2 : startups en crois­sance et petites équipes

Dès que n8n devient un outil utilisé ré­gu­liè­re­ment dans l’activité quo­ti­dienne, une base plus solide est ju­di­cieuse. Une con­fi­gu­ra­tion avec 6 vCores, 8 Go de RAM et 240 Go NVMe offre plus de marge pour plusieurs workflows n8n actifs, des tâches cron ré­cur­rentes, des in­ter­faces avec des systèmes de CRM ou de boutique en ligne, ainsi que les premiers usages pro­duc­tifs de webhooks. Cette variante est adaptée lorsque plusieurs personnes accèdent à l’en­vi­ron­ne­ment ou lorsque les au­to­ma­ti­sa­tions sont déjà intégrées dans des processus opé­ra­tion­nels. Cela inclut par exemple le trai­te­ment des leads, le routage d’emails, les no­ti­fi­ca­tions internes, des rapports simples ou des syn­chro­ni­sa­tions entre services SaaS.

Cas d’usage 3 : PME avec plusieurs processus métiers

Pour les petites et moyennes en­tre­prises qui sou­hai­tent utiliser n8n de manière pro­duc­tive dans plusieurs domaines, une con­fi­gu­ra­tion avec 8 vCores, 16 Go de RAM et 480 Go NVMe est nettement plus adaptée. Dans ce scénario, il ne s’agit gé­né­ra­le­ment plus seulement de processus auxi­liaires isolés, mais de vé­ri­tables chaînes de processus entre les ventes, le support, le marketing, l’E-commerce et les outils internes. Parmi les exemples typiques, on trouve la re­di­rec­tion au­to­ma­tique de tickets, les rap­pro­che­ments ERP ou boutique en ligne, la pré­pa­ra­tion de données pour les rapports, les processus de fac­tu­ra­tion ou encore le trai­te­ment de dé­clen­cheurs externes issus de for­mu­laires et de webhooks. De tels en­vi­ron­ne­ments génèrent une charge parallèle plus élevée et bé­né­fi­cient d’une mémoire vive sup­plé­men­taire afin d’éviter que les exé­cu­tions en cours ne pro­vo­quent des goulots d’étran­gle­ment.

Cas d’usage 4 : agences, pla­te­formes et en­vi­ron­ne­ments très sol­li­ci­tés

Si vous souhaitez exploiter n8n pour de nombreux clients, de nombreux projets ou dans un en­vi­ron­ne­ment fortement sollicité, il est pré­fé­rable de prévoir une con­fi­gu­ra­tion plus puissante. Une con­fi­gu­ra­tion avec 12 vCores, 24 Go de RAM et 720 Go NVMe offre nettement plus de réserves pour de nom­breuses exé­cu­tions si­mul­ta­nées, des workflows plus complexes et un plus grand nombre de systèmes connectés. Cela est par­ti­cu­liè­re­ment in­té­res­sant pour les agences qui gèrent plusieurs mandants, campagnes ou flux de données. Les pla­te­formes qui reçoivent en continu des entrées via des API et des webhooks peuvent également profiter d’un VPS de cette taille. Dans de tels scénarios, les pics de charge sont normaux. Une puissance CPU accrue réduit les temps d’attente, tandis qu’une RAM sup­plé­men­taire stabilise l’exécution des workflows plus longs ou plus gourmands en mémoire.

Aperçu des cas d’usage : quel serveur choisir ?

Étape 2 : préparer un domaine ou un sous-domaine pour n8n

Avant de créer le conteneur, vous devez définir à quelle adresse n8n devra ensuite être ac­ces­sible. En pratique, un sous-domaine dédié comme n8n.votre-domaine.fr est gé­né­ra­le­ment la solution la plus propre. Vous séparez ainsi clai­re­ment votre pla­te­forme d’au­to­ma­ti­sa­tion de votre site Web principal, tout en sim­pli­fiant la gestion du cer­ti­fi­cat TLS, du reverse proxy et de la main­te­nance ul­té­rieure. Comme n8n est exploité derrière Plesk avec un reverse proxy, une adresse cible clai­re­ment définie est par­ti­cu­liè­re­ment im­por­tante.

Créez d’abord le domaine ou sous-domaine souhaité dans Plesk. Veillez à ce que l’entrée DNS pointe déjà cor­rec­te­ment vers votre serveur. Ouvrez ensuite la section « Domaines » dans Plesk et vérifiez que le nouveau domaine y est visible. Pour les débutants, il est judicieux d’exploiter l’instance n8n sur un nouveau sous-domaine afin d’éviter que les con­fi­gu­ra­tions de site Web exis­tantes n’entrent en conflit avec la nouvelle ap­pli­ca­tion.

Close

Étape 3 : activer SSL pour le domaine

Avant de rendre n8n ac­ces­sible pu­bli­que­ment, vous devez sécuriser le domaine avec HTTPS. Grâce à son in­té­gra­tion Let’s Encrypt, Plesk offre un moyen pratique de fournir et de re­nou­ve­ler gra­tui­te­ment des cer­ti­fi­cats SSL. Cela est important pour l’ex­ploi­ta­tion de n8n, car de nombreux services externes n’acceptent les webhooks ou les re­di­rec­tions OAuth que via HTTPS. De plus, les con­nexions, appels API et données de workflows ne doivent jamais être ac­ces­sibles sans chif­fre­ment.

Ouvrez dans Plesk le domaine concerné et activez-y un cer­ti­fi­cat SSL.

Close

Si Let’s Encrypt est déjà installé, vous pouvez demander le cer­ti­fi­cat di­rec­te­ment via l’interface. Ensuite, activez de pré­fé­rence une re­di­rec­tion au­to­ma­tique de HTTP vers HTTPS afin que tous les appels soient cor­rec­te­ment chiffrés. Dans ce menu, vous pouvez aussi té­lé­char­ger ou dé­sins­tal­ler des cer­ti­fi­cats existants.

Close

Étape 4 : installer l’extension Docker dans Plesk

L’ins­tal­la­tion de n8n avec Docker convient à de nombreux scénarios d’auto-hé­ber­ge­ment, car l’ap­pli­ca­tion peut ainsi être gérée de manière isolée, propre et re­la­ti­ve­ment simple. C’est pré­ci­sé­ment pour cette raison que l’extension Docker est la méthode la plus per­ti­nente pour déployer n8n avec Plesk. Plesk prend en charge Docker sur les versions Linux récentes et permet de gérer les con­te­neurs di­rec­te­ment via l’interface d’ad­mi­nis­tra­tion.

Ouvrez dans Plesk la section « Ex­ten­sions » et installez-y l’extension Docker si elle n’est pas encore présente.

Close

Après l’ins­tal­la­tion, une rubrique Docker dédiée apparaît dans la na­vi­ga­tion de gauche. Vous pouvez y re­cher­cher des images, créer des con­te­neurs Docker, attribuer des ports et définir des variables d’en­vi­ron­ne­ment.

Close

Étape 5 : créer le conteneur n8n dans Plesk

Dans l’étape suivante, vous con­fi­gu­rez le conteneur n8n pro­pre­ment dit. Pour cela, re­cher­chez dans l’extension Docker l’image of­fi­cielle « n8nio/n8n » et créez un nouveau conteneur à partir de celle-ci.

Close

En interne, n8n fonc­tionne par défaut sur le port 5678. Ce port doit donc être dis­po­nible dans le conteneur. Comme port hôte, vous pouvez par exemple utiliser 5678 ou un autre port local libre, idéa­le­ment destiné au routage via Plesk plutôt qu’à une ex­po­si­tion directe. Dans Plesk, il est judicieux d’attribuer ma­nuel­le­ment un port hôte fixe plutôt que d’utiliser le mappage au­to­ma­tique des ports, car la règle de proxy peut ainsi être con­fi­gu­rée plus clai­re­ment. De plus, il est important que vos données n8n soient stockées de manière per­ma­nente. Créez donc pour le conteneur un volume ou ré­per­toire per­sis­tant monté sur /home/node/.n8n, car ce dossier contient notamment les workflows, les iden­ti­fiants et la clé de chif­fre­ment.

Close

Étape 6 : créer les variables d’en­vi­ron­ne­ment

Pour la con­fi­gu­ra­tion de base, vous devez définir quelques variables d’en­vi­ron­ne­ment. Elles per­met­tent à n8n d’iden­ti­fier cor­rec­te­ment l’adresse à laquelle l’ap­pli­ca­tion est ac­ces­sible et la manière dont elle doit com­mu­ni­quer avec l’extérieur. Cette étape est par­ti­cu­liè­re­ment im­por­tante lorsque n8n est utilisé derrière un reverse proxy comme Plesk, car l’ap­pli­ca­tion fonc­tionne en interne sur un autre port que celui utilisé par les visiteurs dans leur na­vi­ga­teur.

Les variables N8N_HOST, N8N_PROTOCOL, WEBHOOK_URL et N8N_PROXY_HOPS sont par­ti­cu­liè­re­ment im­por­tantes. Avec ces pa­ra­mètres, vous indiquez à n8n sous quel domaine l’instance est ac­ces­sible, si HTTPS est utilisé et si un reverse proxy est placé devant l’ap­pli­ca­tion.

Si votre instance n8n doit être ac­ces­sible via https://n8n.votre-domaine.fr, vous pouvez vous baser sur les valeurs suivantes :

N8N_HOST=n8n.votre-domaine.fr
N8N_PROTOCOL=https
WEBHOOK_URL=https://n8n.votre-domaine.fr/
N8N_PROXY_HOPS=1
TZ=Europe/Paris
GENERIC_TIMEZONE=Europe/Paris

Dans Plesk, vous saisissez gé­né­ra­le­ment ces valeurs di­rec­te­ment dans la boîte de dialogue du conteneur, sous « Variables d’en­vi­ron­ne­ment ».

Close

Étape 7 : con­fi­gu­rer une règle de proxy Docker dans Plesk

Afin que les uti­li­sa­teurs puissent accéder à votre instance n8n via le nom de domaine sur le port 443, vous devez créer une règle de proxy Docker dans Plesk. Les requêtes adressées au domaine sont alors trans­mises par NGINX vers le port local du conteneur. Vous évitez ainsi aux uti­li­sa­teurs de devoir saisir un port in­ha­bi­tuel dans l’URL.

Ouvrez pour cela dans Plesk la section « Sites Web et domaines » de votre sous-domaine n8n et sé­lec­tion­nez « Règles de proxy Docker » ou « Docker Proxy Rules », selon la langue de votre interface. Créez une nouvelle règle, choi­sis­sez le conteneur n8n et associez le port pré­cé­dem­ment mappé. Pour un sous-domaine dédié, il est gé­né­ra­le­ment plus simple d’acheminer l’ensemble du domaine vers le conteneur. NGINX se charge ensuite de la trans­mis­sion des requêtes vers le port du conteneur fonc­tion­nant en local.

Close

Étape 8 : ouvrir n8n dans le na­vi­ga­teur et terminer la première con­fi­gu­ra­tion

Une fois le conteneur, le cer­ti­fi­cat TLS et la règle de proxy con­fi­gu­rés, vous pouvez saisir l’URL de votre instance n8n dans le na­vi­ga­teur. Si tout est cor­rec­te­ment paramétré, l’interface devrait être ac­ces­sible di­rec­te­ment via votre domaine en HTTPS. Au premier démarrage, n8n vous guide à travers la con­fi­gu­ra­tion de base, par exemple pour créer le premier compte uti­li­sa­teur.

Étape 9 : exploiter n8n de façon sécurisée et main­te­nable

Si votre instance doit être utilisée en pro­duc­tion, il ne faut pas vous en tenir à la simple ins­tal­la­tion de base. Les éléments les plus im­por­tants sont notamment les mises à jour ré­gu­lières, les sau­ve­gardes du ré­per­toire de données per­sis­tant et une con­fi­gu­ra­tion TLS propre. Vous réduisez ainsi con­si­dé­ra­ble­ment les risques de pannes, de pertes de con­fi­gu­ra­tion et de problèmes de sécurité.

D’un point de vue or­ga­ni­sa­tion­nel, il est judicieux d’exploiter n8n comme une ap­pli­ca­tion à part entière, avec son propre sous-domaine, son propre ré­per­toire de données et une con­fi­gu­ra­tion de proxy claire. Vous pouvez ainsi effectuer les mises à jour, les sau­ve­gardes et d’éven­tuelles re­cherches d’erreurs de manière nettement plus struc­tu­rée. Si vos workflows se dé­ve­lop­pent ou que plusieurs personnes tra­vail­lent avec l’outil, l’en­vi­ron­ne­ment pourra plus fa­ci­le­ment être migré vers des res­sources de serveur plus puis­santes. Le choix initial du serveur n’est donc pas seulement une question de prix, mais une base im­por­tante pour un fonc­tion­ne­ment stable.