Rails a mûri — et les attentes envers l'hébergement aussi. Fini le temps où « FTP et MySQL » suffisaient. Aujourd'hui, un déploiement Rails propre implique Ruby versionné, assets compilés, base PostgreSQL, tâches asynchrones et secrets en variables d'environnement — un périmètre que la plupart des hébergements PHP d'entrée de gamme ne proposent tout simplement pas.
Une équipe qui signe un mutualisé « compatible PHP » découvre souvent en production que Puma ne peut pas rester actif, que PostgreSQL n'est pas disponible, et que personne ne sait lancer un worker Active Job. Le framework n'est pas en cause : l'hébergement n'était pas préparé pour Rails, seulement pour du PHP générique.
Attentes raisonnables en 2026
| Besoin Rails | Attente hébergeur | Mutualisé PHP typique |
|---|---|---|
| Ruby 3.2+ | Version sélectionnable | Non |
| PostgreSQL | Oui | MySQL seulement, souvent |
| Processus web persistant | Puma derrière nginx | Non |
| Active Job / Solid Queue | Processus worker | Non |
| Redis (optionnel) | Recommandé | Rare |
| Pipeline d'assets | Build au déploiement | Non applicable |
| SSH + déploiement automatisé | Oui | Très limité |
Attendre un support Rails de niveau 1 sur un VPS à quatre euros non managé, c'est confondre le prix de l'infrastructure et le service applicatif. Rails demande un environnement long-lived — pas une page PHP exécutée à la demande.
Un hébergeur honnête avoue vite ce qu'il ne fait pas : pas de Ruby, pas de worker, pas de PostgreSQL.
Trois voies d'hébergement Rails
Plateforme adaptée à Rails. Déploiement par git push, bases et Redis en option, montée en charge horizontale. Coût plus élevé, charge opérationnelle réduite. Adapté aux équipes produit sans administrateur système dédié.
VPS + Hatchbox, Capistrano ou Kamal. Contrôle total, coût infrastructure bas, vous ou un prestataire administrez. Kamal (Rails 8) cible le déploiement conteneurisé sur VPS — tendance forte en 2026.
Cloud managé + conteneurs. Kubernetes ou orchestrateur équivalent si la culture conteneur existe déjà — rare pour une première application Rails.
Checklist de déploiement production
Avant le lancement, vérifiez que RAILS_ENV=production est défini et que les credentials sont chiffrées ou injectées par l'environnement. Le pipeline d'intégration continue doit exécuter assets:precompile et les tests. Les migrations de base (db:migrate) s'accompagnent d'une sauvegarde. Puma tourne derrière nginx ou un répartiteur de charge. Un worker Solid Queue ou Sidekiq est supervisé (systemd, systemd ou équivalent). Le healthcheck /up (Rails 7.1+) répond correctement. Les journaux sont centralisés — pas seulement dans log/production.log sur le disque local.
Solid Queue, Cable et Cache (Rails 8)
Rails 8 pousse des adaptateurs basés sur la base de données. Cela change les attentes hébergeur : PostgreSQL doit encaisser les écritures des jobs, un processus worker reste obligatoire, et la latence des tâches doit être surveillée. Redis devient optionnel pour certains cas, mais reste utile à grande échelle ou avec Sidekiq legacy.
Le sommet : Rails veut un hôte honnête sur ses limites
Comparez les offres via l'annuaire et la culture de déploiement long-running décrite dans Node.js première app — les principes se recoupent.
Décider et avancer sans angle mort
Choisissez d'abord entre plateforme managée et VPS avec Kamal selon la compétence opérationnelle de l'équipe. Exigez PostgreSQL managé dès la production — pas une base de développement partagée. Planifiez un worker pour les tâches dès les premiers e-mails ou imports asynchrones. Mettez en place un pipeline d'intégration continue avec précompilation des assets et tests automatisés. Testez une restauration de base de données avant le lancement. Comparez les hébergeurs documentés via le comparateur et les guides.
Questions fréquentes
Peut-on héberger Rails sur mutualisé ?
Très difficilement — sans Ruby versionnable, processus persistants et PostgreSQL adaptés, Rails ne tourne pas correctement. Plateforme Rails ou VPS restent la norme.
Faut-il encore Redis avec Rails 8 ?
Moins obligatoire grâce à Solid Cache/Queue/Cable ; Redis reste utile pour les performances et les installations Sidekiq existantes.
Kamal remplace-t-il le PaaS ?
Kamal simplifie le déploiement sur VPS ; un PaaS retire plus de charge opérationnelle. Le choix dépend de l'équipe, pas du buzz.
Que demander au support hébergeur ?
Ruby 3.2+, PostgreSQL, accès SSH, sauvegardes, et clarté sur le périmètre de support Rails réellement couvert.
Rails en 2026 ne cherche pas l'hébergeur le plus à la mode — il cherche celui qui avoue s'il sait faire tourner Puma à minuit.