Coolify vs Railway : liberté du self-hosting ou confort du PaaS managé

Le vrai compromis : son temps contre son argent

Coolify et Railway résolvent le même problème depuis des directions opposées. On a une web app. On veut qu'elle tourne quelque part. On n'a pas envie d'écrire du Terraform ou de débugger du YAML Kubernetes. Les deux plateformes offrent des déploiements au git push, du provisioning de bases de données et des certificats SSL. La différence, c'est qui possède l'infrastructure en dessous.

Avec Railway, personne ne la possède. Enfin, Railway la possède et on la loue. On push du code, Railway le build, le fait tourner, le monitore et gère tout ce qui pourrait merder côté serveur. On paie pour le confort, et le confort est bien réel.

Avec Coolify, c'est nous qui possédons. On loue un VPS chez Hetzner, DigitalOcean, ou où on veut. On installe Coolify dessus. Coolify fournit un dashboard web qui ressemble étonnamment à Railway, mais tout tourne sur du hardware qu'on contrôle. Quand quelque chose casse à 3h du mat, il n'y a pas d'équipe support à appeler. C'est notre serveur.

La question fondamentale : est-ce que c'est notre temps ou notre argent qui est la ressource la plus rare en ce moment ?

Là où Coolify brille

Coolify est un projet open source ambitieux, et il est devenu vraiment bon. Si on l'a testé il y a un an et qu'on a laissé tomber, ça vaut le coup de réessayer.

Les économies sont drastiques et immédiates. Un VPS Hetzner à $6/month avec 4 Go de RAM peut faire tourner une app Next.js, une base Postgres, une instance Redis et un worker en background. Sur Railway, la même stack coûterait $15-30/month selon l'usage, et ça grimpe avec le trafic. Pour un fondateur bootstrappé qui gère plusieurs projets, les économies se cumulent vite. Dix petits projets sur Coolify coûtent peut-être $20/month au total. Sur Railway, on est facilement à $100+.

On a de vrais déploiements façon Heroku sur son propre métal. On connecte un repo GitHub ou GitLab, on choisit une branche, et Coolify build et déploie automatiquement à chaque push. Il détecte les Dockerfiles, les buildpacks Nixpacks et les sites statiques. L'expérience n'est pas aussi polie que celle de Railway, mais c'est étonnamment proche pour un outil open source maintenu par une petite équipe.

Le provisioning de bases de données est en un clic. Postgres, MySQL, MariaDB, MongoDB, Redis et plus. Coolify les provisionne directement sur le serveur et fournit les connection strings. On ne gère pas des containers Docker à la main. On clique sur un bouton et la base existe. La différence principale avec Railway, c'est que les backups sont notre responsabilité.

On peut self-hoster quasiment n'importe quoi. Coolify ne sert pas qu'à nos apps custom. Il peut déployer n'importe quelle image Docker. Envie de faire tourner Plausible analytics, Umami, n8n, Uptime Kuma, Gitea ou MinIO ? Coolify gère tout ça. La bibliothèque de services one-click ne cesse de grandir. Pour les builders indés qui veulent self-hoster toute leur stack d'outils, Coolify est ce qui se rapproche le plus d'un control plane unifié.

Pas de vendor lock-in, pas de risque plateforme. Les apps tournent dans des containers Docker standard sur un serveur qu'on contrôle. Si Coolify disparaît demain, les apps tournent toujours. On peut SSH dedans, gérer les containers directement, ou migrer vers un autre outil. Avec Railway, l'infrastructure n'existe que tant que le compte existe.

L'option Coolify Cloud fait le pont. Si on aime l'idée de Coolify mais qu'on ne veut pas gérer l'instance Coolify elle-même, il y a une offre cloud payante où l'équipe Coolify héberge la couche de management pendant que les apps tournent sur des serveurs qu'on provisionne nous-mêmes. C'est un compromis entre le full self-hosting et un PaaS entièrement managé.

Là où Railway brille

La valeur de Railway n'est pas dans une feature en particulier. C'est l'effet cumulé de tout qui fonctionne bien ensemble.

