Héberger n8n avec Coolify sur Hetzner en 2026

J'utilise Hetzner, Coolify et n8n pour garder la main sur mes déploiements et sur les automatisations qui tournent côté serveur. Cette stack évite d'assembler Docker, un reverse proxy et des certificats à la main, mais elle ne supprime pas le travail d'exploitation.

Le guide original de cet article contenait une ancienne URL d'installation Coolify, le mauvais port d'accès et une configuration n8n obsolète. Voici la version vérifiée au 13 août 2026. Elle convient à une petite installation. Un workflow critique exige en plus des sauvegardes restaurables, des alertes, un plan de reprise et une personne responsable des mises à jour.

Ce que chaque brique prend en charge

La répartition est simple :

Hetzner Cloud
└── Serveur Linux
    └── Coolify
        ├── Reverse proxy et certificats TLS
        ├── Applications web
        ├── n8n et sa base de données
        └── Service de monitoring

Hetzner Cloud fournit la machine, le réseau, les snapshots et le pare-feu de niveau cloud.
Coolify déploie et supervise les conteneurs, gère les domaines et le proxy.
n8n exécute les workflows et stocke leurs credentials, définitions et historiques.
Le monitoring vérifie que les services répondent et que les workflows importants se terminent.

Une panne du serveur affecte toutes ces briques si elles partagent la même machine. Cette architecture accepte donc un point de défaillance unique. Elle est adaptée à un budget serré et à des processus récupérables, pas à une exigence de haute disponibilité.

Choisir le serveur sans reprendre une ancienne fiche tarifaire

Le CX23 actuel n'a plus les caractéristiques indiquées dans l'ancienne version de ce guide. Hetzner le présente avec :

2 vCPU partagés ;
4 Go de RAM ;
40 Go de stockage ;
20 To de trafic inclus dans les régions européennes.

Coolify demande au minimum 2 coeurs, 2 Go de RAM et 30 Go d'espace libre. Un CX23 atteint donc le seuil technique, mais laisse peu de marge si la même machine construit une application Next.js, exécute n8n et conserve des données. Surveillez la RAM, le disque et la charge pendant les builds. Pour plusieurs services ou des workflows lourds, dimensionnez au-dessus ou utilisez un serveur de build séparé.

Depuis l'ajustement tarifaire du 15 juin 2026, Hetzner indique 5,49 EUR par mois hors TVA et hors IPv4 pour un nouveau CX23 en Allemagne ou en Finlande. Le prix d'une installation complète doit aussi inclure l'IPv4 éventuelle, les sauvegardes, le domaine et le stockage externe. Vérifiez toujours la grille Hetzner en vigueur avant de commander.

Pour un environnement de production, je pars sur une image Ubuntu LTS propre, dans une région européenne adaptée aux données traitées. La méthode d'installation automatique de Coolify prend officiellement en charge Ubuntu LTS 20.04, 22.04 et 24.04.

Préparer SSH et le pare-feu

Ajoutez votre clé SSH avant de désactiver l'authentification par mot de passe. Coolify utilise SSH même pour administrer le serveur sur lequel il est installé. Sa documentation recommande PermitRootLogin prohibit-password lorsque l'installation fonctionne avec le compte root.

Le pare-feu Hetzner est préférable à une règle UFW isolée. Docker ajoute des règles réseau qui peuvent contourner UFW. Pour l'installation self-hosted, Coolify documente les ports suivants :

Port	Usage
22	SSH, idéalement limité à vos adresses d'administration
80	HTTP et émission des certificats via le proxy
443	HTTPS
8000	Accès HTTP initial au tableau de bord Coolify
6001	Communications temps réel de Coolify
6002	Terminal Coolify sur les versions récentes

Après avoir relié le tableau de bord à un domaine protégé par le proxy intégré, la documentation du pare-feu Coolify indique que les ports 8000, 6001 et 6002 peuvent être fermés. Ne rendez pas directement publics les ports internes de n8n, de PostgreSQL ou des autres services.

Installer Coolify avec la commande actuelle

Sur un serveur neuf compatible, connectez-vous en SSH puis lancez la commande recommandée :

curl -fsSL https://cdn.coollabs.io/coolify/install.sh | sudo bash

Si la session est déjà ouverte en root, sudo n'est pas nécessaire. Le script installe les outils requis, Docker Engine, les répertoires sous /data/coolify et Coolify. Docker installé par Snap n'est pas pris en charge.

A la fin, le script affiche une URL de ce type :

http://203.0.113.1:8000

Ouvrez-la immédiatement et créez le premier compte administrateur. Tant que ce compte n'existe pas, une autre personne qui atteint la page d'inscription pourrait prendre le contrôle de l'instance. Le port correct est 8000, pas 3000.

La documentation d'installation Coolify reste la source à suivre si la commande ou les prérequis changent.

Relier un dépôt et déployer une application

Dans Coolify :

