- Cet article est une checklist documentant en détail, étape par étape, la procédure d’auto-hébergement sur VPS avec Hetzner et Coolify
- Hetzner est recommandé pour sa faible latence en Europe, son excellent rapport qualité/prix et sa tarification transparente
- Il couvre aussi des sujets fréquents en pratique comme le setup initial du serveur axé sécurité, la sécurisation SSH, le pare-feu et la configuration des mises à jour automatiques
- Il explique en détail la mise en place d’un environnement de production, la supervision, les sauvegardes et le dépannage pour déployer une application Node.js en toute sécurité
- C’est un guide pratique pour développer ses compétences DevOps et sa capacité à administrer librement son propre serveur
Checklist de préparation au setup d’un VPS
- Dans la partie consacrée au choix d’un fournisseur de VPS, Hetzner est cité comme recommandation pour son rapport prix/performances
- Il faut choisir une configuration avec au minimum 1 Go de RAM et 20 Go de stockage, et noter l’adresse IP du serveur ainsi que les informations du compte root
- Prévoir un client SSH sur la machine locale et utiliser un générateur de mots de passe robustes
Pourquoi choisir ce fournisseur VPS
- Hetzner Cloud est peu coûteux, rapide et fiable en Europe
- Alternatives : DigitalOcean (excellent onboarding/documentation, mais prix en hausse), AWS Lightsail (dépendance à AWS, plus difficile pour les débutants), Linode (stable mais moins compétitif sur le prix), Render/Fly.io (pratiques en PaaS, mais plus coûteux et avec davantage de contraintes)
- Hetzner est 2 à 3 fois moins cher à configuration équivalente, sans facturation opaque, avec l’avantage de ses datacenters européens
Checklist de setup initial du serveur
Première connexion et mise à jour du système
- Mise à jour de la liste des paquets et upgrade du système
- Commandes fournies pour vérifier les informations système (ex. :
uname -a, cat /etc/os-release)
Sécurisation du compte root
- Définir un mot de passe complexe et le conserver de façon sécurisée
- Créer un compte utilisateur unique au lieu de noms conventionnels comme
admin ou user
- Accorder les droits sudo au nouveau compte et vérifier qu’ils sont bien appliqués
Configuration de l’authentification par clé SSH
- Générer sur la machine locale une paire de clés Ed25519 (recommandé) ou RSA
- Ajouter la clé publique dans
.ssh/authorized_keys sur le serveur puis configurer les permissions
- Vérifier que la connexion SSH par clé fonctionne correctement (connexion sans saisie de mot de passe)
- Désactiver l’authentification par mot de passe et vérifier aussi, si nécessaire, les fichiers cloud-init séparés
- Redémarrer le démon SSH et vérifier qu’il fonctionne normalement
- Désactiver la connexion root pour bloquer l’accès root à distance
Checklist de configuration du pare-feu
Configuration de base d’UFW
- Refuser par défaut tout trafic entrant, autoriser le trafic sortant
- Autoriser les ports SSH, HTTP (80) et HTTPS (443), puis vérifier qu’UFW est bien appliqué
- Option : restreindre le port SSH à certaines IP et changer le numéro de port (dans une logique de durcissement) pour ajouter une couche de défense supplémentaire
Checklist de configuration des mises à jour automatiques
Configuration de Unattended Upgrades
- Installer les paquets
unattended-upgrades et apt-listchanges, puis accepter l’activation par défaut
- Décommenter les mises à jour de sécurité et, si besoin, configurer les notifications par e-mail ainsi que l’option de redémarrage automatique
- Tester le fonctionnement des mises à jour automatiques et vérifier leur état
Checklist de déploiement d’une application en production
Mise en place de l’environnement Node.js
- Installer Node.js LTS et vérifier la version
- Envoyer les fichiers de l’application sur le serveur, puis installer les dépendances pour préparer l’exploitation en production
Utilisation du gestionnaire de processus PM2
- Lancer l’application avec PM2 en mode production, avec option de clustering
- Configurer le démarrage automatique de PM2 au boot et fournir les commandes de redémarrage/supervision
Configuration du reverse proxy Nginx
- Créer le fichier de configuration du site Nginx et appliquer le proxy pass
- Activer le site et redémarrer Nginx
Checklist de configuration du certificat SSL
Let's Encrypt et Certbot
- Installer
certbot et python3-certbot-nginx, puis émettre automatiquement un certificat SSL basé sur le domaine
- Configurer l’automatisation du renouvellement et tester la validité du certificat
Checklist de supervision et de maintenance
Méthodes de supervision de base
- Installer des outils de vérification des ressources système comme
htop et iotop
- Mettre en place la surveillance en temps réel des logs
syslog, auth.log, ainsi qu’une politique de rotation des logs (logrotate)
Stratégie de sauvegarde
- Écrire un script de sauvegarde de l’application et de la base de données avec
tar
- Effectuer des sauvegardes régulières selon un planning (
crontab)
Checklist de dépannage
Problèmes de connexion SSH
- Vérifier la configuration du pare-feu, l’état du service SSH, les logs d’authentification et le réseau
Erreurs liées aux permissions
- Vérifier les permissions des fichiers/dossiers, les groupes et la configuration sudo
Service qui ne démarre pas
- Contrôler l’état et les logs avec
systemctl et journalctl, et vérifier la syntaxe des fichiers de configuration
Utilisation excessive des ressources
- Analyser les processus, le disque, le réseau et les logs applicatifs
Checklist de validation finale
Vérification de la sécurité
- Vérifier que tous les points fonctionnent : authentification par clé SSH, connexion par mot de passe, connexion root, pare-feu, mises à jour automatiques, mode production, SSL, sauvegardes, etc.
Test de performance
- Effectuer des tests de charge avec Apache Bench, surveiller les ressources et vérifier les erreurs dans les logs
Liste rapide de commandes de référence
Vérification des informations système
htop, df -h, free -h, uname -a
Gestion des processus
pm2 status, pm2 restart all, pm2 logs, pm2 monit
Sécurité
sudo ufw status, sudo fail2ban-client status, sudo lynis audit system
Gestion des services
sudo systemctl status nginx, sudo systemctl restart nginx, sudo journalctl -u nginx
Conclusion
- Cette checklist fournit une procédure complète de setup et d’administration d’un VPS
- Elle permet d’obtenir non seulement un faible coût, mais aussi la gestion directe, l’apprentissage et l’autonomie DevOps
- L’auto-hébergement avec Hetzner et Coolify permet d’acquérir confiance et liberté grâce à une expérience concrète
- C’est un contenu jouant le rôle de guide pratique pour celles et ceux qui veulent se lancer dans l’hébergement sur VPS
1 commentaires
Commentaire Hacker News
Je trouve que c’est un très bon résumé pour les débutants comme moi, je vais clairement le mettre en favori.
Cela dit, c’est dommage que Coolify soit mentionné dans le titre alors qu’il est à peine évoqué dans le corps de l’article.
Parmi les autres bons articles utiles sur un sujet proche, il y a « Setting up a Production-Ready VPS from Scratch », que j’ai aussi mis en favori via le lien ci-dessous.
https://dreamsofcode.io/blog/setting-up-a-production-ready-vps-from-scratch
Quand je veux comprendre ce type de sujet plus en profondeur, je mets généralement le lien de l’article dans un LLM avec un prompt du genre :
"Ceci est un article sur le ‘sujet/titre’ : https://article.link. Comprends-le bien, analyse-le, puis développe chaque section avec tes connaissances et ajoute aussi des sections complémentaires pertinentes."
C’est comme ça que j’apprends.
https://www.youtube.com/watch?v=taJlPG82Ucw
J’utilise cette configuration depuis environ un an, et c’est la première fois que l’auto-hébergement m’a semblé réellement accessible.
OVH est tout aussi fiable que Hetzner, et propose actuellement des offres bien moins chères.
https://us.ovhcloud.com/vps/configurator/?planCode=vps-2025-model3&brick=VPS%2BModel%2B3&pricing=upfront12&processor=%20&vcore=8__vCore&storage=200__SSD__NVMe
Si j’utilise Coolify, j’hésite sur la distribution à choisir.
J’hésite entre Ubuntu 24.04 et Debian 13 pour savoir lequel serait le meilleur choix.
OVH VPS — 24 vCPU (ou threads), 96 Go de RAM pour 53,4 $/mois.
Hetzner VPS (option AMD) : 16 vCPU, 32 Go, 54,9 $/mois.
DO Droplet : 16 vCPU, 64 Go de RAM pour 504 $/mois.
Linode et Upcloud sont aussi bien plus chers, à 576 $/mois pour 24 à 20 vCPU et 96 Go de RAM, comparés à OVH.
Je ne sais pas quel CPU utilise OVH, mais même en tenant compte de l’écart de prix, ce serait une offre plutôt correcte même si c’était un CPU Intel E-Core.
À noter que Hetzner a aussi une option Intel vCPU moins chère, mais sur du matériel ancien, et les créneaux ne se libèrent qu’en cas d’annulation par d’autres clients.
J’ai donc pris uniquement l’option AMD récente comme base de comparaison.
Le seul vrai problème chez OVH, c’est qu’il faut envoyer une copie de sa pièce d’identité pour louer un VPS (autour de 30 $/mois).
Je n’ai pas envie de diffuser mes données personnelles comme ça, donc j’ai finalement choisi une option plus chère.
D’après mon expérience, certes pas très longue, les serveurs cloud Hetzner étaient nettement meilleurs en performances que les VPS OVH.
Je suis satisfait des deux, cela dit.
Je me demande pourquoi OVH et Hetzner sont à ce point moins chers que les autres fournisseurs.
Je peux le comprendre dans une certaine mesure pour les VPS, puisqu’ils sont plus mutualisés que d’autres, mais ces deux acteurs proposent aussi des serveurs dédiés très bon marché.
Je me demande s’il y a un piège quelconque, ou si les prix d’OVH ont changé récemment.
Dans mon souvenir, c’était plus cher que Hetzner il y a quelques années.
Tous les CPU mentionnés ici sont très probablement en réalité des ressources partagées.
Et ils ne publient pas le degré réel de mutualisation.
Chez Hetzner, il existe aussi des serveurs avec le même nombre de cœurs pour la moitié du prix.
Ce n’est pas visible en surface, mais si on teste directement les performances, les serveurs moins chers n’offrent en pratique que la moitié des performances.
En désactivant les deux réglages CSS ci-dessous, l’UI/UX du blog s’est énormément améliorée.
pre {
margin: 2rem 0 !important;
padding: 1rem !important;
}
Les blocs de code avaient trop de padding et de marge, si bien qu’on ne voyait que trois lignes à l’écran.
Et si on installe Webmin/Virtualmin, des tâches comme l’ajout de nouveaux sous-domaines ou d’utilisateurs deviennent bien plus simples.
J’ai cliqué parce que Coolify m’intéressait, mais en réalité il n’est mentionné que dans les tags, l’introduction et la conclusion, pas dans le corps du texte.
Je trouve donc que la mention de Coolify n’est pas appropriée.
Cet article parle en réalité de la préparation d’un VPS pour un déploiement avec Coolify.
Il ne traite pas de l’installation de Coolify elle-même.
Jusqu’à présent, je gère tous mes services sur une VM avec Docker Compose, donc j’ai cliqué pour voir si Coolify constituait une alternative nettement meilleure à cette approche.
Mais il n’y avait en fait aucun vrai contenu sur Coolify, et les tâches manuelles de préparation pour Coolify semblaient au contraire plus complexes.
Mon approche, qui consiste à « utiliser une image de base Docker Compose et ajuster seulement quelques points », m’a paru bien plus simple.
J’en ai conclu que ma méthode restait tout à fait valable.
L’avantage, c’est qu’une migration entre hôtes se règle à 99 % en copiant simplement un seul fichier YAML Docker Compose.
J’ai essayé Coolify il y a quelques mois, et j’ai rencontré toutes sortes de problèmes quand plusieurs conteneurs étaient reliés via Compose.
Par exemple, j’oubliais qu’un conteneur était déjà lancé et je le redémarrais en doublon, ou bien les deux tournaient mais Coolify n’en détectait qu’un seul.
Quand on enregistre chaque service séparément dans Coolify, ça fonctionne à peu près correctement.
Au final, je suis moi aussi revenu à une configuration autonome basée sur Docker Compose, et c’était même bien plus simple à exploiter.
Je pense qu’une tentative comme Coolify est vraiment nécessaire, mais à l’heure actuelle ce n’est pas encore assez mûr pour un usage en vraie production.
Tant que Coolify ou des projets similaires ne prendront pas en charge les sauvegardes de base de données et la réplication en streaming, cela restera dans le domaine du hobby.
J’exploite deux VM avec Docker Compose et des scripts bash, et le simple fait de mettre en place des sauvegardes horaires sur S3, du wal streaming, ainsi que la réplication en streaming de PG et Redis suffit selon moi à couvrir le minimum requis pour de la vraie production.
Cela dépend sans doute de l’usage, mais j’ai essayé à la fois Coolify et CapRover.
J’ai finalement choisi CapRover, parce que son Git Hook permettait de lancer plus rapidement mes applications NodeJS avec une build automatique à chaque commit.
Les deux gèrent cette fonction, mais CapRover génère moins de friction.
Coolify a davantage de fonctionnalités.
Coolify fonctionne au-dessus de Traefik et Docker ; au fond, c’est essentiellement une UI par-dessus.
Il lui manque beaucoup de fonctions essentielles liées aux sauvegardes, même si on peut s’en sortir avec quelque chose comme restic, et l’UX est simplement correcte.
Coolify nécessite toujours les droits root à l’installation.
J’ai entendu dire qu’une branche permettant une installation sans privilèges root était en cours de développement.
On peut se connecter au serveur en ssh, installer Coolify, puis désactiver ensuite la connexion root.
C’est envisageable si l’on est prêt à repartir de zéro et à reconfigurer entièrement le serveur.
J’ai récemment essayé un déploiement Coolify complètement from scratch, et j’ai eu sans cesse des erreurs avec les clés ssh.
Je déploie pourtant très bien plusieurs projets sur d’autres serveurs, mais l’approche « il suffit de fournir le fichier docker compose » n’a en réalité jamais vraiment bien fonctionné chez moi.
J’ai récemment migré un serveur FreeBSD vers Hetzner, et cela a été très simple.
La seule variable, c’est que les ports pour les serveurs mail restent bloqués tant que le premier cycle de facturation n’est pas entièrement terminé.
Je comprends cette politique, mais ce n’était pas clairement indiqué au départ, donc ça m’a surpris.
À noter que si votre carte bancaire expire, Hetzner peut couper immédiatement le réseau lui-même.
Il n’y a eu aucun avertissement préalable, et je ne l’ai su qu’après avoir été contacté par un vrai client ou un membre du staff.
Cela m’est réellement arrivé.
Si vous contactez l’équipe Hetzner en expliquant le type de trafic prévu, ils peuvent aussi ouvrir les ports à l’avance.
Je leur ai montré des éléments prouvant le projet que je voulais migrer, et ils les ont ouverts immédiatement.
Les outils comme Coolify ou Dokploy ont l’air intéressants, mais je trouve toujours frustrant que l’état du serveur ne soit pas représenté dans du code.
C’est pourquoi je préfère NixOS ou Ansible, mais pour un vrai déploiement de production, cela demande trop de boilerplate et de personnalisation.
Je me demande si quelqu’un connaît un framework d’infrastructure as code, plus déclaratif que ça, pas basé sur Kubernetes, et qui facilite vraiment la gestion de serveurs de production.
Il n’y a presque rien à sauvegarder dans la configuration Coolify, et tous les paramètres des applications se trouvent dans /data/coolify.
Je sauvegarde l’ensemble du volume avec kopia.
Ce n’est pas une solution très élégante, c’est plutôt du bricolage, mais c’est une méthode utilisable pour la reprise après sinistre.
Bon guide.
Mais je ne suis pas d’accord avec la configuration du pare-feu, surtout dans le cas de Hetzner.
Si on n’a besoin que d’une configuration simple, le pare-feu fourni par Hetzner suffit largement, avec en plus un fort effet d’« externalisation ».
Et si l’on veut quelque chose de plus personnalisé, on peut aussi le configurer via API.
https://docs.hetzner.cloud/reference/cloud#firewalls
Je me demande s’il existe un défaut majeur au pare-feu Hetzner.
Je pense que le conseil « autoriser SSH uniquement depuis mon IP » est risqué, même s’il est présenté comme optionnel mais recommandé.
Si l’IP change, on peut se retrouver complètement verrouillé dehors.
On peut réinitialiser via le tableau de bord Hetzner, mais plutôt que de se lier à une IP domestique qui change sans cesse, mieux vaut utiliser quelque chose comme Tailscale
ou disposer d’une IP VPN externe fixe.
Utiliser l’authentification par clé pour SSH suffit déjà à éviter la quasi-totalité des problèmes de sécurité.
Ajouter une couche supplémentaire pour réduire le bruit dans les logs peut aussi être utile, et pour les services autres que SSH qui n’ont pas besoin d’être exposés publiquement,
il vaut mieux les protéger derrière un VPN, par exemple.
En réalité, la plupart des services sur un serveur sont plus vulnérables que SSH.
C’est clairement risqué.
Beaucoup de gens ont une IP dynamique à la maison.
Configurer des clés SSH et désactiver uniquement la connexion root me semble déjà suffisamment sûr.
Je pense qu’il vaut mieux remplacer la partie sur la mise en place d’une application de production par Docker.
De nos jours, Docker est bien plus reproductible et plus simple à configurer.