Auto-héberger n8n sur Coolify

n8n est un outil d'automatisation de flux de travail. Vous enchaînez des appels HTTP, des requêtes de base de données, des intégrations d'API et des scripts, puis vous les exécutez selon un horaire ou un déclencheur. Il rivalise avec Zapier et Make, avec une différence importante : vous pouvez l'exécuter sur votre propre serveur.

Cela vaut la peine d'y réfléchir avant de vous engager. Chaque flux que vous construisez contient les identifiants des services qu'il touche : votre CRM, votre base de données, votre fournisseur de courriel, votre hébergeur Git. Chaque exécution enregistre les données d'entrée et de sortie. Sur une plateforme d'automatisation hébergée, tout ça repose sur l'infrastructure de quelqu'un d'autre, selon son calendrier et sous sa juridiction.

Cet article explique comment déployer n8n sur Coolify (en anglais) à partir de son catalogue de services en un clic. Si vous n'avez jamais rien déployé sur Coolify, commencez par notre guide de déploiement Coolify, puis revenez ici.

Pourquoi l'auto-héberger

Trois raisons, à peu près dans l'ordre de fréquence où elles reviennent.

Vos données restent où vous les mettez. Les définitions de flux, les identifiants des services connectés et l'historique d'exécution vivent tous dans le stockage de votre instance n8n. Rien d'une exécution ne quitte votre serveur, sauf si le flux lui-même l'envoie ailleurs.

Pas de tarification à l'exécution. n8n Cloud facture selon un quota mensuel d'exécutions propre à chaque forfait. Ce modèle convient quand le volume est prévisible, moins quand il ne l'est pas. Un flux qui interroge une API chaque minute épuise un quota rapidement. En auto-hébergement, votre coût est celui du serveur, et le serveur se moque de savoir si vous lancez 500 exécutions ou 500 000.

Vous contrôlez la version et l'environnement. C'est vous qui décidez du moment de la mise à niveau, des variables d'environnement et des dépendances supplémentaires à installer.

Une note sur la licence : n8n est publié sous la Sustainable Use License, une licence à code source disponible que n8n qualifie de « fair-code » plutôt que de logiciel libre au sens de l'OSI. La licence autorise l'usage interne de votre entreprise, ainsi que l'usage personnel et non commercial. Auto-héberger vos propres flux entre dans ce cadre. Fournir n8n à des tiers à des fins commerciales, non : ni en le revendant comme service hébergé, ni en intégrant ses fonctions à un produit que vous vendez. Il faut alors une entente distincte avec n8n. Lisez la licence avant de bâtir quoi que ce soit par-dessus.

Étape 1 : créez le service

n8n figure au catalogue de services en un clic de Coolify, qui lui consacre même une page de documentation. C'est le chemin utilisé ici, parce que le modèle configure déjà l'image, le réseau et les variables d'environnement dont le conteneur a besoin.

Dans votre projet, ajoutez une nouvelle ressource, choisissez Service, puis cherchez n8n dans le catalogue. Coolify propose plusieurs variantes :

• n8n seul, qui utilise SQLite pour le stockage
• n8n avec PostgreSQL, qui ajoute un conteneur de base de données
• n8n avec PostgreSQL et worker, qui ajoute un conteneur worker distinct et une instance Redis pour que les exécutions passent par une file d'attente hors du processus principal

La variante avec worker lance le plus de conteneurs et c'est celle conçue pour l'exécution en file d'attente. Si vous hésitez, les variantes simple ou PostgreSQL sont plus faciles à suivre, et les modèles du catalogue ne sont que des fichiers compose que vous pourrez modifier plus tard.

Étape 2 : configurez le domaine pour obtenir le SSL

Avant de déployer, attribuez un domaine au service. Le proxy de Coolify s'occupe du TLS avec Let's Encrypt automatiquement dès qu'un domaine est configuré et que le DNS pointe vers votre serveur.

1. Créez un enregistrement A pour le sous-domaine voulu, par exemple n8n.example.com, vers l'adresse IP de votre serveur.
2. Dans la configuration du service, associez ce domaine au conteneur n8n.
3. Déployez.

Cette étape n'a rien de cosmétique. n8n doit connaître sa propre adresse publique, et dans un service Coolify, c'est le domaine attribué qui alimente les variables qui la lui donnent.

Étape 3 : vérifiez les variables d'hôte et de webhook

Coolify génère des variables de domaine à partir du FQDN attribué. Deux d'entre elles comptent ici :

• SERVICE_FQDN_N8N contient seulement le nom d'hôte, par exemple n8n.example.com
• SERVICE_URL_N8N contient l'URL complète avec le protocole, par exemple https://n8n.example.com

Le modèle de service n8n branche ces valeurs sur les variables que n8n lit, dont N8N_HOST, N8N_PROTOCOL, N8N_EDITOR_BASE_URL et l'URL de webhook. Ouvrez l'onglet des variables d'environnement du service après avoir attribué le domaine et vérifiez que les valeurs sont correctes.