L'expérience de déploiement est vraiment best-in-class. On connecte son repo GitHub, on push du code, et Railway le build et le déploie. Les logs de build arrivent en temps réel. Le deploy passe en live avec un zero-downtime rollout. Faire un rollback c'est un clic sur le déploiement précédent. On ne pense jamais aux serveurs de build, aux registres de containers ou aux scripts de déploiement. Ça marche, tout simplement, et c'est rapide.

Le dashboard est un vrai produit, pas un afterthought. La vue projet de Railway montre les services comme un graphe visuel. On voit la web app connectée à la base Postgres connectée au cache Redis, le tout avec des indicateurs de statut en live. Logs, métriques et variables d'environnement sont juste là. Pour quelqu'un qui passe du temps dans les dashboards, ça compte plus que ça en a l'air.

Le provisioning de bases de données est zéro-friction. Besoin d'une base Postgres ? Un clic, elle existe. La connection string est automatiquement injectée comme variable d'environnement dans le service. On ne configure rien. On ne se soucie pas des backups. On ne pense pas à l'espace disque. Railway gère. Pour un fondateur solo qui a besoin d'une base de données et un produit à shipper, c'est le bon niveau d'abstraction.

La gestion des environnements est bien pensée. Railway permet de définir des variables par service, par environnement, et d'utiliser des références de variables pour les partager. L'UI montre quelles variables sont héritées, surchargées ou manquantes. Quand on clone un projet pour le staging, toutes ces relations suivent. Comparé à la gestion de fichiers .env sur plusieurs services d'un VPS, c'est une vraie amélioration du quotidien.

Le marketplace de templates accélère tout. Besoin de déployer Metabase, Directus, Ghost ou Supabase ? Railway a des templates one-click avec bases de données et variables d'environnement pré-câblées. Ce ne sont pas des démos jouets. Ce sont des stacks prêtes pour la production qui se déploient en secondes.

Le scaling est un slider, pas un projet. Sur Railway, on ajuste les limites CPU et mémoire dans le dashboard. L'autoscaling est dispo sur les plans Pro. On règle les curseurs et Railway gère le reste. Sur Coolify, scaler veut dire upgrader le VPS, migrer les données, et potentiellement reconfigurer le réseau. Railway transforme un projet d'infrastructure en changement de paramètres.

Comparatif des coûts : les chiffres comptent

C'est là que la conversation devient sérieuse pour les fondateurs bootstrappés qui surveillent leur burn rate.

Le modèle de coûts de Coolify est simple. On paie un VPS. Un Hetzner CX22 avec 4 Go de RAM et 2 vCPUs coûte environ 4 EUR/mois. Un CAX21 ARM avec 8 Go de RAM et 4 vCPUs coûte environ 7 EUR/mois. C'est toute la facture d'hébergement pour tout ce qui tourne sur ce serveur. Plusieurs apps, plusieurs bases de données, des workers en background, des outils internes. Tout sur une seule machine. Si on a besoin de plus de capacité, on upgrade le VPS ou on ajoute un second serveur que Coolify gère à distance.

Les coûts de Railway scalent avec l'usage. Le Hobby plan est à $5/month et inclut $5 de crédits d'usage. Une petite app typique avec une base Postgres coûte $8-20/month selon le trafic et le compute. Le plan Pro à $20/month par membre supprime les limites et ajoute des fonctionnalités d'équipe. Un SaaS moyennement actif avec une web app, une API, une base de données et un cache Redis peut facilement coûter $40-80/month sur Railway. Pas déraisonnable pour un produit qui génère du revenu, mais significatif pour un side project pré-revenu.

L'écart se creuse avec plusieurs projets. Si on est un builder indé qui fait tourner 5 side projects en parallèle de son projet principal, les coûts Railway s'additionnent sur chacun. Sur Coolify, ces 5 projets peuvent partager un seul serveur à $10/month. Sur Railway, chaque projet a ses propres coûts de compute et de base de données.

Les coûts Railway sont aussi plus prévisibles d'une certaine façon. On voit les coûts estimés dans le dashboard avant de déployer. Avec Coolify, les coûts sont fixes (la facture VPS), mais on peut atteindre des limites de performance plus difficiles à prévoir. Quand le VPS à $6 commence à swapper sous charge, la solution c'est un upgrade de serveur et une migration, pas un slider.

