Rails

• Version : bin/rails db:prepare s’exécute avant la mise en ligne de chaque version (votre Procfile release: l’emporte).
• Valeurs par défaut en production : RAILS_ENV, RACK_ENV, RAILS_SERVE_STATIC_FILES et RAILS_LOG_TO_STDOUT sont définies si vous ne l’avez pas fait; les assets se construisent avec SECRET_KEY_BASE_DUMMY=1, donc un vrai secret n’est pas nécessaire au moment du build. SECRET_KEY_BASE est généré une seule fois.
• Bases de données : pg → Postgres, mysql2/trilogy → MySQL, redis/sidekiq → Redis. Les bases de données supplémentaires de Rails 8 (cache, queue, cable) trouvées dans config/database.yml obtiennent chacune leur propre <NAME>_DATABASE_URL.
• Workers : Sidekiq, Solid Queue (bin/jobs si présent), GoodJob, Resque et Delayed Job sont proposés à partir de votre Gemfile.lock.
• Téléversements : Active Storage sur disque reçoit automatiquement un volume storage/ persistant; ou attachez un bucket et les variables S3 sont injectées.
• Anciens gems natifs (nio4r, puma 5…) compilent sous GCC 14 sans changement.

Les workers sont un second processus, pas une seconde application

Une application, c’est un seul code et une seule image; web, worker, la commande de release et le cron sont des types de processus de cette même application, chacun mis à l’échelle indépendamment — le modèle 12-factor, pas une flotte d’applications presque identiques pour un seul code. Avec un Procfile :

web: bin/rails server -p $PORT
worker: bundle exec sidekiq

les deux apparaissent automatiquement. Sans Procfile, Railyard démarre web lui-même et propose le premier exécuteur de tâches trouvé dans votre Gemfile.lock comme processus worker. Ajoutez-en d’autres depuis l’onglet Workers de l’application, ou mettez à l’échelle ce qui existe déjà depuis la CLI :

railyard scale my-app worker=3

web est limité à une seule réplique pour l’instant; worker va de 1 à 10. Voir Workers et tâches planifiées pour le cron.

Solid Queue, trois façons

• Sa propre base de données (le défaut de Rails 8). config/database.yml déclare une entrée queue: avec migrations_paths: db/queue_migrate; Railyard la lit comme une base de données supplémentaire et provisionne un QUEUE_DATABASE_URL séparé, en plus de DATABASE_URL. bin/rails db:prepare migre les deux dans l’étape de release. Le processus worker exécute bin/jobs si votre application l’a, sinon bundle exec rake solid_queue:start.
• Partager la base de données principale. Retirez l’entrée queue: (ou faites-la pointer vers la connexion principale) et les tables de Solid Queue vivent à côté des vôtres — rien n’est provisionné en plus, un seul DATABASE_URL, la même commande worker.
• À l’intérieur de Puma, sans processus worker. Le panneau Settings → Rails du canvas, avec l’interrupteur Run Solid Queue inside Puma, définit SOLID_QUEUE_IN_PUMA=true, que le config/puma.rb par défaut de Rails 8 lit déjà (plugin :solid_queue if ENV["SOLID_QUEUE_IN_PUMA"]). Puma distribue les jobs lui-même; retirez le processus worker et mettez plutôt web à l’échelle.

Le même panneau ajoute Action Cable sur Solid Cable (WebSockets, qui provisionne son propre CABLE_DATABASE_URL), YJIT et Thruster devant Puma.

Configuration et secrets

Rien que des variables d’environnement : définissez-en une sous Variables, ou avec railyard env:set my-app KEY=VALUE depuis la CLI, et la même image tourne sans changement de staging jusqu’en production — la parité dev/prod, pas une branche au moment du build. SECRET_KEY_BASE et tout autre secret propre à votre application sont générés une seule fois et chiffrés; une clé tierce n’est jamais inventée pour vous. Pour pointer vers un Postgres ou un Redis qui tourne comme son propre service sur le canvas plutôt que comme un addon sur le serveur de l’application, référencez-le avec ${{redis.REDIS_URL}} — résolu par environnement, la même syntaxe de référence entre services utilisée partout. Voir Variables et secrets.

Précompiler les assets (Tailwind, esbuild, importmap)

assets:precompile s’exécute dans l’étape de build sans aucune configuration de votre part : le build intègre une chaîne Node directement dans le build Ruby, donc une étape tailwindcss:build ou cssbundling-rails/esbuild enchaînée derrière fonctionne tout simplement — il n’y a pas d’étape Dockerfile séparée ni de pre-deploy hook à écrire. Si la précompilation a besoin de la base de données ou de Redis — un initializer qui interroge au démarrage, par exemple — et que seul le serveur de l’application les a, Railyard détecte l’échec et reporte automatiquement cette même étape à la phase de release, là où ils existent. Pousser une image déjà construite plutôt que de laisser Railyard la construire fonctionne de la même façon : les assets se compilent d’abord contre des conteneurs Postgres et Redis temporaires sur le serveur de build et sont intégrés à l’image avant qu’elle n’atteigne le serveur de l’application, donc votre vraie base de données n’est jamais touchée. Vous n’avez besoin d’aucun release_command pour tout ça — n’en définissez un que si db:prepare ne suffit pas, par exemple un script de migration de données.

Déployez-la

• Depuis un dépôt : collez l’URL Git, ou choisissez-la dans le sélecteur une fois GitHub connecté — Railyard lit le Gemfile, remplit la liste des processus, les bases de données et les variables documentées, et déploie à chaque push.
• Depuis la CLI : railyard create my-app https://github.com/me/my-app --addons postgres,redis, ou exécutez railyard git:remote && git push railyard main depuis le dépôt pour déployer à chaque push sans GitHub.
• En un clic : ajoutez le bouton de déploiement à votre README, ou publiez-la dans le catalogue de modèles pour que n’importe qui puisse la lancer avec ses addons et variables déjà remplis.