Alternatives à Railway avec des prix prévisibles pour les SaaS indie

Pourquoi les fondateurs cherchent des alternatives à Railway

Railway s'est fait un nom en étant le PaaS que les développeurs aiment vraiment utiliser. On connecte un repo GitHub, Railway détecte le framework, build l'app et la déploie en moins de 90 secondes. Besoin d'une base de données ? Un clic. Redis ? Un clic. Variables d'environnement ? Injectées automatiquement. L'expérience développeur est réellement excellente.

Alors pourquoi partir ?

Trois choses poussent les fondateurs bootstrapés à chercher ailleurs.

La tarification à l'usage est imprévisible. Railway facture par heure de vCPU, par Go de mémoire, par Go de trafic sortant et par Go de stockage de base de données. Pour une app en régime stable avec peu de trafic, c'est bon marché — souvent 3-8 $/mois. Mais un pic de trafic change les calculs rapidement. Un passage sur Hacker News, la page d'accueil de Product Hunt ou un lancement réussi, et la facture peut grimper à 30-50 $ en une seule journée. On ne peut pas fixer de plafond de dépense. On peut configurer des alertes, mais le temps de lire l'email, la charge est déjà passée.

Pour un fondateur solo qui surveille son burn rate, cette imprévisibilité est inconfortable. On veut connaître ses coûts d'hébergement avant le début du mois, pas les découvrir après.

Il n'y a pas de vrai plan gratuit. Railway a supprimé son essai gratuit en 2023 après des abus. Le plan Hobby coûte 5 $/mois et inclut 5 $ de crédits d'usage. Si l'app consomme moins de 5 $ en compute, on paie 5 $/mois tout compris. Si elle consomme plus, on paie le dépassement. Il n'y a aucun moyen de faire tourner un side project, un environnement de staging ou une app de démo pour zéro euro. Pour les indie builders qui jonglent avec plusieurs projets — certains qui génèrent du revenu, d'autres qui sont des expérimentations — payer 5 $/mois par projet dormant, ça s'additionne vite.

Les options de régions sont limitées. Railway tourne principalement dans des régions US. Si vos utilisateurs sont en Europe, en Asie-Pacifique ou en Amérique latine, chaque appel API traverse l'océan aller-retour. Pour un produit SaaS où la latence API affecte l'expérience utilisateur, ces 100-200 ms de temps de trajet en plus sont perceptibles. Fly.io déploie dans plus de 30 régions. Railway ne peut pas rivaliser sur ce point.

Aucun de ces points n'est rédhibitoire pour tous les projets. Mais si l'un d'eux vous gêne, les alternatives sont solides.

Comment on a évalué ces alternatives

On a testé chaque plateforme avec le workload typique d'un SaaS indie :

• Un service web Node.js ou Python qui gère les requêtes API
• Une base Postgres pour stocker les données applicatives
• Une instance Redis pour le cache et la gestion de sessions
• Un worker en arrière-plan qui traite les jobs asynchrones

Pour chaque plateforme, on a mesuré :

• Vitesse de déploiement : temps entre le git push et l'URL en ligne
• Coût à faible trafic : facture mensuelle pour 10 000 requêtes/jour
• Coût à trafic modéré : facture mensuelle pour 100 000 requêtes/jour
• Prévisibilité des coûts : peut-on estimer la facture à 5 $ près avant le début du mois ?
• Expérience base de données : facilité de provisionner, connecter et gérer Postgres
• Couverture mondiale : combien de régions, et à quelle distance de vos utilisateurs ?

On a optimisé pour le profil indie builder : shipper vite, garder les coûts bas, éviter l'infrastructure qui demande des compétences DevOps pour être gérée.

Analyse détaillée : ce que chaque alternative fait de mieux

Render — facturation prévisible, vrai plan gratuit

Render est le concurrent le plus direct de Railway, et les différences se résument à la philosophie de tarification. Railway facture ce qu'on consomme. Render facture par service à un tarif mensuel fixe. Les deux approches ont leurs compromis, mais le modèle de Render veut dire qu'on connaît sa facture avant le début du mois.

Le plan gratuit est la carte maîtresse de Render face à Railway. Hébergement statique gratuit avec 100 Go de bande passante par mois. Services web gratuits avec 750 heures de compute par mois. Ce sont des offres réellement utilisables — suffisantes pour des environnements de staging, des sites de documentation, des projets perso et des MVP à faible trafic. Railway n'a rien d'équivalent.

