Laravel

Laravel

Déployez Laravel avec MySQL ou Postgres, APP_KEY, des workers de queue, Horizon et le scheduler.

  • Version : php artisan migrate --force.
  • Variables : DB_HOST, DB_PORT, DB_DATABASE, DB_USERNAME, DB_PASSWORD et APP_URL depuis votre .env.example sont reliées à la base de données provisionnée et à l’URL de l’application. APP_KEY est généré dans le format base64: de Laravel.
  • Workers : php artisan queue:work, ou php artisan horizon quand laravel/horizon est installé.
  • Octane : avec laravel/octane dans composer.json et sans Dockerfile, le processus web exécute automatiquement php artisan octane:start --server=frankenphp --host=0.0.0.0 --port=$PORT.
  • Reverb : avec laravel/reverb dans composer.json, un worker reverb exécutant php artisan reverb:start est ajouté pour vous.

Les workers de queue et le scheduler, comme processus

queue (ou horizon), reverb et un processus scheduler sont la même image que web, démarrée avec une commande artisan différente — un seul code et un seul build, plusieurs types de processus, chacun mis à l’échelle indépendamment.

web: php artisan octane:start --server=frankenphp --host=0.0.0.0 --port=$PORT
queue: php artisan queue:work
scheduler: php artisan schedule:work

Railyard ajoute queue (ou horizon quand il est installé) automatiquement; un processus scheduler exécutant schedule:work est aussi proposé dès que routes/console.php ou bootstrap/app.php planifie quelque chose. Préférez plutôt le cron de Railyard et faites-lui exécuter php artisan schedule:run à intervalle fixe — les deux fonctionnent, puisque schedule:run ne déclenche que les tâches réellement dues. Ajoutez d’autres processus depuis l’onglet Workers, ou mettez à l’échelle ce qui existe déjà depuis la CLI :

railyard scale my-app queue=2

Backend de queue et de cache

QUEUE_CONNECTION, CACHE_STORE, SESSION_DRIVER ou BROADCAST_CONNECTION réglés à redis dans votre .env.example (ou laravel/horizon lui-même) provisionnent Redis et injectent ses variables de connexion automatiquement — aucun addon à ajouter à la main. La base de données suit la même règle : DB_CONNECTION=pgsql ou mysql dans .env.example décide quel moteur est provisionné.

Configuration et secrets

Chaque variable que la config de Laravel lit avec env() est une simple variable sous Variables, ou définie avec railyard env:set my-app KEY=VALUE — jamais intégrée à l’image, donc le même build tourne sans changement de staging jusqu’en production : la parité dev/prod, pas une reconstruction par environnement. APP_KEY est généré une seule fois dans le format base64: propre à Laravel et chiffré; une clé tierce n’est jamais inventée. Pour pointer vers une base de données ou un Redis qui tourne comme son propre service sur le canvas, référencez-le avec ${{redis.RAILYARD_PRIVATE_URL}} — résolu par environnement. Voir Variables et secrets.

Déployez-le

  • Depuis un dépôt : collez l’URL Git, ou choisissez-le dans le sélecteur une fois GitHub connecté — Railyard lit composer.json et .env.example, remplit artisan migrate, le worker de queue et la base de données provisionnée, et déploie à chaque push.
  • Depuis la CLI : railyard create my-app https://github.com/me/my-app --addons mysql,redis, ou railyard git:remote && git push railyard main depuis le dépôt.
  • En un clic : ajoutez le bouton de déploiement à votre README, ou publiez-le dans le catalogue de modèles pour que n’importe qui puisse le lancer avec ses addons et variables déjà remplis.