Railway : prix, limites et comparatif avec Render en 2026

Railway : prix à l’usage ; Render : capacité de calcul réservée. C’est la principale différence entre les deux plateformes. Dans l’exemple de petite application détaillé ci-dessous, Railway Hobby revient à $15.11 par mois, contre $20 pour Render Hobby. Render inclut toutefois la restauration de la base de données, absente du chiffrage Railway. Privilégiez Railway pour ajuster librement les ressources consommées ; choisissez Render si la prévisibilité du coût des instances et la restauration Postgres incluse comptent davantage.

Railway ou Render : quelle plateforme choisir ?

Choisissez Render si vous lancez votre entreprise et cherchez à héberger une application toujours active, un worker en arrière-plan et une base Postgres payante avec restauration incluse. Un worker est un processus distinct qui exécute des tâches, comme l’envoi d’e-mails ou la création de rapports, sans faire attendre le visiteur. Chez Render, chaque service dispose d’une capacité de calcul choisie à l’avance : le montant de base de la facture est donc facile à prévoir.

Choisissez Railway si vous souhaitez héberger plusieurs services avec souplesse et acceptez de surveiller leur consommation de ressources. Cette plateforme d’hébergement d’applications facture le CPU et la mémoire utilisés par vos services. Son interface visuelle permet de suivre facilement les connexions entre l’application, le worker et la base de données. Une faible utilisation du CPU peut réduire la facture, même si les services tournent en permanence.

Pour une petite équipe, comparez aussi les offres d’espace de travail, au-delà des machines. Le minimum facturé sur Railway Pro inclut la consommation de ressources ; chez Render Pro, l’abonnement à l’espace de travail s’ajoute au calcul. Un fondateur solo peut envisager les deux offres Hobby, mais un déploiement bon marché ne garantit pas une base de données prête pour la production.

Prix et fonctionnalités vérifiés sur les pages tarifaires et dans la documentation des deux fournisseurs le 18 octobre 2026. Le verdict repose sur le mode de facturation, la restauration prévue par défaut, le fonctionnement des tâches en arrière-plan et les possibilités de mise à l’échelle. La facture présentée est calculée à partir des tarifs publiés et d’hypothèses explicites : il ne s’agit ni d’un test de déploiement ni d’un benchmark de performances.

Ces différences sont détaillées dans la documentation Postgres de Railway, la documentation de Render sur la restauration et les règles de mise à l’échelle présentées plus bas.

Railway : prix d’une petite application face à Render

Railway est moins cher dans notre scénario à faible consommation CPU ; Render permet de connaître le coût du calcul avant même de lancer l’application. Cela ne fait d’aucune des deux plateformes la moins chère dans tous les cas. Railway mesure la consommation ; Render facture l’instance choisie pendant sa durée de fonctionnement, au prorata si elle ne tourne qu’une partie du mois.

Les offres Railway actuelles sont Free à $0, Hobby avec un minimum mensuel de $5, Pro avec un minimum de $20 et Enterprise sur devis. Les minimums de Hobby et Pro sont utilisables en consommation de ressources. Pro inclut un nombre illimité de membres dans l’espace de travail. Tarifs Railway.

Chez Render, les offres d’espace de travail actuelles sont Hobby à $0, Pro à $25 par mois, Scale à $499 et Enterprise sur devis, avec le calcul facturé séparément. Pro inclut un nombre illimité de membres : le tarif n’est pas calculé par développeur. Hobby comprend 5 GB de bande passante et Pro 25 GB ; au-delà, elle coûte $0.15 par GB. Tarifs Render.

Les hypothèses de consommation

Prenons une petite application de réservation lancée par un fondateur solo. Elle comprend un service web/API, un worker qui tourne en continu et traite les tâches via la base Postgres existante, ainsi qu’un service Postgres à nœud unique. Une file de tâches nécessitant un cache distinct ajouterait un poste de dépense ; ce cas n’est pas inclus ici.

Le mois retenu compte 30 jours, soit 2,592,000 secondes. Tous les services restent actifs. La mémoire moyenne facturée est de 0.5 GB pour le service web, 0.5 GB pour le worker et 0.25 GB pour Postgres, soit 1.25 GB au total. La consommation moyenne de CPU actif est respectivement de 0.05, 0.05 et 0.02 vCPU, soit 0.12 vCPU au total. Le vCPU est une unité de capacité de traitement : une moyenne de 0.12 représente cette quantité de travail CPU sur le mois, et non une machine annoncée avec cette capacité.

