Coolify, le PaaS open source qu'on héberge soi-même

Une facture d'hébergement qui double après un bon mois de trafic, ou un client qui demande sur quelle machine ses données sont physiquement stockées : il suffit d'une de ces deux conversations pour que la question revienne. Et si on hébergeait nous-mêmes ? Reprendre ses serveurs paraît simple. Ce qui coince, c'est tout ce qu'une plateforme managée fait sans qu'on y pense, déployer à chaque push, émettre puis renouveler les certificats, sauvegarder les bases, signaler la machine qui sature.

Coolify occupe exactement cette place. C'est un PaaS (platform as a service), la couche logicielle qui transforme un serveur nu en plateforme de déploiement, sauf qu'il tourne sur vos propres machines. Le produit vient de sortir d'une beta au très long cours : la version 4 est passée stable fin avril, et les correctifs s'enchaînent depuis, le dernier remontant à la mi-août. Reste à regarder ce que l'outil fait vraiment, et ce que son exploitation demande à une équipe.

Ce que Coolify fait, sans le vocabulaire marketing

Le projet ne s'embarrasse pas de circonlocutions. La documentation officielle annonce le déploiement de sites statiques, d'API, de bases de données et de services sur n'importe quel serveur joignable en SSH, qu'il s'agisse d'un VPS, d'une instance EC2 ou d'un Raspberry Pi. La présentation du dépôt public chiffre le catalogue à plus de 280 services en un clic et assume le positionnement d'alternative auto-hébergeable aux plateformes managées du marché, Vercel, Heroku ou Netlify.

Ce dépôt, coollabsio/coolify, a été créé le 25 janvier 2021 et dépasse aujourd'hui les 60 000 étoiles sur GitHub, compteur relevé le 18 août 2026 et qui évolue en continu. Le code est publié sous licence Apache 2.0, une licence permissive qui autorise sans ambiguïté l'usage commercial. Le point qui intéresse une direction technique tient en une ligne sur la page self-hosted de l'éditeur : la version auto-hébergée est gratuite, sans fonctionnalité verrouillée derrière un palier payant, sans limite de nombre de sites ni de serveurs. Ce qui se paie, ce sont les machines et le temps de ceux qui les exploitent.

Projet, environnement, ressource : le modèle de l'interface v4

Le tableau de bord actuel repose sur une hiérarchie à trois étages, décrite dans les concepts de base de la documentation. Un projet regroupe des environnements, typiquement production et préproduction, et chaque environnement détermine comment tournent les ressources qui y sont déployées. Une ressource, c'est une application ou un service : un site, une API, une base de données. Tout finit par tourner dans un conteneur Docker, sur un serveur qui fournit la puissance de calcul.

Cette organisation n'a l'air de rien tant qu'on gère deux applications. Elle devient la différence entre un outil lisible et un dépotoir le jour où l'instance en fait tourner trente : on retrouve un service par son projet, pas en fouillant une liste plate de conteneurs.

L'interface v4, une console qui se peaufine

Coolify n'essaie pas de ressembler à un produit grand public. Une barre latérale fixe donne accès aux serveurs, aux projets, aux sources git, aux clés et aux réglages de l'instance, et la page centrale montre d'abord les machines et ce qui tourne dessus. Le principe tient en une phrase : ce qu'on écrirait ailleurs dans un fichier de configuration se règle ici dans un formulaire, ressource par ressource, du build pack au nom de domaine, des variables d'environnement au healthcheck. Dense, mais rien n'est caché derrière un assistant.

Ce qui a bougé depuis la sortie stable relève de l'ergonomie plus que du concept. La navigation se replie et retient son état, l'affichage s'ajuste, une recherche permet de sauter d'une application à une base sans repasser par les listes, et le journal de déploiement se lit en direct dans le navigateur. Un terminal web ouvre même une session sur un serveur ou dans un conteneur sans client SSH. Rien de spectaculaire, mais c'est ce genre de finition qui compte quand plusieurs personnes travaillent sur la même instance.

Une réserve, en revanche : l'éditeur annonce sur sa galerie de captures, qui montre encore l'interface du cycle beta, qu'une refonte complète est en cours. L'écran d'aujourd'hui ne sera pas celui de l'an prochain. Rien d'alarmant pour un outil qu'on met à jour de toute façon, mais mieux vaut le savoir avant de rédiger une procédure interne capture d'écran par capture d'écran.

La v4 est stable depuis avril, et le produit n'a pas arrêté de bouger

La v4.0.0, c'est-à-dire la sortie générale, a été publiée le 27 avril 2026, au terme d'une période beta particulièrement longue : la version qui la précède immédiatement dans le dépôt s'appelle v4.0.0-beta.474. L'éditeur l'assume dans ses notes de version : « Finally releasing v4.0. It was long overdue because we have been in beta for a long time. Thousands of companies and people have been using Coolify in production for 1-2 years. » Le passage en stable n'a donc pas ouvert un usage en production, il a entériné un usage déjà installé depuis un à deux ans.

