Pourquoi utiliser Coolify

Le problème avec les PaaS managés

Quand on commence un projet, c'est tentant de tout mettre sur Vercel, Railway ou Render. Et c'est normal. Le setup est instantané, le déploiement se fait en un git push, le SSL est automatique. Pour un side project ou un MVP, c'est parfait.

Le souci arrive quand les projets grossissent, ou quand on en a plusieurs. Chez Orange Bleu, on gère une dizaine de services en parallèle : des API NestJS, des fronts Nuxt, des petits services Hono (j'en parle dans ma note sur Hono), des bases PostgreSQL, du Redis, des workers. Sur Railway ou Render, chaque service a son pricing. Chaque base de données est facturée séparément. Ça monte vite.

Pour donner un ordre d'idée : un projet typique chez nous (une API, un front, une DB PostgreSQL et souvent un site vitrine), ça peut facilement coûter 40-60$/mois sur Railway. Multipliez par le nombre de projets en prod, ajoutez les environnements de staging, et la facture devient significative. Et on ne parle même pas des limites de ressources qui obligent à upgrader dès qu'un service consomme un peu plus de RAM que prévu.

L'autre problème, et celui-là me dérange davantage que le coût, c'est la question des données. Quand la base PostgreSQL tourne sur l'infra de Railway, les données de nos clients sont chez eux. On n'a pas la main sur le chiffrement au repos, sur la localisation physique des serveurs, sur les politiques de rétention. Pour certains projets, nos clients demandent explicitement que leurs données restent en Europe, sur une infra qu'on contrôle. Avec un PaaS managé, c'est compliqué à garantir.

Coolify, concrètement

Coolify est un PaaS open-source qu'on installe sur son propre serveur. L'idée est simple : retrouver le confort de déploiement d'un Vercel ou Railway, mais sur une machine qu'on possède.

En pratique, c'est une interface web qui orchestre Docker et Traefik sur un VPS. On connecte un repo Git, on configure quelques variables d'environnement, et Coolify se charge du build, du déploiement, du SSL et du reverse proxy. C'est pas magique, c'est juste une couche d'abstraction au-dessus de Docker Compose et Traefik, deux outils qu'on utiliserait de toute façon si on faisait tout à la main.

Comment ça marche sous le capot

Quand on déploie un service sur Coolify, voilà ce qui se passe :

1. Coolify clone le repo (via webhook ou manuellement)
2. Il détecte le Dockerfile ou le docker-compose.yml à la racine
3. Il build l'image Docker sur le serveur
4. Il configure Traefik pour router le domaine vers le bon conteneur
5. Il provisionne un certificat Let's Encrypt pour le SSL
6. Il démarre le conteneur et redirige le trafic

Tout ça est configurable. On peut définir le contexte de build, les build args, les health checks, la stratégie de déploiement (rolling update ou recreate). Mais par défaut, le flow "Dockerfile + domaine" fonctionne sans rien toucher.

Traefik est le reverse proxy. Il route les requêtes vers les bons conteneurs en fonction du domaine. Coolify génère automatiquement les labels Docker que Traefik utilise pour le routage. En pratique, on n'a jamais besoin de toucher à la config Traefik directement, sauf pour des cas particuliers (headers custom, rate limiting au niveau du proxy, etc.).

Le SSL est géré par Traefik via Let's Encrypt. On renseigne le domaine dans Coolify, et le certificat est provisionné et renouvelé automatiquement. Ça marche aussi avec les wildcards si on configure le DNS challenge. Zéro intervention manuelle après le setup initial.

Les bases de données

C'est un des gros avantages par rapport au "tout Docker Compose à la main". Coolify permet de provisionner des services de base de données en quelques clics : PostgreSQL, MySQL, MariaDB, MongoDB, etc. Chaque service tourne dans son propre conteneur, avec des volumes persistants.

Ce qui est bien pensé, c'est que Coolify gère les backups automatiques vers S3 (ou compatible S3, comme MinIO). On configure la fréquence, la rétention, le bucket, et c'est parti. Pour les bases PostgreSQL, il utilise pg_dump en interne. C'est pas la solution la plus sophistiquée, mais pour notre usage c'est largement suffisant. Les backups partent sur un bucket S3 chez un provider différent du serveur principal, ce qui couvre le scénario "le serveur prend feu".

On peut aussi exposer les ports des bases de données pour s'y connecter depuis l'extérieur (via un tunnel SSH ou directement, selon la paranoia de chacun). En dev, c'est pratique pour se connecter avec un client comme DBeaver ou TablePlus sans avoir à passer par un bastion.

Ce que j'apprécie au quotidien

Le déploiement par webhook. On push, Coolify build et déploie. C'est le même confort qu'un Vercel, mais sur notre machine. On a aussi la possibilité de déployer depuis d'autres branches pour les environnements de preview, même si en pratique on utilise surtout le déploiement manuel pour le staging.

La gestion des variables d'environnement. Chaque service a son propre jeu de variables, modifiable depuis l'interface. On peut aussi partager des variables entre services (pratique pour les credentials de base de données, par exemple). C'est pas du Vault, mais c'est fonctionnel.

Le monitoring intégré. Coolify affiche la consommation CPU, RAM et disque de chaque conteneur. C'est basique comparé à un Grafana, mais ça suffit pour repérer un service qui fuit de la mémoire ou un disque qui se remplit. Pour du monitoring plus avancé, on a ajouté Umami pour l'analytics et on envisage Uptime Kuma pour la supervision, tous les deux déployés sur le même Coolify.

Le multi-serveur. On peut connecter plusieurs serveurs à une seule instance Coolify. On ne l'utilise pas encore (tout tient sur un seul dédié pour l'instant), mais c'est rassurant de savoir qu'on peut scaler horizontalement le jour où un seul serveur ne suffit plus.