On suppose également 1 GB de stockage utilisé sur le volume de la base pendant tout le mois et 1 GB de données sortantes vers Internet. Les connexions à la base restent sur le réseau privé, les builds ne dépassent pas les quotas inclus, et il n’y a ni réplicas, ni environnements de préproduction, ni disques supplémentaires, ni nœuds de haute disponibilité. Les taxes, l’enregistrement du nom de domaine et les frais d’API de l’application sont exclus.

Sur Render, retenons une instance web 0.5c-512mb à $7, un worker 0.5c-512mb à $7 et une instance Postgres 0.1c-256mb à $6. La page tarifaire indique 1 GB de stockage de base de données inclus, et la documentation de création autorise cette taille initiale. Ces instances sont volontairement très petites : rien ne dit qu’elles suffiront à toutes les applications en production. Tarifs du calcul, configuration du stockage de la base.

La comparaison porte sur les composants de l’application et la demande supposée, pas sur les performances matérielles. Chez Railway, les consommations de mémoire et de CPU servent au calcul de l’estimation ; chez Render, les tailles d’instance constituent des plafonds de capacité. Testez votre application en charge avant de considérer ces plafonds comme suffisants.

Le calcul de la facture mensuelle

Railway affiche les tarifs suivants : $0.00000386 par GB-seconde de mémoire, $0.00000772 par vCPU-seconde, $0.00000006 par GB-seconde de stockage sur volume et $0.05 par GB de trafic sortant des services. En multipliant ces tarifs exacts par les hypothèses précédentes, on obtient les montants suivants. Tarifs des ressources Railway.

Les tarifs des ressources proviennent de Railway, ceux des instances et des espaces de travail de Render. Le fonctionnement du minimum de consommation Railway est décrit dans sa documentation des offres. Les totaux sont calculés sans arrondir les valeurs intermédiaires. Les tarifs mensuels de référence arrondis par Railway produisent quelques centimes d’écart ; ici, le calcul utilise systématiquement les prix affichés à la seconde pour ce mois de 30 jours.

À partir de quand Render devient-il moins cher ?

Dans cette comparaison des offres Hobby, Render devient moins cher autour de 0.364 vCPU actif moyen sur l’ensemble des trois services, à condition que chaque service tienne toujours dans l’instance Render choisie. À mémoire, stockage, bande passante et nombre d’instances constants, le coût mensuel des ressources Railway est de $12.71192 + $20.01024 × vCPU actif moyen. Il suffit d’égaler ce montant aux $20 de Render pour trouver le point de bascule.

À 0.12 vCPU, Railway coûte $15.11. À 0.30, la facture passe à $18.71 ; à 0.50, à $22.72 ; à 0.70, à $26.72. Render reste à $20 uniquement tant que les instances retenues absorbent la charge. Il s’agit de calculs de sensibilité, pas de mesures de performances ni d’estimations du nombre de requêtes par seconde.

La mémoire peut faire grimper la facture même sans visiteurs supplémentaires. Sur le mois étudié, chaque GB moyen supplémentaire ajoute environ $10.01 de consommation Railway, avant prise en compte des minimums des offres. Un worker en attente de tâches peut continuer à occuper de la mémoire : « inactif » ne signifie donc pas « gratuit ».

Pour la prévisibilité, Render l’emporte. À tailles et nombre d’instances constants, le coût du calcul est connu. Prévoyez séparément la bande passante, les builds au-delà des quotas et la croissance du stockage. Sur Railway, configurez des alertes de consommation et surveillez les ressources réellement utilisées. Un plafond strict de dépenses de calcul arrête les services : il freine les dépenses, mais ne permet pas de servir un trafic illimité à prix fixe.

Offres gratuites : utiles pour tester, limitées pour cette architecture

Render prend l’avantage pour une démo web gratuite ; aucune des deux offres gratuites n’est un choix solide par défaut pour cette architecture complète en production. Render accorde 750 heures d’instance web gratuite par espace de travail et par mois calendaire. Un service web gratuit se met toutefois en veille après 15 minutes sans trafic entrant. La base Postgres gratuite expire au bout de 30 jours, et aucun type d’instance gratuit n’est proposé pour les workers en arrière-plan ou les tâches cron. Limites des services gratuits Render.

