Coolify

Ce qu'est réellement Coolify

Coolify (github.com/coollabsio/coolify) est un plan de contrôle pour des serveurs qui vous appartiennent. Vous le pointez vers une machine en SSH — un VPS, du matériel dédié ou un Raspberry Pi, selon les mots du projet lui-même — et il prend en charge la distance entre un dépôt git et un service en fonctionnement : construire l'image, lancer le conteneur, émettre le certificat, brancher le domaine, et tenir à côté les bases de données et les services installables en un clic. Lire le fichier LICENSE plutôt que le badge le confirme : c'est un texte Apache 2.0 propre et non modifié, sans avenant et sans ligne de partage entre un cœur gratuit et un répertoire payant, à la différence du modèle open core qu'emploient plusieurs de ses voisins. Une version nuage payante existe, et la note du dépôt lui-même indique que le projet entend ne laisser aucune fonctionnalité derrière le mur payant : ce que vend le nuage, c'est la haute disponibilité, les notifications, le support et la maintenance assurée par quelqu'un d'autre.

L'affirmation qui mérite une lecture posée est celle sur la dépendance au fournisseur. Le README dit que votre configuration est écrite sur votre propre serveur, et que vous pourriez donc continuer à gérer ce qui tourne même après avoir cessé d'utiliser Coolify — puis ajoute, avec ses propres mots, que vous perdriez les automatisations. C'est une façon de le dire d'une franchise peu commune, et c'est le bon modèle mental : ce qui reste, ce sont les conteneurs et la configuration ; ce qui part, c'est la machinerie qui les reconstruisait et les redéployait pour vous. Cela reste une bien meilleure réponse que celle donnée à la même question par la plupart des plateformes gérées, à savoir un bouton d'export ou rien du tout.

La facture que vous comparez vraiment

La comparaison de surface est facile et trompeuse. Une plateforme gérée vous facture chaque mois une chose que deux petits serveurs approchent, si bien que l'arithmétique semble tranchée avant même de commencer. La vraie comparaison n'est pas la facture, c'est la facture plus les heures — et les heures sont la moitié que personne n'estime honnêtement au départ, parce qu'elles arrivent plus tard et par petits morceaux.

Rien de tout cela ne plaide contre l'auto-hébergement. Cela plaide pour le faire délibérément. C'est un bon échange quand votre temps coûte moins que la facture, quand vous avez plusieurs services à faire tourner et que le coût fixe d'un plan de contrôle se partage, et quand vous préférez heurter une limite que vous voyez venir plutôt qu'une limite fixée par quelqu'un d'autre. C'est un mauvais échange le mois où vous cherchez vos premiers clients, car chaque heure passée là est une heure non passée à faire venir qui que ce soit voir la chose.

Ce que nous avons appris en exploitant notre propre flotte sur une plateforme gérée

Nous n'utilisons pas Coolify, donc cette page n'affirme rien sur son exploitation. Ce dont nous pouvons parler de première main, c'est la décision de l'autre côté : nous faisons tourner un conteneur par espace de travail client sur une plateforme gérée, et trois choses nous ont surpris qui méritent d'être connues avant de choisir dans un sens comme dans l'autre.

La première, c'est que les limites d'une plateforme gérée sont les chiffres de quelqu'un d'autre, et qu'elles peuvent se retrouver sous les yeux de vos utilisateurs. La nôtre plafonne le nombre de services qu'un même projet peut contenir. Nous avons atteint ce plafond, et la panne n'est pas arrivée sous forme d'alerte : elle est arrivée sous la forme d'un client qui, en pleine inscription, a vu le message de quota de la plateforme elle-même, avec le nom de notre fournisseur et une invitation à changer d'offre adressée à nous et non à lui. Une limite portant sur du matériel que vous louez vous-même est au moins une limite que vous voyez approcher. C'est un point réel en faveur de Coolify, et de tout ce qui figure ici, celui auquel nous donnerions le plus de poids.

La deuxième est architecturale. Notre correctif a été de cesser de donner à chaque client son propre service et de rattacher les clients, à mesure qu'ils arrivent, à l'un des services d'un ensemble générique. Si vous envisagez un conteneur par client sur une plateforme quelconque, gérée ou auto-hébergée, découvrez où se trouve le plafond avant de construire autour, et non après.

La troisième porte sur l'économie elle-même. Laisser les machines inactives redescendre à zéro, c'est de l'argent bien réel, et le difficile n'est pas de les endormir : c'est de les laisser dormir. Chaque réveil que nous avons poursuivi s'est révélé être une minuterie d'arrière-plan que personne ne considérait comme du trafic : une vérification d'état, une interrogation de statut, un tableau de bord laissé ouvert dans une autre fenêtre. Un seul onglet oublié, session ouverte, se rafraîchissant tout seul, a maintenu un espace de travail éveillé quasiment en permanence alors que le reste de la flotte dormait la plus grande partie de la journée : l'économie sur cet espace a donc été nulle. Avant d'ajouter la moindre tâche périodique à une installation auto-hébergée, demandez-vous ce qu'elle fait à une machine censée dormir.

Voilà la forme honnête de ce choix. Coolify déplace le bouton de déploiement vers du matériel que vous contrôlez, et vous tend le bipeur avec. Quel que soit le côté choisi, publier est le début du problème et non sa fin : ce que vous venez de déployer doit encore être trouvé par quelqu'un, et c'est une discipline différente de celle qui l'a mis en marche. Les briques auto-hébergées que l'on finit le plus souvent par faire tourner à côté sont PocketBase pour le backend, OpenStatus pour savoir quand c'est tombé, et Meilisearch le jour où le champ de recherche commence à compter.