Déployer Laravel sans écrire à la main une config de worker de file

La plupart de ce qui est agaçant dans l’hébergement d’une vraie application Laravel n’est pas la faute de Laravel — c’est qu’un hébergeur typique veut son propre fichier de config, sa propre définition de processus de worker de file, et sa propre copie de ce que .env.example déclare déjà. L’information nécessaire pour faire tourner l’application correctement existe déjà dans le dépôt; l’étape d’hébergement ne devrait pas avoir besoin de la redemander.

Ce qui est lu automatiquement

Au push, Railyard analyse composer.json et .env.example et câble ce que Laravel déclare déjà sur lui-même :

• DB_CONNECTION=pgsql ou mysql dans .env.example décide quel moteur de base de données est réellement provisionné — pas une liste déroulante à choisir manuellement.
• php artisan migrate --force tourne comme étape de release avant chaque déploiement.
• APP_KEY est généré une fois, dans le propre format base64: de Laravel, et stocké chiffré — jamais laissé à vous de lancer php artisan key:generate et de le coller quelque part.
• QUEUE_CONNECTION, CACHE_STORE, SESSION_DRIVER ou BROADCAST_CONNECTION réglé sur redis (ou laravel/horizon simplement présent) provisionne Redis et injecte ses variables de connexion sans addon à ajouter à la main.

railyard create my-app https://github.com/me/my-app --addons mysql,redis

ou la même chose depuis le tableau de bord une fois GitHub connecté — chaque push après le premier reconstruit et redéploie.

Les workers de file sont un type de processus, pas un hack de cron

laravel/horizon installé signifie que le processus queue lance php artisan horizon plutôt que le simple queue:work — détecté depuis composer.json, pas configuré à la main. laravel/reverb installé ajoute un processus reverb lançant php artisan reverb:start de la même façon. Chacun de ces processus est le même build que web, juste démarré avec une commande artisan différente, mis à l’échelle indépendamment :

web:    php artisan octane:start --server=frankenphp --host=0.0.0.0 --port=$PORT
queue:  php artisan horizon
reverb: php artisan reverb:start

railyard scale my-app queue=2

Un processus scheduler est aussi offert, une fois que routes/console.php ou bootstrap/app.php planifie quoi que ce soit — lançant php artisan schedule:work en continu, ou vous pouvez pointer le propre Cron de Railyard sur schedule:run à intervalle régulier; les deux sont corrects puisque schedule:run ne déclenche que ce qui est réellement dû.

Octane, si l’application l’utilise déjà

laravel/octane dans composer.json sans Dockerfile dans le dépôt signifie que le processus web tourne automatiquement sous FrankenPHP (php artisan octane:start --server=frankenphp) plutôt que le cycle de requête PHP-FPM traditionnel — détecté, pas quelque chose à câbler dans un Procfile à la main.

La config reste de la config, pas une reconstruction

Tout ce que Laravel lit avec env() vit sous Variables, ou via railyard env:set my-app KEY=VALUE depuis la CLI — jamais intégré dans l’image. Le même build tourne sans changement d’une branche de prévisualisation jusqu’à la production, ce qui est le vrai point de la parité dev/prod : un bug de staging est soit réel, soit il ne l’est pas, jamais un artefact de staging qui ferait tourner un bundle différent de la prod.

Référence complète : Documentation Laravel, Workers et tâches planifiées.