Fly.io, Render et Railway partagent un même point de départ : aucune des trois n’a été conçue pour WordPress. Elles ciblent des applications conteneurisées génériques, ce qui change fondamentalement la manière dont on pense l’hébergement d’un back-office WordPress exposé uniquement via une API REST ou GraphQL à un front découplé en Next.js ou Nuxt. Sur un projet récent de ce type, nous avons testé les trois options en conditions réelles pendant quatre semaines, avec la même image Docker et le même volume de contenu.
Le contexte technique était le suivant : un WordPress purement back-office, sans thème public, servant uniquement de source de contenu via WPGraphQL, avec un trafic d’écriture faible (quelques dizaines d’articles par semaine) et un trafic de lecture concentré sur les heures de build du front. Ce profil particulier — peu de trafic HTTP direct, mais des pics de charge CPU au moment des builds — a fortement influencé notre verdict.
Fly.io : le contrôle le plus fin, au prix de la complexité
Fly.io déploie des machines virtuelles légères proches de véritables VPS, avec un contrôle complet sur le réseau, le volume persistant et la configuration système. C’est la plateforme où nous avons pu répliquer le plus fidèlement notre stack de production habituelle : PHP-FPM, Nginx, MySQL sur un volume attaché. La contrepartie est un fichier fly.toml à maîtriser et une compréhension nécessaire des régions et des volumes pour éviter les pertes de données au redémarrage.
Render : la simplicité au prix de la flexibilité
Render propose une expérience proche de Heroku à l’époque de sa popularité : un dépôt Git connecté, un build automatique, un service web exposé sans configuration réseau à gérer. Pour un WordPress headless, cette simplicité a une limite claire : la base de données managée de Render est un service séparé facturé indépendamment, et le stockage de fichiers (médias, uploads) n’est pas persistant sur l’offre standard sans passer par un disque payant en supplément.
Railway : le compromis pour une petite équipe
Railway se situe entre les deux : une interface proche de Render en simplicité, mais avec des volumes persistants disponibles nativement et une tarification à l’usage qui reste lisible sur un petit projet. C’est la plateforme sur laquelle nous avons mis le moins de temps à obtenir un environnement fonctionnel, en partant de notre image Docker existante sans modification majeure.
Tableau comparatif sur notre cas d’usage
| Critère | Fly.io | Render | Railway |
|---|---|---|---|
| Temps de mise en place | Une journée | Deux heures | Une heure |
| Volume persistant natif | Oui | Payant en sus | Oui |
| Contrôle réseau fin | Élevé | Faible | Moyen |
| Coût mensuel observé | 18 € | 32 € | 21 € |
Ce qui manque partout : les spécificités WordPress
Aucune des trois plateformes ne propose de gestion native des tâches cron WordPress, du cache d’objets persistant ou de la purge de cache CDN liée aux mises à jour de contenu. Sur les trois, nous avons dû ajouter manuellement un service de cron externe déclenchant wp cron event run --due-now, ainsi qu’un plugin de cache d’objets pointant vers un Redis externe hébergé séparément. Cette charge de configuration additionnelle réduit en partie l’avantage de simplicité apparente de Render et Railway.
- Sur Fly.io, le cron a été géré via une machine dédiée planifiée, ce qui demande de comprendre le système de machines à la demande.
- Sur Render, un cron job séparé (offre payante distincte) a été nécessaire.
- Sur Railway, un service cron intégré au projet a suffi, avec une configuration minimale.
Notre verdict
Pour un WordPress headless à faible trafic d’écriture et une petite équipe technique, Railway offre le meilleur rapport entre simplicité de mise en place et contrôle réel sur la persistance des données. Fly.io reste préférable dès que le trafic augmente ou que l’équipe a l’habitude d’administrer des VPS classiques, car le contrôle fin évite les mauvaises surprises à l’échelle. Render, malgré son excellente expérience développeur, s’avère le choix le plus coûteux dès qu’on ajoute stockage persistant et cron externe, ce qui en fait notre dernier choix des trois pour ce cas d’usage précis.
