Fly.io a déjà fait l’objet d’un article détaillé sur ce blog. Ce comparatif élargit la focale à deux concurrents directs sur le même segment, Railway et Render, tous trois positionnés comme des plateformes qui simplifient le déploiement de conteneurs sans la complexité d’un cluster Kubernetes ou la gestion manuelle d’un VPS. Le test a consisté à déployer exactement le même Dockerfile WordPress, sans aucune modification, sur les trois plateformes, pour un site vitrine professionnel de complexité moyenne.
Le Dockerfile de test embarquait PHP-FPM 8.2, Nginx en frontal, et une configuration standard pointant vers une base de données MySQL managée externe, cohérente avec ce que ces trois plateformes recommandent pour la persistance des données.
Mise en route : Railway en tête
Railway s’est révélé le plus rapide à mettre en route : connexion du dépôt GitHub, détection automatique du Dockerfile, et déploiement effectif en moins de trois minutes, base de données MySQL provisionnée automatiquement via son catalogue de services intégrés, avec les variables de connexion injectées automatiquement dans l’environnement du conteneur sans configuration manuelle.
Render suit de près, avec une interface tout aussi guidée, mais demande une étape supplémentaire pour lier explicitement le service de base de données au service web, une manipulation simple mais qui ajoute deux ou trois minutes au processus de mise en route par rapport à Railway.
Fly.io, déjà noté comme plus exigeant dans l’article précédent qui lui était consacré, confirme cette caractéristique face à la concurrence : le déploiement passe par sa CLI dédiée, flyctl, avec un fichier fly.toml à écrire ou générer, et aucune base de données managée native équivalente à celles de Railway ou Render, ce qui impose de configurer un service tiers séparément.
Tableau comparatif
| Critère | Fly.io | Railway | Render |
|---|---|---|---|
| Temps de mise en route | ~15 min | ~3 min | ~6 min |
| Base de données managée intégrée | Non (via Fly Postgres séparé) | Oui (MySQL, Postgres, Redis) | Oui (Postgres uniquement) |
| Stockage persistant pour uploads | Volumes natifs, configuration manuelle | Volumes, configuration simple | Disques persistants, le plus simple à monter |
| Coût mensuel estimé (trafic moyen) | ~18 € | ~22 € | ~25 € |
| Présence de datacenters en France/UE | Oui (Paris) | Oui (Europe de l’Ouest) | Oui (Francfort) |
Le vrai point de friction : le stockage persistant des médias
Un conteneur WordPress typique écrit dans wp-content/uploads, un besoin de stockage persistant que ces trois plateformes gèrent différemment. Render propose l’intégration la plus simple, avec un disque persistant attachable au service en quelques clics et monté directement sur le chemin souhaité :
# render.yaml
services:
- type: web
name: site-client
env: docker
disk:
name: uploads
mountPath: /var/www/html/wp-content/uploads
sizeGB: 10
Railway impose une configuration comparable mais légèrement plus manuelle, via l’onglet Volumes de son interface, avec un mapping de chemin à définir explicitement. Fly.io, de son côté, nécessite de créer le volume via la CLI avant le déploiement puis de le référencer dans fly.toml, une étape supplémentaire qui a occasionné une erreur de montage lors du premier essai, faute d’avoir créé le volume dans la même région que l’application elle-même, une contrainte propre à Fly.io absente chez les deux autres.
Limites communes aux trois plateformes
- Aucune des trois ne propose de solution native pour le cache d’objet persistant partagé entre plusieurs instances, un besoin qui se pose dès qu’on active le scaling horizontal : Redis externe reste nécessaire dans tous les cas.
- La facturation, dans les trois cas, reste moins prévisible qu’un VPS à prix fixe : elle dépend de l’usage réel de CPU, mémoire et bande passante, ce qui demande une surveillance des coûts sur les premiers mois pour éviter une facture surprise après un pic de trafic imprévu.
- Aucune des trois plateformes ne remplace un vrai CDN pour les assets statiques : un service tiers comme Cloudflare reste recommandé en complément dans les trois cas.
Le choix entre ces trois plateformes se joue moins sur des fonctionnalités radicalement différentes que sur le niveau de friction accepté pour la configuration initiale, chacune ayant fait des choix par défaut différents sur les mêmes briques.
Notre verdict
Pour un site professionnel qui ne justifie pas l’investissement d’un cluster Kubernetes ni la maintenance manuelle d’un VPS, Railway convainc par sa rapidité de mise en route et sa base de données managée intégrée, un choix pertinent pour un premier projet ou un client peu technique côté agence. Render prend l’avantage dès que le stockage persistant des médias devient un enjeu central, avec la configuration la plus simple des trois. Fly.io, plus exigeant à configurer, reste réservé aux projets qui ont besoin de sa flexibilité de déploiement multi-région, un besoin rare mais réel pour certains clients internationaux du parc de l’agence.