Portez attention à la différence entre les deux. Un bogue signalé dans le modèle n8n de Coolify remplissait l'URL de base de l'éditeur et l'URL de webhook à partir de la variable sans protocole. Cela casse les rappels OAuth avec n8n 2.0 et les versions suivantes, puisque ces URL exigent le préfixe https://.

La correction consiste à pointer les deux vers la variable contenant l'URL complète. Les versions plus récentes du modèle le font peut-être déjà, alors lisez vos propres valeurs avant de connecter un identifiant Google, Microsoft ou LinkedIn, pas après.

Étape 4 : créez le compte propriétaire tout de suite

Au premier lancement, n8n affiche un écran de configuration et le premier compte créé devient le propriétaire de l'instance. La documentation de n8n exige au minimum huit caractères, dont au moins un chiffre et une majuscule.

Faites-le dès que le déploiement se termine. Tant que la configuration n'est pas complétée, quiconque peut joindre l'instance peut en revendiquer la propriété. Un domaine public avec un certificat valide est joignable par définition.

Comment les webhooks se résolvent réellement

n8n construit ses URL de webhook à partir de N8N_PROTOCOL, N8N_HOST et N8N_PORT. Derrière un proxy inverse, ce qu'est précisément un service Coolify, ce calcul donne l'adresse interne plutôt que votre adresse publique. La documentation de n8n traite ce cas directement : définissez l'URL de webhook explicitement pour que n8n affiche la bonne URL dans l'éditeur et enregistre la bonne URL auprès des services externes.

La documentation de n8n précise aussi que N8N_WEBHOOK_URL remplace l'ancienne WEBHOOK_URL, et que l'ancien nom déclenche un avertissement de dépréciation. Beaucoup de modèles utilisent encore l'ancien nom, alors vérifiez lequel votre version attend.

Le symptôme d'une erreur ici est précis et déroutant : le flux se déclenche depuis l'URL de test dans l'éditeur, et le webhook de production n'arrive jamais. C'est parce que l'URL transmise au service externe pointe vers un endroit qu'il ne peut pas atteindre.

Persistance, clé de chiffrement et mises à niveau

Les services Coolify conservent leurs données dans des volumes Docker. Arrêter puis redémarrer un service ne les efface donc pas. Pour n8n, cela inclut le répertoire de données, et pour les variantes PostgreSQL, aussi le volume de la base de données.

Un élément mérite une attention particulière. n8n génère une clé de chiffrement aléatoire au premier lancement, la conserve dans son répertoire de données .n8n et s'en sert pour chiffrer les identifiants avant leur écriture en base. Restaurez une base sans cette clé et les identifiants qu'elle contient deviennent indéchiffrables.

Vous pouvez définir vous-même N8N_ENCRYPTION_KEY au lieu de laisser n8n en générer une. La clé devient alors un élément que vous gérez sciemment, plutôt qu'une valeur enfouie dans un volume.

Pour mettre à niveau, utilisez l'option de l'interface du service qui récupère les dernières images et redémarre. Fixez une version dans le fichier compose si vous préférez décider exactement du moment où la version change.

Sauvegardes

Coolify intègre des sauvegardes planifiées pour les bases de données. Sur une ressource de base de données, vous définissez un horaire cron, un nombre de sauvegardes à conserver et une destination compatible S3, et Coolify exécute le vidage pour vous. Si vous utilisez la variante PostgreSQL du service n8n, ça couvre vos flux et votre historique d'exécution.

Sauvegardez séparément la clé de chiffrement et le volume de données n8n. Un vidage de base seul ne constitue pas une restauration complète.

Consultez notre guide des sauvegardes pour voir comment ça fonctionne sur un serveur MapleDeploy et ce que nous prenons en charge au niveau de la machine virtuelle (VM).

L'angle canadien

Les flux d'automatisation accumulent des données d'affaires sans que personne ait vraiment décidé qu'ils le feraient. Un flux qui synchronise des commandes contient des dossiers clients. Un flux qui ouvre des billets de soutien contient tout ce que les clients ont écrit. Et les identifiants stockés dans l'instance donnent souvent accès à bien plus que les flux eux-mêmes.

Décidez donc sciemment ce qu'un flux a le droit de manipuler. Notre politique d'utilisation acceptable et nos conditions excluent certaines catégories d'emblée : renseignements de santé ou médicaux, données de cartes de paiement, identifiants gouvernementaux ou de comptes financiers. n8n enregistre les données d'entrée et de sortie de chaque exécution. Un flux qui ne fait que transporter ces données finit donc quand même par les stocker.

MapleDeploy exploite Coolify géré sur des machines virtuelles dédiées à Toronto. Quand vous déployez n8n comme service sur ce serveur, toute l'instance y reste : le conteneur, la base de données, l'historique d'exécution et les identifiants chiffrés. Aucun intermédiaire américain, et aucune exposition au CLOUD Act pour votre serveur et ses données. Voyez hébergement canadien pour les détails de juridiction.

Chaque serveur est une VM dédiée, pas une infrastructure partagée. Le forfait Starter offre 4 Go de RAM et 2 vCPU à 45 $ CAD/mois, et vous pouvez déployer n8n aux côtés de vos autres applications sur la même instance Coolify. Le forfait qui vous convient dépend de votre volume d'exécutions.