Le piège des services web gratuits, c'est la mise en veille. Après 15 minutes d'inactivité, le service s'endort. La première requête après le sommeil prend 30 à 60 secondes — un tueur de taux de conversion pour les produits face aux utilisateurs. Pour un outil interne ou un environnement de staging, ça passe. Pour tout ce qui est client-facing, on veut le plan payant.

Le plan Individual à 7 $/mois par service supprime la mise en veille et donne un conteneur dédié. Un stack SaaS standard (service web + Postgres + Redis + worker) coûte environ 28 $/mois au plan Individual. Sur Railway, le même workload coûterait peut-être 10-20 $/mois à faible trafic mais pourrait monter plus haut. Le prix de Render est fixe.

Les temps de build sont le point faible de Render face à Railway. Un build qui prend 60 secondes sur Railway peut prendre 3-5 minutes sur Render. Si on déploie plusieurs fois par jour, cette différence de vitesse d'itération est réelle. Railway utilise Nixpacks avec un cache agressif. Le pipeline de build de Render est plus lent mais fiable.

Le Postgres managé de Render est solide avec un piège bien connu : la base gratuite expire après 90 jours. On migre ses données vers une nouvelle instance gratuite (fastidieux) ou on passe au plan payant à 7 $/mois. C'est documenté clairement, mais ça surprend quand même en plein projet.

Quand choisir Render : on veut des coûts mensuels prévisibles, un vrai plan gratuit pour les side projects, et une plateforme managée où la facture ne surprend jamais. Le meilleur choix pour les fondateurs qui gèrent plusieurs projets et qui en veulent certains à coût zéro.

Fly.io — déploiement mondial pour les apps sensibles à la latence

Fly.io résout un problème que Railway n'adresse quasiment pas : la distribution géographique. Au lieu de faire tourner l'app dans un seul data center US, Fly.io déploie vos conteneurs vers des points de présence dans le monde entier. Chaque requête API est servie depuis le data center le plus proche de l'utilisateur qui la fait.

Pour un SaaS avec des utilisateurs à New York, Londres et Sydney, ça signifie des temps de réponse sous les 100 ms pour tout le monde. Sur Railway, votre utilisateur londonien ajoute 80-120 ms de latence transatlantique sur chaque requête. Sur Fly.io, sa requête ne quitte jamais l'Europe.

L'API Machines est là où Fly.io devient intéressant pour l'optimisation des coûts. Le scale-to-zero signifie que l'app s'arrête complètement quand aucune requête n'arrive et redémarre en 1-3 secondes quand le trafic revient. C'est radicalement plus rapide que les cold starts de 30-60 secondes de Render. Pour les apps avec des patterns de trafic en dents de scie — actives en heures de bureau, mortes la nuit — le scale-to-zero de Fly.io peut réduire les coûts significativement.

L'allocation gratuite inclut 3 VMs partagées avec 256 Mo de RAM chacune. C'est suffisant pour une petite API ou un service web. Fly.io propose aussi Postgres avec read replicas et LiteFS pour du SQLite distribué — une option convaincante si on veut une base répliquée près des utilisateurs sans la complexité d'un cluster Postgres multi-régions.

La courbe d'apprentissage est le principal compromis. L'expérience Railway c'est "connecter le repo, cliquer deploy". Fly.io demande d'installer la CLI flyctl, d'écrire un fichier de configuration fly.toml, et de comprendre des concepts comme les machines, volumes, régions et secrets. Le debug est plus complexe aussi — le dashboard est moins abouti que celui de Railway, et il faut parfois se connecter en SSH sur la machine pour comprendre ce qui s'est passé.

La granularité de la tarification est à la fois une force et une faiblesse. On paie séparément le CPU, la mémoire, la bande passante et le stockage. Une petite app coûte typiquement 3-10 $/mois, ce qui est compétitif avec Railway. Mais prévoir le montant exact demande de comprendre plusieurs dimensions de facturation.

Quand choisir Fly.io : les utilisateurs sont répartis mondialement et le temps de réponse impacte directement l'expérience produit. Aussi pertinent pour les applications temps réel, les services WebSocket-heavy et les workloads où le scale-to-zero fait de vraies économies.

Vercel — la plateforme frontend-first

Vercel et Railway résolvent des problèmes différents, mais ils se chevauchent suffisamment pour que les fondateurs hésitent entre les deux. Vercel excelle sur le déploiement frontend — sites statiques, apps Next.js, pages edge-rendered. Railway excelle sur l'infrastructure backend — API, bases de données, workers.

Si le projet est un frontend Next.js avec quelques API routes, Vercel est fait pour ça. Deploy previews sur chaque pull request. Rollbacks instantanés. Edge middleware. Optimisation d'images. Le workflow Git-to-production est le meilleur du marché.

