Desplegar Laravel sin escribir a mano la configuración del queue worker

La mayor parte de lo molesto de hospedar una app de Laravel real no es culpa de Laravel — es que un host típico quiere su propio archivo de configuración, su propia definición de proceso de queue worker, y su propia copia de lo que .env.example ya declara. La información que de verdad se necesita para correr la app correctamente ya existe en el repo; el paso de hosting no debería tener que volver a pedirla.

Qué se lee automáticamente

En cada push, Railyard analiza composer.json y .env.example y conecta lo que Laravel ya declara sobre sí mismo:

DB_CONNECTION=pgsql o mysql en .env.example decide qué motor de base de datos se aprovisiona en realidad — no un dropdown para elegir a mano.
php artisan migrate --force corre como el paso de release antes de cada despliegue.
APP_KEY se genera una sola vez, en el propio formato base64: de Laravel, y se guarda cifrado — nunca te deja a ti correr php artisan key:generate y pegarlo en algún lado.
QUEUE_CONNECTION, CACHE_STORE, SESSION_DRIVER o BROADCAST_CONNECTION definidos como redis (o laravel/horizon presente, sin más) aprovisiona Redis e inyecta sus variables de conexión sin ningún complemento que agregar a mano.

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

o lo mismo desde el panel una vez que GitHub está conectado — cada push después del primero reconstruye y redespliega.

Los queue workers son un tipo de proceso, no un truco de cron

Tener laravel/horizon instalado hace que el proceso queue corra php artisan horizon en vez del queue:work plano — detectado a partir de composer.json, no configurado a mano. Tener laravel/reverb instalado agrega un proceso reverb que corre php artisan reverb:start de la misma forma. Cada uno de estos es el mismo build que web, solo iniciado con un comando artisan distinto, escalado de forma independiente:

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

También se ofrece un proceso scheduler, en cuanto routes/console.php o bootstrap/app.php programan algo — corriendo php artisan schedule:work de forma continua, o puedes apuntar el propio Cron de Railyard a schedule:run en un intervalo en su lugar; cualquiera de las dos es correcta ya que schedule:run solo dispara lo que de verdad toca ejecutar.

Octane, si la app ya lo usa

Tener laravel/octane en composer.json sin un Dockerfile en el repo hace que el proceso web corra bajo FrankenPHP automáticamente (php artisan octane:start --server=frankenphp) en vez del ciclo de request tradicional con PHP-FPM — detectado, no algo que conectar a mano en un Procfile.

La configuración sigue siendo configuración, no un rebuild

Todo lo que Laravel lee con env() vive en Variables, o con railyard env:set my-app KEY=VALUE desde la CLI — nunca horneado en la imagen. El mismo build corre sin cambios desde una rama de preview hasta producción, que es justamente el sentido real de la paridad dev/prod: un bug de staging es real o no lo es, nunca un artefacto de que staging esté corriendo un bundle distinto al de prod.

Referencia completa: Documentación de Laravel, Workers y jobs programados.