Railway propose actuellement une offre Free qui se poursuit après l’essai. Les nouveaux comptes reçoivent un crédit d’essai unique de $5, valable jusqu’à 30 jours, puis $1 de crédit gratuit chaque mois. Les limites de mémoire et de volume sont plus strictes sur les services gratuits, et l’accès à cron n’y est disponible que pendant l’essai. Ce crédit récurrent reste une petite enveloppe : il ne garantit pas l’hébergement gratuit de n’importe quelle application à trois services. Détails de l’offre gratuite Railway.

La mise en veille peut convenir à une démo. Pour un client qui réserve un rendez-vous payant, attendre le réveil de l’application ou découvrir que sa base a expiré est un mauvais compromis. Choisissez explicitement la configuration payante de vos services : passer un espace de travail Render à une offre supérieure ne change pas, à lui seul, l’offre de calcul d’un service gratuit.

Postgres managé : Render inclut la restauration

Choisissez Render pour bénéficier de la restauration avec une petite base payante ; choisissez Railway si la souplesse de configuration de l’infrastructure de base de données justifie les décisions supplémentaires. PostgreSQL, généralement abrégé en Postgres, est la base relationnelle qui conserve notamment les utilisateurs, les commandes et les réservations.

Render sauvegarde en continu les instances Postgres payantes pour permettre la restauration à un instant donné, c’est-à-dire le retour à un état antérieur des données. La fenêtre de restauration est de 3 jours sur les espaces de travail Hobby et de 7 jours à partir de Pro. Une restauration crée une base distincte, à valider avant de modifier la connexion de l’application. Restauration et exports Render.

Le modèle Postgres actuel de Railway est maintenu par Railway. La plateforme propose aussi une conversion explicite vers la haute disponibilité et une restauration optionnelle à un instant donné. Qualifier toute l’offre de « Postgres non managé » masque cette nuance. En revanche, modifier l’image, la commande de démarrage ou les variables du modèle peut vous rendre la responsabilité de sa gestion. Périmètre de prise en charge de Postgres chez Railway.

La fonction de restauration de Railway doit être activée. Elle archive les données dans un bucket de stockage et facture à la fois le stockage des archives et le trafic sortant de la base nécessaire à leur envoi. La documentation Postgres décrit un historique de restauration d’environ quatre semaines, une fois les archives constituées. C’est utile, mais la configuration et le mode de facturation diffèrent de la fenêtre de restauration incluse chez Render. Restauration à un instant donné chez Railway.

Restaurer une sauvegarde n’est pas basculer automatiquement

Les sauvegardes répondent à une perte de données ; la haute disponibilité répond à l’indisponibilité d’un nœud de base de données. Si une migration défectueuse supprime des réservations, une réplique de secours peut reproduire cette suppression. Il faut alors pouvoir revenir à un état antérieur. Si la base principale cesse de fonctionner, une réplique de secours peut prendre le relais sans devoir d’abord reconstruire la base à partir d’archives.

La haute disponibilité (HA) de Render exige une offre de calcul Postgres d’au moins 1 CPU. La réplique de secours est facturée aux mêmes tarifs de calcul et de stockage que la base principale. La base à $6 de l’exemple n’est pas éligible. Conditions de haute disponibilité chez Render.

La conversion vers la haute disponibilité (HA) de Railway ajoute des réplicas de base de données, des services de coordination et des proxys de connexion. La conversion automatique prend en charge les images Postgres officielles de Railway ; les images personnalisées telles que PostGIS ou TimescaleDB ne sont pas compatibles avec cette procédure. C’est une limite importante si votre application dépend de ces images. Prérequis de haute disponibilité chez Railway.

Les petites offres ont des plafonds concrets : Railway Hobby limite le stockage sur volume à 5 GB, tandis que l’instance Postgres Render de notre scénario dispose de 256 MB de RAM et accepte au maximum 100 connexions. Un volume de données croissant ou une application qui ouvre de nombreuses connexions peut imposer une autre configuration avant même que le coût du CPU ne départage les plateformes. Limites Railway, tailles des bases Render.

Pour un fondateur, la question pratique est de savoir qui détectera le problème, restaurera les données et vérifiera les réservations. Retenez une configuration de restauration que vous savez exploiter, puis répétez la procédure avant d’y stocker des données irremplaçables.

Workers et cron : des contrôles plus explicites chez Render

Render est le choix le plus lisible pour une équipe qui veut définir séparément ses services web, ses workers et ses tâches planifiées. Ses workers fonctionnent en continu et traitent les tâches en file d’attente sans recevoir de trafic réseau entrant. Railway peut également faire tourner un worker comme service continu sans exposer de point d’accès public : nul besoin d’une catégorie de produit dédiée pour exécuter un processus en arrière-plan. Workers Render, modèle de services Railway.