Le plan gratuit est généreux pour les cas d'usage frontend : 100 Go de bande passante, 100 Go-heures d'exécution de fonctions serverless, et 1 000 optimisations d'images par mois. Un site marketing SaaS typique ou un produit early-stage tient confortablement dans ces limites.

Là où Vercel ne convient pas aux utilisateurs Railway, c'est sur les capacités backend. Pas de processus long. Pas de workers en arrière-plan. Pas de Postgres managé pour un usage général (Vercel Postgres existe mais est limité et tarifé séparément). Pas de Redis. Les fonctions serverless ont une limite d'exécution de 10 secondes sur le plan gratuit et 60 secondes sur le Pro. Si le backend fait quoi que ce soit au-delà de réponses API légères, Vercel n'est pas le bon foyer.

Le modèle de tarification a des aspérités. Le plan Pro coûte 20 $/mois par membre d'équipe — par siège, pas par projet. Les dépassements de bande passante, invocations de fonctions et optimisations d'images ont chacun leur propre compteur. Un projet avec un trafic modéré et plusieurs API routes peut atteindre 50-100 $/mois plus vite qu'on ne le pense.

Le pattern le plus efficace pour les réfugiés Railway est un déploiement split : Vercel pour le frontend, et une autre plateforme (Render, Fly.io, ou une option auto-hébergée) pour le backend et les bases de données. On profite de l'excellente DX frontend de Vercel sans forcer le backend dans un modèle serverless qui ne lui convient pas.

Quand choisir Vercel : le projet est frontend-heavy (Next.js, Astro, SvelteKit) avec des besoins backend légers. Pas un remplacement des capacités full-stack de Railway, mais la meilleure plateforme pour la moitié frontend d'une architecture split.

Coolify — la DX de Railway sur votre propre serveur

Coolify, c'est ce qui se passe quand on prend la philosophie de déploiement de Railway — git push, builds automatiques, bases de données en un clic — et qu'on la fait tourner sur sa propre infrastructure. On installe Coolify sur un VPS Hetzner à 5 $/mois, et on obtient un dashboard web qui fait l'essentiel de ce que fait Railway, sans la facturation par service.

Le calcul de coût est le point fort de Coolify face à Railway. Un Hetzner CPX21 (3 vCPU, 4 Go de RAM) à 10 $/mois peut héberger 5-10 petites applications web, plusieurs instances Postgres et Redis, et des workers en arrière-plan. Le même workload sur Railway — disons 3 services web, 2 bases de données et un worker — coûterait facilement 30-60 $/mois en charges à l'usage. Coolify consolide tout ça en une seule facture VPS.

L'expérience de déploiement est étonnamment proche de Railway. On connecte un repo GitHub, Coolify détecte automatiquement le framework avec Nixpacks (le même builder que Railway utilise), build l'app et la déploie en conteneur Docker. SSL automatique via Let's Encrypt. Gestion des variables d'environnement via le dashboard. Provisionnement de bases de données en un clic pour Postgres, MySQL, MongoDB et Redis avec sauvegardes automatiques.

Les compromis sont les compromis classiques de l'auto-hébergement. La maintenance serveur est notre responsabilité. Mises à jour OS, correctifs de sécurité, monitoring de l'espace disque et vérification des sauvegardes — tout ça nous incombe. Il n'y a pas de failover automatique — si le serveur tombe, tout tombe. Il n'y a pas de CDN mondial sauf si on met Cloudflare devant le serveur.

Pour un fondateur technique à l'aise avec l'administration Linux de base, Coolify est l'option avec le meilleur ROI de cette liste. Les économies se cumulent mois après mois, et on garde la main sur toute sa stack. Pour quelqu'un qui veut se concentrer uniquement sur le produit et ne jamais penser aux serveurs, Railway ou Render vaut le prix.

Quand choisir Coolify : on fait tourner plusieurs services, on est à l'aise avec SSH et l'administration serveur de base, et on veut une DX niveau Railway pour une fraction du coût. Le sweet spot c'est 3+ services où la tarification par service rend les plateformes managées trop chères.

DigitalOcean App Platform — le choix écosystème établi

DigitalOcean App Platform est la couche PaaS au-dessus de l'un des providers cloud les plus populaires chez les développeurs indie. Si on utilise déjà des Droplets DigitalOcean, des bases managées ou Spaces, App Platform s'intègre naturellement dans cet écosystème.

L'expérience de déploiement est compétente. On connecte un repo GitHub, on configure les variables d'environnement, on déploie. La détection automatique fonctionne pour les frameworks courants. Logs, métriques et historique de déploiement sont disponibles dans le dashboard. Ca fonctionne, mais ça ne procure pas le même plaisir que le flow de déploiement de Railway.