Depuis, les sorties s'enchaînent. La v4.1.0, le 18 mai 2026, apporte une barre latérale repliable dont l'état persiste d'une session à l'autre, le suivi des changements de configuration de déploiement (un comparatif avant redéploiement, précieux quand plusieurs personnes touchent aux mêmes variables) et un support MCP au niveau de l'instance. La v4.3.6 du 16 août 2026 ajoute le choix entre affichage pleine largeur ou centré, un fil d'Ariane consultable par recherche pour sauter d'une application à une base ou à un service, un lien de navigation Admin pour les comptes root, et corrige la remontée d'état des ressources quand la sonde Sentinel renvoie un inventaire de conteneurs vide. La dernière version publiée, la v4.3.7 du 17 août 2026, s'attaque surtout aux sauvegardes : dumps complets quand toutes les bases sont sélectionnées, sauvegardes PostgreSQL et de volumes vers un stockage S3 réparées sur les serveurs qui se connectent avec un compte SSH sans privilèges root, annulation de déploiement fiabilisée.

Ces notes disent bien la nature du projet : de petites itérations fréquentes plutôt que des refontes. C'est rassurant sur la vitalité de l'outil, mais ça implique de traiter Coolify comme n'importe quelle dépendance d'infrastructure, avec quelqu'un qui lit les notes de version avant de monter l'instance de production.

Nixpacks par défaut, Railpack en beta

Le build pack est la brique qui transforme un dépôt git en image exécutable. Coolify utilise Nixpacks par défaut : cet outil open source, créé par Railway, éditeur d'une plateforme de déploiement managée, analyse le dépôt, génère automatiquement un Dockerfile puis construit l'image à partir de ce fichier. Pour les stacks courantes, vous n'écrivez aucune configuration.

Une seconde option est apparue avec la v4.1, marquée Beta : Railpack, présenté comme le successeur de Nixpacks et conçu par la même équipe. La promesse est identique, détecter le langage, installer les dépendances, configurer la construction et le démarrage sans configuration à écrire. La mécanique en dessous change : Railpack construit une image optimisée avec Docker BuildKit, et les paquets supplémentaires s'ajoutent via Mise, quand Nixpacks s'en tient au Dockerfile qu'il a lui-même généré.

La lecture raisonnable est simple : Nixpacks reste le défaut, Railpack est le chantier à surveiller. Un changement de build pack se teste sur une préproduction avant d'y faire passer une application qui rapporte de l'argent, a fortiori quand l'option porte encore une étiquette beta.

Domaines validés, serveurs surveillés

Deux briques font gagner du temps au quotidien, et on ne les remarque qu'une fois qu'elles manquent. La première concerne les domaines : Coolify valide les enregistrements DNS que vous déclarez auprès du résolveur public 1.1.1.1, opéré par Cloudflare, fournisseur d'infrastructure réseau. Le ou les serveurs DNS interrogés se personnalisent dans les réglages avancés, via le champ Custom DNS Servers. Le certificat, lui, suit tout seul : dès qu'un domaine est saisi en https, le proxy intégré, Traefik ou Caddy, le réclame à Let's Encrypt, l'autorité de certification gratuite, puis le renouvelle avant la fin des 90 jours de validité. Ça élimine le grand classique du domaine pointé de travers qu'on ne découvre qu'une fois le site injoignable.

La seconde s'appelle Sentinel. C'est un conteneur open source léger qui expose une API système Linux et remonte l'utilisation processeur et mémoire du serveur ainsi que celle des conteneurs qui y tournent. De quoi repérer une machine qui sature sans déployer une pile de supervision complète. Un point à connaître avant de compter dessus : la documentation range encore Sentinel parmi les fonctionnalités expérimentales, et les métriques collectées se limitent pour l'instant au processeur et à la mémoire. C'est aussi cette sonde qui alimente l'état des ressources dans l'interface, d'où le correctif de la v4.3.6 évoqué plus haut.

Les sauvegardes partent vers n'importe quel stockage S3

C'est souvent sur ce point que se joue la décision d'héberger soi-même. La documentation des sauvegardes décrit un fonctionnement direct : les sauvegardes programmées reposent sur des expressions cron, donc sur la fréquence que vous choisissez, horaire, quotidienne, hebdomadaire ou mensuelle. La planification y est documentée pour PostgreSQL et pour la base de Coolify elle-même, et la page détaille aussi les commandes de sauvegarde retenues pour MySQL, MariaDB et MongoDB. Les archives peuvent partir vers n'importe quel stockage compatible S3 que vous déclarez.