Utilisez un worker pour les tâches qui arrivent tout au long de la journée, comme l’envoi d’une confirmation de réservation. Réservez cron, qui lance une commande à une heure planifiée, à une tâche comme la production du rapport nocturne. Un worker qui interroge continuellement une file et une tâche planifiée de courte durée ne consomment pas les ressources de la même façon : le coût de l’un ne permet pas d’estimer celui de l’autre.

Railway intègre la planification cron dans les paramètres des services. Les exécutions doivent être espacées d’au moins 5 minutes, les horaires sont en UTC et le processus doit se terminer une fois la tâche accomplie. S’il reste actif parce qu’il a laissé une connexion à la base ouverte, Railway saute l’exécution planifiée suivante. Règles cron de Railway.

Render utilise également UTC. La plateforme reporte une exécution planifiée tant que la précédente est active, arrête toute exécution après 12 heures et applique un minimum mensuel de $1 par service cron, avec le calcul facturé à la seconde. Un lancement manuel annule d’abord l’exécution en cours. Fonctionnement de cron chez Render.

Cette différence entre une exécution sautée et une exécution reportée compte pour un rapprochement nocturne. Concevez des tâches que l’on peut relancer sans effets indésirables, enregistrez leur fin et déclenchez une alerte si le résultat attendu manque. La plateforme peut lancer votre commande ; l’application doit encore savoir si la tâche métier a abouti.

Ne supposez pas que l’option Serverless de Railway mettra en veille un worker de file d’attente. Les connexions à la base et les autres flux sortants peuvent empêcher la mise en veille ; le réveil d’un service endormi entraîne par ailleurs un démarrage à froid. Un processus qui interroge continuellement une file peut donc rester actif. Fonctionnement de Serverless chez Railway.

Régions et mise à l’échelle : le choix dépend des contraintes

Railway prend l’avantage pour répartir les réplicas d’un même service entre plusieurs régions ; Render l’emporte pour ajuster automatiquement leur nombre selon des cibles de CPU ou de mémoire. La mise à l’échelle verticale consiste à donner davantage de ressources à une instance. La mise à l’échelle horizontale consiste à en faire tourner davantage. Elles répondent à des goulets d’étranglement différents.

Railway augmente automatiquement les ressources utilisées jusqu’aux limites configurées, mais le nombre de réplicas utilisés pour la mise à l’échelle horizontale se règle manuellement. Ses réplicas multirégions acheminent le trafic public vers la région la plus proche. Chez Render, il faut choisir une offre de calcul supérieure pour augmenter les ressources par instance ; à partir de l’espace de travail Pro, le nombre d’instances peut s’ajuster automatiquement selon des cibles de CPU ou de mémoire. Mise à l’échelle Railway, mise à l’échelle Render.

Railway propose la Californie, la Virginie, Amsterdam et Singapour. Render propose l’Oregon, l’Ohio, la Virginie, Francfort et Singapour. Choisissez en fonction de la localisation de vos utilisateurs et de vos données, sans présumer qu’un fournisseur est systématiquement plus rapide. Régions Railway, régions Render.

Pour une petite application, commencez par regrouper l’API, le worker et la base de données. Répartir l’API entre plusieurs régions ne répartit pas automatiquement les écritures de la base. Multiplier les emplacements géographiques n’accélère pas non plus systématiquement une requête qui sollicite beaucoup la base.

Certaines limites sont très concrètes. Les réseaux privés de Render sont régionaux, et un service ou une base existants ne peuvent pas simplement changer de région : il faut créer un remplacement et migrer. Railway autorise les changements de région, mais déplacer un service auquel un volume est attaché exige de migrer ce volume, avec une interruption de service. Chez Render, attacher un disque persistant empêche de passer ce service à plusieurs instances. Ces contraintes sont à prendre en compte avant de stocker les fichiers envoyés par vos clients sur le disque local de l’application.

Changer de plateforme : migrer les données et les pratiques d’exploitation

Migrez lorsqu’une limite vérifiée ou un coût récurrent le justifie, pas simplement parce que l’autre tableau de bord paraît plus facile. L’interface visuelle de Railway convient à un fondateur qui veut relier ses services à l’écran. Les types de services et les Blueprints de Render conviennent à une équipe qui recherche une configuration d’infrastructure reproductible. Les deux plateformes savent déployer depuis des dépôts de code ou des images de conteneurs, ce qui facilite la portabilité de l’application ; la base de données et l’organisation de l’exploitation exigent néanmoins une migration préparée. Guide de migration de Render, guide de migration de Railway.