ajoutez la source GitHub avec les permissions minimales nécessaires ;
sélectionnez le dépôt et la branche de production ;
choisissez le mode de build adapté au projet, par exemple un Dockerfile présent dans le dépôt ;
déclarez les variables d'environnement dans Coolify, sans les committer ;
ajoutez le domaine et vérifiez le certificat ;
configurez un healthcheck qui teste une route applicative réelle ;
activez les notifications d'échec de déploiement.

Un push peut déclencher un déploiement via l'intégration GitHub, mais la durée varie selon le projet et les ressources. Ne basez pas une procédure de reprise sur une promesse de déploiement en deux minutes.

Déployer n8n sans configuration héritée

Coolify propose n8n comme service. Utilisez le modèle maintenu par la plateforme plutôt qu'un docker-compose copié depuis un ancien tutoriel. Le modèle doit conserver les données sur un volume persistant ou dans les services de données associés.

Les valeurs importantes dépendent du déploiement, mais vérifiez au minimum :

N8N_HOST=automation.example.com
N8N_PROTOCOL=https
N8N_EDITOR_BASE_URL=https://automation.example.com
WEBHOOK_URL=https://automation.example.com/
GENERIC_TIMEZONE=Europe/Paris
TZ=Europe/Paris
N8N_ENCRYPTION_KEY=<secret-long-et-stable>

Ne remettez pas les anciennes variables N8N_BASIC_AUTH_ACTIVE, N8N_BASIC_AUTH_USER et N8N_BASIC_AUTH_PASSWORD de ce guide. Utilisez la gestion des comptes intégrée à n8n, protégez le compte propriétaire avec un mot de passe unique et activez la double authentification lorsqu'elle est disponible.

La clé N8N_ENCRYPTION_KEY doit être sauvegardée dans un coffre distinct du serveur. Sans elle, une restauration de la base peut laisser les credentials chiffrés inutilisables.

N'exposez pas le port 5678 directement sur Internet. Coolify doit publier n8n derrière son proxy HTTPS. Pour des données métier, préférez PostgreSQL à une base locale isolée et sauvegardez la base ainsi que les fichiers persistants.

Sauvegarder ce qui permet réellement de repartir

Un snapshot Hetzner ne suffit pas comme seule sauvegarde. Il reste chez le même fournisseur et ne prouve pas qu'une restauration fonctionne.

Conservez hors du serveur :

une sauvegarde de la base n8n ;
la clé de chiffrement n8n ;
les variables et secrets nécessaires, dans un coffre ;
les données persistantes des autres services ;
la configuration DNS et la procédure de restauration ;
si nécessaire, des exports versionnés des workflows sans credentials.

Testez la restauration sur une instance séparée. Le test doit confirmer que n8n démarre, déchiffre les credentials, reçoit un webhook et exécute un workflow de contrôle.

Superviser le service et les workflows

Un test HTTP sur la page de connexion confirme seulement que le proxy et l'application répondent. Ajoutez au moins :

un contrôle HTTPS externe sur Kirako et n8n ;
une alerte sur l'espace disque et la mémoire ;
une notification sur les exécutions n8n en erreur ;
un workflow sentinelle qui s'exécute à intervalle régulier ;
une alerte si ce workflow ne produit plus son signal ;
un suivi des sauvegardes et de leur âge.

n8n fournit aussi une commande d'audit de sécurité qui signale notamment les credentials inutilisés, les webhooks non protégés, les noeuds à risque et une instance obsolète.

Mettre à jour sans casser la production

N'utilisez pas aveuglément le tag latest pour un service critique. Lisez les notes de version, sauvegardez, mettez à jour dans une fenêtre prévue et testez les workflows importants. Pour n8n, contrôlez en particulier les changements de version majeure, les noeuds communautaires et les paramètres d'exécution.

Le même principe s'applique à Coolify et au système d'exploitation. Une stack self-hosted donne du contrôle parce que l'équipe choisit quand et comment elle met à jour. Elle donne aussi la responsabilité de ne pas laisser les composants vieillir.

Le coût réel n'est pas seulement la facture du VPS

Le socle matériel peut rester peu coûteux. En revanche, une comparaison honnête inclut :

Poste	A prévoir
Serveur	Instance, IPv4 éventuelle, TVA
Données	Sauvegarde externe et rétention
Domaine	Enregistrement et DNS
Exploitation	Mises à jour, alertes, restauration
Incident	Temps de diagnostic et reprise

Le self-hosting peut réduire des abonnements et offrir plus de contrôle. Il n'est pas automatiquement moins cher si personne n'assume l'exploitation. Pour choisir entre cette approche et un service géré, partez du coût d'une interruption et du délai de reprise acceptable.

Sources officielles

Pour aller plus loin

Cette stack devient utile quand elle sert un processus précis, par exemple automatiser la facturation Pennylane avec n8n. Pour une entreprise, je commencerais par un workflow non critique, avec une sauvegarde et une alerte testées, avant d'y déplacer un processus qui bloque la facturation ou la relation client.

Si vous voulez garder n8n self-hosted sans porter seul les choix d'architecture et d'exploitation, la page consultant n8n pour entreprises détaille l'accompagnement Kirako.