La charge de maintenance : le coût caché du self-hosting

C'est la dimension qui tue le pitch de Coolify pour certains, et à juste titre.

Avec Coolify, la maintenance serveur c'est notre job. Mises à jour de l'OS, patchs de sécurité, mises à jour Docker, mises à jour Coolify, monitoring de l'espace disque, scripts de backup, renouvellement des certificats SSL (quasi automatisé, mais quand même), règles de firewall, et le crash mystérieux de container à 2h du mat de temps en temps. Rien de tout ça n'est dur individuellement. Mais ça s'accumule. Si on est fondateur solo et qu'on construit aussi le produit, fait le marketing et gère le support, la taxe de maintenance est réelle.

Les backups sont entièrement à notre charge. Railway sauvegarde les bases de données automatiquement. Avec Coolify, il faut configurer les plannings de backup, choisir une destination de stockage (S3, local, où on veut), et surtout vérifier que les backups fonctionnent. La plupart des gens mettent en place les backups le premier jour et ne testent jamais une restauration jusqu'au jour où ils en ont besoin. C'est comme ça qu'on perd des données.

Les mises à jour de Coolify peuvent être bumpy. Coolify est activement développé et s'améliore rapidement, mais les mises à jour introduisent parfois des breaking changes. La communauté est réactive et le développeur principal aussi, mais on fait toujours tourner un logiciel d'infrastructure pre-1.0. Railway ne met jamais dans une situation où une mise à jour casse le pipeline de déploiement.

Avec Railway, les ops c'est le problème de quelqu'un d'autre. On ne SSH jamais dans quoi que ce soit. On ne se soucie jamais de l'espace disque, des mises à jour kernel ou des versions de container runtime. On n'est jamais réveillé en urgence. On ne débugge jamais des problèmes réseau entre services sur le même host. La surface opérationnelle dont on est responsable est essentiellement zéro. Pour certains fondateurs, ça seul justifie le coût plus élevé.

Expérience de déploiement : proches mais différents

Les deux plateformes proposent des déploiements au git push. Les détails font la différence.

Le pipeline de deploy Railway est plus poli. On push sur GitHub, Railway détecte le commit, build le container, lance les health checks et route le trafic vers la nouvelle instance en zero downtime. Les logs de build sont rapides et lisibles. Les rollbacks c'est un clic. Les preview environments par branche sont disponibles. Tout le flow est optimisé pour la vitesse et la confiance.

Le pipeline de deploy Coolify est capable mais plus brut. Il supporte les webhooks GitHub, GitLab et Bitbucket. Les builds utilisent soit le Dockerfile soit Nixpacks (le même système de buildpacks que Railway). Les déploiements fonctionnent bien une fois configurés, mais le setup initial implique plus de décisions : quelle méthode de build, quel port mapping, quelle config réseau. Les health checks et les déploiements zero-downtime existent mais demandent une configuration plus explicite.

Là où Coolify a un avantage : le support Docker Compose. Si l'app est définie comme un stack Docker Compose, Coolify la déploie nativement. Railway ne supporte pas les fichiers Compose directement. Pour les setups multi-containers complexes qui ont déjà un docker-compose.yml fonctionnel, c'est un vrai plus.

Gestion des bases de données : managé vs auto-géré

Les deux plateformes provisionnent des bases de données en un clic. La différence c'est ce qui se passe après.

Les bases de données Railway sont entièrement managées. Backups automatisés, connection pooling, métriques dans le dashboard, et un data browser intégré. On clique sur un bouton, on a une base, et on passe à autre chose. Si on a déjà perdu des données parce qu'on avait oublié de mettre en place les cron jobs de backup, on comprend la valeur du truc.