1. 1

   Recenser ce qui tourne

   Listez la commande de démarrage web, celle du worker, la planification cron, les variables d’environnement, les secrets, les extensions de la base, le stockage et les domaines. Repérez les tâches qui ne doivent pas s’exécuter deux fois pendant la migration.

2. 2

   Répéter la migration de la base

   Créez la base de destination, puis testez un export et une restauration. Vérifiez la compatibilité du schéma, les extensions nécessaires, le nombre d’enregistrements et les requêtes importantes de l’application. Ne placez pas les identifiants d’accès dans le dépôt de code.

3. 3

   Prévoir le traitement des dernières écritures

   Décidez comment les écritures seront arrêtées ou synchronisées pendant le transfert final. Suspendez les tâches planifiées et les workers si nécessaire pour éviter que les deux plateformes envoient la même confirmation ou traitent le même paiement.

4. 4

   Basculer et vérifier

   Mettez à jour les chaînes de connexion et les domaines, testez un parcours réel dans l’application, puis vérifiez les tâches en arrière-plan et les paramètres de restauration. Avant d’arrêter les anciens services, conservez un plan de retour arrière qui tient compte des nouvelles écritures sur la destination.

Ne migrez pas une application qui fonctionne bien pour la modeste économie obtenue sur Hobby dans cet exemple sans chiffrer le travail de migration et la période où les deux plateformes seront facturées en parallèle. Si les données clients exigent un basculement automatique, comparez d’abord les configurations de base de données plus complètes. Une facture de base à trois services ne suffit pas à trancher.

Vercel convient mieux si votre application s’articule avant tout autour d’un frontend Next.js, avec des prévisualisations intégrées aux pull requests. Sa documentation de déploiement Next.js décrit ce workflow ; notre comparatif Vercel vs Netlify et notre guide des tarifs Vercel détaillent ces options.

Fly.io convient mieux si vous voulez contrôler directement le cycle de vie, les ressources et la répartition géographique de vos machines virtuelles. Sa documentation Machines présente ces possibilités.

Render vs Railway : comment trancher ?

Commencez par Render si la restauration Postgres incluse et un budget de calcul fondé sur les instances sont les principales raisons pour lesquelles vous voulez éviter de gérer des serveurs. Commencez par Railway si la liberté d’assembler vos services et la facturation à la consommation comptent davantage. Railway constitue une alternative crédible à Render pour une application composée de plusieurs services, à condition d’assumer les hypothèses de consommation et la configuration de la restauration.

La semaine prochaine, confrontez vos besoins réels en services web, workers et base de données à l’exemple présenté. Remplacez les hypothèses de mémoire, de CPU et de trafic sortant par des mesures issues d’une charge représentative, ajoutez les paramètres de restauration nécessaires, puis comparez les totaux de l’espace de travail complet. Si votre application tourne déjà correctement sur l’une des plateformes, abordez la migration comme un projet d’entreprise avec un coût, pas comme une amélioration automatique.

Questions fréquentes

Railway ou Render : que permettent les offres gratuites ?

Les services web gratuits de Render se mettent en veille après 15 minutes d’inactivité, et sa base Postgres gratuite expire après 30 jours. Railway propose un crédit d’essai initial de $5, puis $1 de crédit gratuit par mois. Aucune des deux plateformes ne fournit des ressources gratuites illimitées pour cet ensemble complet de services web, worker et base de données fonctionnant en continu.

Railway ou Render : lequel coûte le moins cher ?

Le scénario explicite de petite application revient à $15.11 sur Railway Hobby contre $20 sur Render Hobby, ou à $20 contre $45 sur leurs espaces de travail Pro. Ce sont des scénarios calculés, pas des prix universels pour toute application. Les archives de restauration Railway sont exclues ; la restauration de la base payante Render est incluse.

Railway ou Render : lequel choisir pour un backend ?

Les deux peuvent héberger une API, des tâches en arrière-plan et Postgres. Choisissez Render pour la restauration incluse avec les bases payantes et la mise à l’échelle horizontale automatique selon des cibles à partir de Pro ; choisissez Railway pour la facturation à la consommation, son interface reliant visuellement les services et ses réplicas multirégions. Vérifiez la compatibilité de l’image de la base avant de retenir la conversion automatique vers la haute disponibilité de Railway.