Pourquoi self-héberger Rails sur un VPS ?
Une application Rails de production combine plusieurs processus : le serveur web Puma, des workers Sidekiq pour les jobs asynchrones, PostgreSQL et Redis. Les plateformes managées facturent chaque dyno ou worker séparément, ce qui fait grimper la note dès que l'application grandit. Sur un VPS, tous ces processus cohabitent sur un même serveur que vous pilotez : vous réglez le nombre de threads et de workers Puma, vous lancez autant de workers Sidekiq que la RAM le permet, et vous gérez le précompilage des assets et le cache. Avec Rails 7 et plus, l'intégration native de Propshaft, Solid Queue et Solid Cache simplifie encore l'auto-hébergement. Vous gardez un coût fixe et une stack entièrement transparente.
Bénéfices concrets d'un Rails auto-hébergé
- Puma et Sidekiq sur le même VPS, sans facturer chaque worker séparément.
- Réglage du nombre de threads et de workers Puma selon les cœurs et la RAM.
- Jobs en arrière-plan illimités avec Sidekiq/Redis ou Solid Queue.
- PostgreSQL maîtrisé : index, sauvegardes
pg_dumpet tuning des connexions. - Précompilage des assets et cache Rails gérés localement, sans surcoût.
- Coût fixe et prévisible, idéal pour les SaaS et applications métier en croissance.
Prérequis matériels et logiciels
Rails est plus consommateur de RAM que la moyenne à cause des workers Puma et Sidekiq : visez 2 Go minimum, et 4 Go dès que vous lancez plusieurs workers ou ajoutez Redis et Elasticsearch. Installez Ruby 3.2+ via rbenv ou asdf, ou utilisez une image Docker ruby:3.3-slim. Prévoyez PostgreSQL 15, Redis pour Sidekiq et le cache, Node.js si vous utilisez un bundler JS, et Bundler. Nginx sert de frontal pour le TLS et les assets statiques. Un domaine pointé vers le VPS est requis. Définissez RAILS_ENV=production et générez une SECRET_KEY_BASE.
Déployer Rails étape par étape
Préparer le serveur et l'application
En SSH, installez Ruby 3.3, PostgreSQL et Redis (ou Docker). Clonez le dépôt et configurez les variables : DATABASE_URL, REDIS_URL, RAILS_MASTER_KEY et SECRET_KEY_BASE. Lancez bundle install --without development test.
Précompiler les assets et migrer
Exécutez RAILS_ENV=production bin/rails assets:precompile puis bin/rails db:migrate. Avec Rails 7+, Propshaft et l'importmap simplifient le pipeline d'assets sans build Node complexe.
Lancer Puma
Démarrez le serveur via bundle exec puma -C config/puma.rb, en réglant WEB_CONCURRENCY (workers) et RAILS_MAX_THREADS dans l'environnement. Faites écouter Puma sur un socket Unix pour de meilleures performances avec Nginx, et gérez le processus via systemd.
Démarrer les workers Sidekiq
Créez un service systemd qui exécute bundle exec sidekiq -e production -C config/sidekiq.yml, avec redémarrage automatique. Ajustez le nombre de threads Sidekiq selon la charge de jobs et la mémoire disponible.
Configurer Nginx et le SSL
Pointez Nginx vers le socket Puma via upstream et proxy_pass, servez public/assets directement avec un cache long, puis obtenez un certificat Let's Encrypt avec Certbot pour votredomaine.ma. Forcez le HTTPS et le renouvellement automatique.
Automatiser les déploiements
Mettez en place un script ou Kamal/Capistrano qui enchaîne git pull, bundle install, db:migrate, assets:precompile et le redémarrage de Puma et Sidekiq. Le déploiement atomique avec liens symboliques permet de revenir en arrière instantanément en cas de problème.
Surveillez l'empreinte mémoire de Puma : les processus Ruby gonflent avec le temps à cause de la fragmentation mémoire. Activez jemalloc comme allocateur (via LD_PRELOAD) pour réduire significativement la RAM consommée par les workers, et configurez un redémarrage périodique des workers Puma. Sur un VPS où la RAM est la ressource la plus limitante pour Rails, ce réglage seul peut éviter d'avoir à monter en gamme.
