Railway vs Fly.io : DX fluide ou controle infra global ?

Deux visions du PaaS moderne

Railway et Fly.io sont deux plateformes d'hebergement pour developpeurs. Les deux supportent des conteneurs, des bases de donnees, du scaling automatique. Les deux ciblent les devs qui veulent deployer sans gerer du bare metal.

Mais leur philosophie est radicalement differente.

Railway optimise pour la DX. L'objectif, c'est de rendre le deploy aussi simple que possible. Dashboard propre, provisionnement de services en un clic, logs lisibles, variables d'environnement bien gerees. On pousse son code, ca tourne.

Fly.io optimise pour le controle geographique. L'objectif, c'est de faire tourner des apps proches des utilisateurs, partout dans le monde, avec un controle fin sur les machines et les regions. C'est plus complexe, mais ca donne acces a des patterns d'architecture impossibles ailleurs.

Railway : le PaaS ou on ne pense pas a l'infra

Railway a ete concu pour que le deploy soit un non-evenement. Et sur ce point, il livre.

Le dashboard est un des meilleurs du marche. Chaque projet est visualise comme un graphe de services. On voit les connexions entre l'app, la base de donnees, le redis, les workers. C'est lisible, c'est intuitif, et ca permet de comprendre l'architecture d'un coup d'oeil.

Le provisionnement est instantane. Besoin d'un Postgres ? Un clic. Redis ? Un clic. Un cron job ? Quelques lignes de config. Railway rend la creation de services aussi simple que d'ajouter un item a une liste.

Les variables d'environnement sont bien gerees. Railway genere automatiquement les connection strings et les injecte dans les services qui en ont besoin. On ne copie-colle pas des credentials entre les onglets. C'est un detail, mais ca change la vie au quotidien.

Le deploy est rapide. Push sur Git, Railway detecte le langage, build, deploy. Pour la plupart des projets Node.js, Python, Go ou Rust, ca marche sans Dockerfile. Et quand on en a besoin, le support Docker est la.

Les preview environments marchent bien. Chaque pull request peut avoir son propre environnement avec sa propre base de donnees. C'est pratique pour tester des features en isolation avant de merger.

Le compromis : Railway est historiquement limite en termes de regions. L'app tourne quelque part, ca marche, mais on ne choisit pas finement ou. Pour une app avec des utilisateurs repartis mondialement et des besoins de latence stricts, ca peut etre un probleme.

Fly.io : le PaaS pour ceux qui pensent en regions

Fly.io part d'un principe different : ton app devrait tourner la ou sont tes utilisateurs.

Le placement geographique est central. Fly.io propose des dizaines de regions dans le monde. On choisit ou l'app tourne. On peut avoir des replicas a Paris, Sydney, et Sao Paulo. Chaque utilisateur est route vers l'instance la plus proche.