Docker Compose natif. Pour les projets qui ont déjà un compose.yml (et c'est le cas de la plupart des nôtres), Coolify sait le déployer tel quel. Pas besoin de réécrire la config dans un format propriétaire. Le compose.yml qu'on utilise en dev est quasi le même qu'en prod, avec juste les variables d'environnement qui changent.

La gouvernance des données. Les bases de données tournent sur notre serveur, dans un datacenter européen qu'on a choisi. On sait où sont les données, qui y a accès, comment elles sont sauvegardées. Quand un client pose la question (et ça arrive de plus en plus), on a une réponse claire. Avec un PaaS managé, on dépend de leur politique de stockage, et celle-ci peut changer sans préavis.

Aucune dépendance sur un pricing externe. C'est peut-être le point le plus sous-estimé. Quand Railway ou Render changent leurs tarifs (et ça arrive), on subit. On a vu des augmentations significatives sur certains PaaS ces dernières années, parfois du jour au lendemain. Avec un dédié, le coût est fixe et prévisible. Si Hetzner augmente ses prix de 5€, ça reste gérable. On ne se réveille pas un matin avec une facture doublée parce qu'un service a décidé de revoir son modèle de pricing.

Les limites, honnêtement

Coolify n'est pas parfait, et il faut en être conscient avant de migrer toute son infra dessus.

On est son propre sysadmin. Si le serveur tombe à 3h du matin, c'est notre problème. Pas de support technique, pas de SLA. Il faut être à l'aise avec le fait de SSH sur une machine et de debug un Traefik qui ne route plus correctement. Ça m'est arrivé deux ou trois fois en un an, souvent après une mise à jour de Coolify qui a changé un truc dans la config Traefik. Rien de dramatique, mais faut pas avoir peur de mettre les mains dedans.

Pas de CDN intégré. Vercel et Netlify distribuent les assets sur un réseau edge mondial. Avec Coolify, le serveur est à un endroit, et c'est tout. On peut mettre un Cloudflare devant (c'est ce qu'on fait), mais c'est une couche supplémentaire à configurer. Pour un site statique qui vise un public mondial, un Vercel sera objectivement plus performant en termes de latence. Pour une API SaaS qui sert principalement l'Europe, la différence est négligeable.

L'interface a ses moments. Coolify est développé principalement par une seule personne (Andras Bacsai), avec une communauté de contributeurs. L'interface est fonctionnelle, mais il y a parfois des petits bugs d'UI, des états qui ne se rafraîchissent pas, des messages d'erreur cryptiques. Rien de bloquant, mais c'est pas le polish d'un produit avec 50 ingénieurs front derrière. Le projet évolue vite, et la v4 (actuellement en cours) promet pas mal d'améliorations.

Les mises à jour demandent de l'attention. Coolify se met à jour depuis l'interface, et en général ça se passe bien. Mais j'ai pris l'habitude de lire le changelog avant chaque update, parce qu'il arrive que des changements cassent des trucs. Rien qu'on ne puisse pas fixer, mais il faut prévoir 15 minutes de vérification après chaque mise à jour plutôt que de cliquer "update" et de passer à autre chose.

Quand ne pas utiliser Coolify

Si on est dev solo sans expérience infra, que la priorité c'est de livrer du code et pas de gérer un serveur, les PaaS managés restent le meilleur choix. Le temps passé à maintenir un serveur, c'est du temps qu'on ne passe pas à coder. Et si on valorise son temps correctement, le surcoût d'un Railway est souvent justifié.

Pour les projets qui ont besoin d'une présence edge mondiale (un site marketing avec des visiteurs partout dans le monde, par exemple), Vercel ou Cloudflare Pages feront un meilleur travail. Coolify ne remplace pas un CDN.

Et si le projet a des exigences de haute disponibilité avec du failover automatique, un Kubernetes managé (EKS, GKE) sera plus adapté. Coolify peut faire du multi-serveur, mais ce n'est pas un orchestrateur de conteneurs au sens strict.

Notre stack infra complète

Pour donner une vue d'ensemble de ce qu'on fait tourner sur Coolify chez Orange Bleu :

• Projets clients : API NestJS + front Nuxt, chacun dans son conteneur
• Bases de données : PostgreSQL pour chaque projet, avec backups S3 quotidiens
• Outils internes : Umami (analytics), Directus (CMS headless pour certains clients)
• Reverse proxy : Traefik (géré par Coolify) + Cloudflare devant pour le CDN et la protection DDoS

Le tout sur un seul dédié, avec encore de la marge. Le jour où ça ne suffit plus, on ajoutera un deuxième serveur et on répartira les services. Coolify gère ça nativement.

Pour résumer

Coolify n'est pas pour tout le monde. Il faut accepter d'être responsable de son infra, de lire des logs Docker quand ça plante, de maintenir son serveur à jour. Mais pour une petite équipe technique qui veut garder le contrôle sur ses données et ses coûts, c'est un excellent compromis entre le confort d'un PaaS et la liberté du self-hosting.

On l'utilise en production depuis plus d'un an chez Orange Bleu, et on ne reviendrait pas en arrière. Pas parce que les PaaS managés sont mauvais, mais parce que dans notre contexte (plusieurs projets, clients européens, budget maîtrisé), Coolify coche toutes les cases.

  # avant : un provider par service
- vercel.com          → front         19$/mois
- railway.app         → api           29$/mois
- railway.app         → postgres      21$/mois
- railway.app         → redis          7$/mois
-                                    = 76$/mois (un seul projet)

  # après : tout sur un dédié
+ bare metal          → 1 serveur     €/an (tous les projets)
+ coolify             → self-hosted   gratuit
+ cloudflare          → CDN/DNS       gratuit