Les bases de données Coolify tournent sur notre serveur. On a le même provisioning en un clic, mais la base est un container Docker sur notre VPS. Les backups demandent de la configuration. Le monitoring demande du setup (ou au moins de vérifier l'utilisation des ressources dans le dashboard Coolify). Le tuning de performance c'est à nous. Les bases de données elles-mêmes fonctionnent bien. L'enveloppe opérationnelle autour est plus fine.

Pour les vrais workloads de production, on peut considérer une base de données dédiée dans tous les cas. Que l'on utilise Coolify ou Railway, coupler avec un fournisseur de base de données managée comme Supabase ou Neon donne des backups, du connection pooling et des réplicas multi-régions sans lier la base de données à la plateforme de déploiement. C'est à considérer dès qu'on a de vrais utilisateurs et de vraies données.

Scaling : des plafonds différents

Railway scale de manière fluide dans son modèle. Plus de réplicas, des instances plus grosses, des règles d'autoscaling. On atteint des limites à un moment (Railway n'est pas AWS), mais pour la plupart des apps indés, le plafond est assez haut. Le scaling horizontal et vertical sont tous les deux disponibles sans re-architecturer quoi que ce soit.

Coolify scale en upgradeant le hardware. Plus de CPU ? Un plus gros VPS. Plus de RAM ? Pareil. Ça marche jusqu'à un certain point, le scaling mono-serveur plafonne à ce que le plus gros VPS du fournisseur offre (généralement 32-64 Go de RAM). Au-delà, il faut ajouter des serveurs au cluster Coolify, ce qui fonctionne mais ajoute de la complexité. Le scaling horizontal d'apps individuelles demande de mettre un load balancer devant plusieurs instances, ce que Coolify supporte mais ne rend pas trivial.

Pour la plupart des apps indés, aucun des deux plafonds n'a d'importance. Un seul VPS bien provisionné gère plus de trafic que la plupart des produits SaaS ne verront la première année. Les problèmes de scaling sont de bons problèmes. Mais si on planifie pour la croissance, le scaling Railway est plus fluide.

Quand choisir Coolify

• Le budget d'hébergement est serré et chaque euro compte.
• On apprécie (ou au moins on tolère) gérer des serveurs et on n'a pas peur des sessions SSH.
• On fait tourner plusieurs petits projets et on veut tout mettre sur un seul serveur pas cher.
• On veut self-hoster des outils open source comme l'analytics, le monitoring ou des dashboards internes.
• Le vendor lock-in dérange et on veut posséder son infrastructure complètement.
• On a les compétences techniques pour gérer les backups, les mises à jour et les incidents serveur occasionnels.
• On compare avec d'autres options self-hosted et on veut l'expérience la plus proche de Heroku.

Quand choisir Railway

• Le temps est plus rare que le budget d'hébergement.
• On veut le chemin le plus court du code à la production avec zéro ops.
• On est fondateur solo et on ne veut pas que la maintenance serveur bouffe du temps produit.
• On a besoin de bases de données managées avec des backups automatiques auxquels on ne pense jamais.
• L'équipe inclut des gens qui ne sont pas à l'aise avec les serveurs ou les workflows CLI.
• On veut que le scaling soit un réglage dans le dashboard, pas un projet d'infrastructure.
• On évalue Railway face à Render ou Fly.io et la DX est la priorité.

Verdict final

Ce comparatif n'est pas une question de quelle plateforme est la meilleure. C'est une question de quel compromis on préfère.

Coolify est le bon choix pour les builders techniquement capables qui veulent un contrôle maximal et un coût minimal. Si on sait se débrouiller sur un serveur Linux, le temps de setup est modeste et les économies récurrentes sont significatives. Faire tourner 5 projets sur un VPS à $10/month au lieu de payer $50+/month sur Railway, c'est le genre d'optimisation qui compte quand on est en bootstrap et qu'on surveille son runway.

Railway est le bon choix pour les builders qui veulent échanger de l'argent contre du temps. La DX est exceptionnelle, la charge opérationnelle est nulle, et la plateforme ne se met pas en travers du chemin. Si on est dans le sprint initial de construction d'un produit et que chaque heure passée sur la maintenance serveur est une heure en moins sur les features, Railway mérite son prix.

Notre avis : si on est pré-revenu et que le budget est serré, on commence avec Coolify sur un VPS pas cher. On apprend les bases ops, on garde les coûts proches de zéro, et on investit le cash dans le produit. Si on génère du revenu ou que le temps vaut clairement plus que $20-50/month en hébergement, on prend Railway sans regarder en arrière. Les deux sont d'excellents outils pour les builders indés. Le bon dépend d'où on en est dans son parcours.