Les micro-VMs Firecracker. Au lieu de conteneurs classiques, Fly.io utilise des micro-VMs Firecracker (la techno d'AWS Lambda). Le demarrage est rapide, l'isolation est forte, et le modele de facturation est granulaire -- on paie les machines qu'on fait tourner.

Le scaling est explicite. On definit le nombre de machines, la taille memoire/CPU, les regions. C'est du controle direct, pas de l'autoscaling magique. Ca demande plus de reflexion, mais on sait exactement ce qui tourne et ce que ca coute.

Le networking est avance. Fly.io donne acces a un reseau prive entre les machines (WireGuard), du anycast IPv6, et des options de routage avancees. Pour des architectures distribuees, c'est un vrai atout.

Fly Postgres. Fly.io propose Postgres, mais c'est une app Fly managee, pas un service gere comme chez Railway. Ca veut dire que les backups, le monitoring, les upgrades de version sont plus manuels. C'est fonctionnel, mais ca demande plus d'attention.

Le compromis : Fly.io est plus complexe a operer. Le CLI est l'interface principale, la doc est dense, et certaines operations (scaling, volumes, networking) demandent de comprendre des concepts d'infra que Railway abstrait completement.

DX au quotidien : dashboard vs CLI

C'est la ou l'experience diverge le plus.

Railway, c'est un dashboard web d'abord. On visualise ses services, on configure les variables, on lit les logs, on provisionne des ressources -- tout se fait dans l'interface. Le CLI existe mais il est secondaire.

Fly.io, c'est un CLI d'abord. fly launch, fly deploy, fly scale, fly ssh console. La majorite des operations se font en ligne de commande. Le dashboard web existe mais il est plus limite et sert surtout de vue d'ensemble.

Pour un dev qui vit dans le terminal, Fly.io se sent naturel. Pour un dev qui prefere une interface visuelle claire, Railway est plus agreable.

Le onboarding illustre bien la difference. Sur Railway, on connecte son repo GitHub, on clique "Deploy", et en deux minutes l'app tourne. Sur Fly.io, on installe le CLI, on lance fly launch, on repond a des questions sur les regions et les machines, on ajuste le fly.toml, et on deploy. Le resultat est potentiellement meilleur (placement geographique optimal), mais le chemin est plus long.

Pricing : simplicite vs granularite

Railway facture a l'utilisation avec un modele simple. On paie pour le CPU, la memoire et le reseau consommes. Le plan Hobby (5$/mois) donne un credit de 5$ d'utilisation. Le plan Pro (20$/mois par membre) donne plus de ressources et des features d'equipe. Les prix sont previsibles.

Fly.io facture aussi a l'utilisation, mais le modele est plus granulaire. On paie pour chaque machine (taille et duree), chaque Go de stockage, chaque Go de bande passante sortante. Le tier gratuit existe avec quelques machines incluses. Mais la facture peut surprendre si on multiplie les regions et les machines sans y penser.

Pour une app simple avec quelques services, Railway est generalement moins cher et plus previsible. Pour une app distribuee dans plusieurs regions, Fly.io peut etre plus economique parce qu'on controle exactement les ressources allouees.

Le piege commun avec Fly.io : oublier des machines actives dans des regions qu'on n'utilise plus. Avec Railway, le dashboard rend ca visible immediatement.

Base de donnees : gere vs semi-gere

C'est un point de friction important.

Railway propose un Postgres en un clic. Backups automatiques, connection string injectee, interface de query dans le dashboard. C'est un vrai service gere. On ne pense pas a l'infra de la base de donnees.

Fly.io propose Fly Postgres, qui est en realite une app Fly qui fait tourner Postgres. C'est fonctionnel, mais les backups, le failover, et les mises a jour sont plus manuels. Fly.io a ameliore l'experience, mais ca reste en dessous du niveau de confort de Railway ou d'un Supabase.

Si la base de donnees est critique pour ton app (et elle l'est presque toujours), c'est un facteur de decision important. Avec Railway, le Postgres "marche". Avec Fly.io, il "marche si tu t'en occupes".

Scaling : automatique vs intentionnel

Railway scale en ajustant les ressources du service. On peut configurer l'autoscaling, et Railway gere le reste. C'est simple, ca couvre la majorite des cas.

Fly.io scale en ajoutant ou retirant des machines dans des regions specifiques. fly scale count 3 --region cdg,iad,nrt : trois machines, une a Paris, une en Virginie, une a Tokyo. C'est puissant, c'est explicite, mais ca demande de savoir ce qu'on fait.

Pour un SaaS avec 100 utilisateurs, l'autoscaling de Railway suffit largement. Pour une app avec des utilisateurs sur trois continents et des contraintes de latence, le scaling geographique de Fly.io est un vrai avantage.

Quand choisir Railway

• La DX et la rapidite de mise en prod sont prioritaires
• Tu veux un dashboard clair pour visualiser et gerer tes services
• Tu as besoin d'un Postgres gere sans te soucier des backups
• Ton app n'a pas de contraintes de latence geographique strictes
• Tu es dev solo ou en petite equipe et tu veux minimiser le temps passe sur l'ops
• Tu veux des preview environments pour tes pull requests

Quand choisir Fly.io

• Tu as des utilisateurs repartis mondialement et la latence compte
• Tu veux controler exactement ou tes machines tournent
• Tu es a l'aise avec le CLI et la gestion d'infra directe
• Tu as besoin d'architectures distribuees (replicas read, caches regionaux)
• Tu veux le controle granulaire sur les machines et les ressources
• Tu construis une app ou le placement geographique est un avantage produit

Verdict

Railway est le meilleur choix par defaut pour la majorite des projets. La DX est superieure, le deploy est rapide, la gestion des bases de donnees est simple, et on passe son temps a construire le produit plutot qu'a configurer l'infra.

Fly.io est le bon choix quand la geographie compte. Si tes utilisateurs sont repartis sur plusieurs continents et que la latence est un enjeu produit reel, Fly.io offre un niveau de controle que Railway n'a pas. Mais cette puissance vient avec une complexite operationnelle qu'il faut etre pret a gerer.

Si tu hesites, commence par Railway. Tu pourras toujours migrer vers Fly.io plus tard si les contraintes geographiques deviennent reelles. L'inverse (migrer de Fly.io vers Railway) est plus facile, mais tu perdras le controle fin sur le placement.