# Fly.io, Railway ou Render pour héberger un WordPress conteneurisé

> Simplicité de mise en route, coût réel et limites de ces trois plateformes pour héberger un site WordPress professionnel conteneurisé.

- Auteur : Clément Hadrot
- Publié le : 2026-08-22
- Mis à jour le : 2026-08-22
- Catégorie : Outils & workflow
- URL : https://wpmoderne.dev.wordpress-developpement.fr/outils/fly-io-railway-render-wordpress-conteneurise/

## L’essentiel

- Railway offre la mise en route la plus rapide pour un premier déploiement
- Render impose le stockage persistant le plus simple à configurer
- Fly.io reste le plus flexible mais demande le plus de configuration manuelle

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

> L'essentiel à retenir : Railway offre la mise en route la plus rapide pour un premier déploiement ; Render impose le stockage persistant le plus simple à configurer ; Fly.io reste le plus flexible mais demande le plus de configuration manuelle

| 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.