La tarification par conteneur est claire : 5 $/mois pour un conteneur Basic, 12 $/mois pour le Professional. C'est prévisible et facile à budgéter. Mais ça s'additionne quand on a plusieurs services. Une app web + worker + Postgres managé (15 $/mois minimum) + Redis met déjà à 30-40 $/mois. Railway gère souvent le même workload pour moins cher à faible trafic.

La vraie valeur, c'est l'intégration écosystème. Le réseau privé entre les services App Platform et l'infrastructure DigitalOcean existante fonctionne nativement. Les bases managées (Postgres, MySQL, Redis, MongoDB) se connectent sans quitter le dashboard DigitalOcean. Spaces donne du stockage objet S3-compatible. Si l'infrastructure est déjà sur DO, App Platform évite la surcharge de gestion multi-fournisseurs.

Huit régions mondiales donnent plus de choix géographiques que Railway, bien que moins que Fly.io. Pour les équipes qui servent un marché spécifique (US, EU ou APAC), c'est généralement suffisant.

Quand choisir DigitalOcean App Platform : on est déjà investi dans l'écosystème DigitalOcean et on veut un PaaS qui se connecte à ses bases de données, stockage et networking existants sans jongler entre plusieurs fournisseurs.

Koyeb — l'option serverless mondiale sous-estimée

Koyeb est la plateforme la moins connue de cette liste, et elle mérite plus d'attention. La proposition de valeur est forte : du déploiement serverless mondial avec un plan gratuit qui garde réellement les services en ligne.

Le plan gratuit est le plus gros différenciateur de Koyeb. On obtient 2 services nano et 1 service micro, et contrairement à Render, ils ne se mettent pas en veille après une période d'inactivité. L'app gratuite reste active et répond immédiatement. Pas de cold starts. Pas d'attente de 30-60 secondes pour la première requête. Pour une app de démo, une API perso ou un MVP qu'on teste avec des early users, c'est un avantage concret.

Le déploiement supporte les builds depuis GitHub (Koyeb détecte le framework et build automatiquement) et les images Docker pré-construites. La plateforme déploie dans plusieurs régions mondiales avec load balancing automatique et health checks. Un seul service peut tourner à Francfort et Washington simultanément, routant les utilisateurs vers l'instance la plus proche.

Les compromis sont la maturité et la communauté. Koyeb a lancé après Railway, Render et Fly.io. La bibliothèque de templates est plus petite. Les tutoriels communautaires et les réponses Stack Overflow sont moins nombreux. La documentation est bonne mais pas aussi profonde. Si on tombe sur un edge case, on a plus de chances de se retrouver seul par rapport aux plateformes plus établies.

Les limites de ressources du plan gratuit (nano : 0.1 vCPU, 256 Mo de RAM) contraignent ce qu'on peut faire tourner à coût zéro. Une API Node.js légère ou une app web simple tient bien. Un service ML Python gourmand en mémoire, non. Les instances payantes montent en puissance, mais à ce stade on compare la tarification payante de Koyeb à des concurrents plus établis.

Quand choisir Koyeb : on veut un plan gratuit où l'app reste active et répond instantanément, avec du déploiement mondial inclus. Idéal pour les projets early-stage, les démos et les MVP où les cold starts sont inacceptables mais payer 5 $/mois pour Railway est prématuré.

Comparaison des coûts pour un workload SaaS typique

Voici ce que coûte réellement un stack SaaS indie standard (service web + Postgres + Redis + worker en arrière-plan) sur chaque plateforme :

• Railway : facturation à l'usage, typiquement 10-20 $/mois à faible trafic. Peut monter à 30-50 $/mois lors de pics de trafic.
• Render : 7 $ (web) + 7 $ (Postgres) + 7 $ (Redis) + 7 $ (worker) = 28 $/mois fixe.
• Fly.io : facturation à l'usage, typiquement 8-15 $/mois. Le déploiement multi-régions ajoute un coût par région.
• Vercel : pas directement comparable — il faut encore un backend séparé. Frontend uniquement : 0-20 $/mois.
• Coolify sur Hetzner : 5-10 $/mois (coût VPS uniquement, tous services inclus).
• DigitalOcean App Platform : 5 $ (web) + 15 $ (Postgres managé) + 5 $ (Redis) + 5 $ (worker) = 30 $/mois.
• Koyeb : le plan gratuit couvre 2-3 services légers. Plan payant pour un stack complet : environ 15-25 $/mois.