Le détail qui compte n'est pas la fonctionnalité, il est dans l'usage. Pour PostgreSQL, la documentation donne la commande de restauration à jouer sur l'archive produite : c'est le geste qu'on n'a jamais répété. Une sauvegarde programmée ne devient une sauvegarde qu'après une restauration réellement testée, et les correctifs de la v4.3.7 sur les dumps complets et les envois vers S3 rappellent que cette chaîne mérite d'être vérifiée chez soi. Le jour où une base part, ce n'est pas le moment de découvrir que le bucket était mal configuré.

Le multi-serveurs reste expérimental, la v5 reste un chantier

Sur le papier, Coolify sait déjà déployer la même application sur plusieurs serveurs, pour tenir de la haute disponibilité. Dans les faits, la documentation présente ce déploiement multi-serveurs comme une fonctionnalité expérimentale, avec trois prérequis explicites. Chaque serveur doit être ajouté à Coolify, validé et joignable. Tous les serveurs concernés, serveur de build compris s'il existe, doivent partager la même architecture, AMD64 ou ARM. Et l'image construite doit être poussée vers un registre Docker : Coolify automatise ce push, à condition d'être authentifié sur le registre depuis le serveur.

Le répartiteur de charge, en revanche, n'est pas automatisé du tout. La documentation le dit sans détour : il se monte à la main, soit en pointant le répartiteur sur les couples adresse et port des serveurs, soit en lui confiant le domaine et la terminaison SSL. Une haute disponibilité bâtie sur une brique estampillée expérimentale et sur un répartiteur configuré à part reste un pari, pas une garantie contractuelle.

Quant à la suite, l'éditeur reste volontairement flou, et c'est à mettre à son crédit. Dans ces mêmes notes de la v4.0.0, il écrit : « v5 is coming together, but we are not rushing it. The biggest feature will be full scalability in the core, so you will have cloud infrastructure, but with your own servers. [...] doing v5 does not mean we won't continue to support v4. » Autrement dit, la scalabilité multi-serveurs native est le chantier structurant de la prochaine version, aucune date n'est annoncée, et la v4 continuera d'être maintenue en parallèle. Rien n'oblige à attendre pour se lancer.

Ce que ça change concrètement pour une équipe

Passer sur un PaaS auto-hébergé déplace la dépense plus qu'il ne la supprime. Vous ne payez plus un abonnement à la plateforme ni des dépassements facturés à l'usage, vous payez des machines et du temps humain : mises à jour de l'hôte, gestion des accès SSH, rotation des sauvegardes, surveillance des ressources. Le calcul penche souvent du bon côté quand plusieurs environnements tournent en parallèle, et il change de nature dès qu'une contrainte de localisation des données entre dans l'équation, puisque vous choisissez la machine.

La bonne façon de trancher n'a rien d'original : lister les applications concernées, mesurer ce que coûte réellement l'hébergement actuel, vérifier qui tiendra les serveurs dans six mois. C'est exactement l'objet d'un audit et d'une étude de cadrage, première étape de notre méthode, à mener avant la première migration plutôt qu'après. Et si personne en interne ne souhaite porter l'exploitation dans la durée, mieux vaut le savoir tout de suite et prévoir la maintenance en conséquence.

Pour aller plus loin

• Coolify ou Dokploy, quel PaaS auto-hébergé choisir : deux outils sur le même terrain, avec des partis pris différents.
• Vercel Ship 2026 : ce que fait bouger la plateforme managée à laquelle Coolify se compare.
• Rancher Desktop : l'équivalent côté poste de développement, pour faire tourner des conteneurs en local.
• Cloud et DevOps : comment nous structurons l'hébergement, la conteneurisation et les déploiements.

Sources

Toutes les informations de cet article proviennent de la documentation officielle de Coolify et des notes de version publiées par son éditeur, vérifiées en statut 200 le 18 août 2026 :

• Coolify Docs, introduction (déploiement sur n'importe quel serveur via SSH)
• Coolify Docs, concepts de base (projets, environnements, ressources)
• Coolify, page self-hosted (auto-hébergement gratuit, sans palier payant)
• Dépôt GitHub coollabsio/coolify (licence Apache 2.0, création le 25 janvier 2021)
• Notes de version v4.0.0, sortie générale du 27 avril 2026
• Notes de version v4.1.0 du 18 mai 2026 (Railpack en beta)
• Notes de version v4.3.6 du 16 août 2026
• Notes de version v4.3.7 du 17 août 2026 (dernière publiée)
• Coolify Docs, build pack Nixpacks
• Coolify Docs, build pack Railpack (beta)
• Coolify Docs, domaines, validation DNS et certificats
• Coolify Docs, Sentinel (supervision serveur et conteneurs, expérimental)
• Coolify Docs, sauvegardes de bases de données vers S3
• Coolify Docs, déploiement multi-serveurs (expérimental)
• Coolify Docs, galerie de captures de l'interface (refonte UI en cours)
• Coolify Docs, terminal web intégré (xterm.js, WebSocket, SSH)
• Changelog officiel Coolify