Cet article est aussi disponible en :

Comment déployer une application Ruby on Rails ou Sinatra ?

Hodifly déploie les applications Ruby depuis GitHub ou GitLab, comme les applications Node, Python ou PHP : vous poussez, Hodifly installe les gems, construit et met en ligne.

⚠️ Attention : une application Ruby tourne en permanence derrière Passenger. Elle nécessite donc un hébergement web SITE PRO ou supérieur, comme les applications Node et Python. Les sites statiques et les applications PHP, eux, fonctionnent sur toutes les offres.

Ce qui est reconnu automatiquement

Hodifly détecte une application Ruby à partir du Gemfile et du config.ru :

Ruby on Rails : reconnu par bin/rails ou config/application.rb.
Sinatra : reconnu par la gem sinatra.
Toute application Rack : un config.ru suffit.

Un dépôt qui contient seulement un Gemfile et un _config.yml est traité comme un site Jekyll, donc comme un site statique : c'est bien ce que vous voulez pour un blog.

Le point d'entrée : `config.ru`

Passenger démarre votre application à partir du fichier config.ru placé à la racine du projet. C'est une convention Rack : il n'y a pas de « fichier de démarrage » à renseigner dans les réglages, contrairement aux applications Node.

Votre config.ru doit donc exister et se terminer par un run :

require_relative "config/environment"
run Rails.application

Ce que Hodifly fait à chaque déploiement

Bundler installe les gems dans un espace dédié à votre application. Les groupes development et test sont ignorés, et ce choix est enregistré pour que l'application démarre avec exactement les mêmes gems que celles installées. Versionnez votre Gemfile.lock.
SECRET_KEY_BASE est généré une seule fois et conservé hors des versions déployées : vos sessions et vos cookies signés survivent aux déploiements. Vous pouvez le remplacer par une variable d'environnement du projet.
Les assets sont précompilés (assets:precompile) pour Rails.
Les migrations sont jouées avant la mise en ligne de la nouvelle version. Une migration en échec laisse la version précédente en place : le site ne casse pas. Posez HODIFLY_SKIP_MIGRATIONS=1 en variable d'environnement pour désactiver ce comportement.
Les données persistantes : storage/ (fichiers envoyés par Active Storage) et log/ vivent hors des versions et sont rattachées à chacune. Elles survivent donc aux déploiements et aux retours arrière. Une base SQLite placée dans db/ ou storage/ est également conservée.

⚠️ Attention : un retour arrière restaure le code, mais pas le schéma de la base de données.

Variables d'environnement

Les variables du projet sont transmises à l'application en cours d'exécution : Rails les lit dans ENV comme d'habitude. Il n'y a pas de fichier .env généré (c'est une particularité des applications PHP). Si votre application attend un .env, ajoutez la gem dotenv-rails.

Version de Ruby

Choisissez-la dans le Runtime des réglages du projet. Elle est pré-remplie à partir de votre .ruby-version ou de la ligne ruby "3.3.0" de votre Gemfile.

Comme pour Python, modifier ces fichiers après la création du projet ne suffit pas : l'espace de gems est créé avant le build. Le journal de déploiement vous prévient, et il faut changer le Runtime dans les réglages du projet.

Déployer dans un sous-dossier

Renseignez config.relative_url_root dans config/application.rb pour que Rails génère les bonnes URL. Voir Comment déployer mon site dans un sous-dossier ?.

Ce qui n'est pas disponible

Les WebSockets (Action Cable en mode persistant) et les processus de fond permanents (Sidekiq, Solid Queue en worker dédié). Pour les traitements différés, utilisez une tâche cron depuis cPanel > Tâches Cron.