Le pattern est clair. L'auto-hébergement (Coolify) est le moins cher si on valorise l'argent plus que le temps. Les plateformes à l'usage (Railway, Fly.io) sont les moins chères à faible trafic mais imprévisibles quand ça scale. Les plateformes par service (Render, DigitalOcean) sont les plus prévisibles mais coûtent plus cher pour les stacks multi-services. Le choix dépend de si on optimise pour le prix, la prévisibilité ou la commodité.

Quand rester sur Railway

Railway reste le bon choix dans plusieurs scénarios :

• On aime la DX et la facture est stable. Si les dépenses Railway sont prévisibles mois après mois et tiennent dans le budget, la DX seule justifie de rester. Le flow de déploiement, le provisionnement de bases de données et la gestion d'environnement de Railway sont les meilleurs de cette catégorie.
• On a besoin de bases de données en un clic sans config. Le provisionnement Postgres, MySQL, Redis et MongoDB de Railway est plus rapide et plus fluide que tous les concurrents. Un clic, 30 secondes d'attente, une connection string. Aucune autre plateforme managée n'égale cette simplicité.
• Le trafic est prévisible. La tarification à l'usage fonctionne bien quand l'usage est stable. Si l'app gère un trafic constant sans gros pics, la tarification de Railway est compétitive et souvent moins chère que les alternatives par service.
• On est sur le plan Pro avec une équipe. Les fonctionnalités équipe de Railway — projets partagés, accès par rôle, logs d'audit — sont bien conçues. Si l'équipe est déjà productive sur Railway, le coût de migration peut dépasser les économies.
• Les environnements de preview comptent dans le workflow. Les déploiements de preview automatiques par pull request de Railway, avec des bases de données isolées, sont une vraie fonctionnalité de productivité pour les équipes qui font de la code review.

Ne changez pas de plateforme juste parce que c'est théoriquement moins cher. Calculez les économies réelles, intégrez le temps d'ingénierie de la migration, et assurez-vous que le retour sur investissement est cohérent avec votre stade.

Conseils de migration : quitter Railway sans tout casser

Migrer de plateforme de déploiement est moins dramatique qu'on ne le pense, mais ça demande de la planification. Voici comment le faire proprement.

1. Commencer par un service non critique. On choisit un side project ou un environnement de staging. On le déploie de bout en bout sur la nouvelle plateforme : build, variables d'environnement, base de données, domaine. On se familiarise avec le nouveau workflow avant de toucher à la production.

2. Exporter les variables d'environnement. Railway stocke les variables d'environnement par service et par environnement. On documente chaque variable, sa valeur et quel service l'utilise. La plupart des plateformes permettent l'import en masse depuis un fichier .env ou via leur CLI.

3. Migrer la base de données avec soin. Pour Postgres, on utilise pg_dump pour exporter et pg_restore pour importer. On teste la migration sur une copie d'abord. On vérifie que toutes les contraintes, index, extensions et politiques de sécurité au niveau des lignes ont survécu au transfert. Les bases Railway sont accessibles via des connection strings standard, donc pg_dump fonctionne directement.

4. Gérer les données Redis. Si l'instance Redis ne stocke que du cache, on saute la migration — on laisse le cache se reconstruire naturellement. Si elle stocke des sessions ou des données persistantes, on utilise redis-cli --rdb pour exporter et importer. La plupart du temps, une instance Redis fraîche avec un cache vide suffit.

5. Utiliser un basculement DNS. On pointe le domaine vers la nouvelle plateforme en mettant à jour les enregistrements DNS. On garde Railway en parallèle pendant 48 heures. On met le TTL DNS à 300 secondes (5 minutes) avant le basculement pour que la propagation soit rapide. Si quelque chose ne va pas, on repointe le DNS vers Railway le temps de debug.

6. Mettre en place le monitoring avant le switch. On déploie un monitoring d'uptime (Uptime Robot, Better Uptime, ou Uptime Kuma en auto-hébergé) avant de router le moindre trafic vers la nouvelle plateforme. Les pannes silencieuses pendant la migration sont le plus gros risque. On veut savoir en moins de 60 secondes si la nouvelle plateforme ne répond pas.

7. Annuler Railway une fois la poussière retombée. On garde Railway actif pendant un cycle de facturation après la migration comme assurance. Une fois certain que la nouvelle plateforme est stable, on supprime le projet Railway pour arrêter la facturation. On télécharge les logs ou métriques qu'on veut garder avant de supprimer.

La migration en elle-même est rarement la partie difficile. La partie difficile, c'est de prendre la décision. Une fois qu'on s'engage, la plupart des apps Railway migrent vers Render, Fly.io ou Coolify en un après-midi.