Fazendo deploy de Laravel sem escrever à mão a configuração do queue worker

A maior parte do que é irritante em hospedar uma aplicação Laravel de verdade não é culpa do Laravel — é que um host típico quer seu próprio arquivo de configuração, sua própria definição de processo queue-worker, e sua própria cópia do que o .env.example já declara. A informação real necessária pra rodar a aplicação corretamente já existe no repositório; a etapa de hospedagem não deveria precisar pedir por ela de novo.

O que é lido automaticamente

No push, o Railyard analisa o composer.json e o .env.example e conecta o que o Laravel já declara sobre si mesmo:

DB_CONNECTION=pgsql ou mysql no .env.example decide qual engine de banco de dados de fato é provisionada — não um dropdown pra escolher manualmente.
php artisan migrate --force roda como etapa de release antes de cada deploy.
APP_KEY é gerado uma vez, no próprio formato base64: do Laravel, e guardado criptografado — nunca deixado pra você rodar php artisan key:generate e colar em algum lugar.
QUEUE_CONNECTION, CACHE_STORE, SESSION_DRIVER ou BROADCAST_CONNECTION definidos como redis (ou laravel/horizon presente de qualquer forma) provisiona o Redis e injeta as variáveis de conexão dele sem addon pra adicionar à mão.

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

ou a mesma coisa pelo dashboard depois que o GitHub estiver conectado — todo push depois do primeiro reconstrói e faz o deploy de novo.

Queue workers são um tipo de processo, não um hack de cron

laravel/horizon instalado significa que o processo queue roda php artisan horizon em vez do queue:work simples — detectado a partir do composer.json, não configurado à mão. laravel/reverb instalado adiciona um processo reverb rodando php artisan reverb:start do mesmo jeito. Cada um desses é o mesmo build que o web, só iniciado com um comando artisan diferente, escalado independentemente:

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

Um processo scheduler também é oferecido, uma vez que routes/console.php ou bootstrap/app.php agenda alguma coisa — rodando php artisan schedule:work continuamente, ou você pode apontar o próprio Cron do Railyard pro schedule:run num intervalo no lugar; os dois estão corretos já que schedule:run só dispara o que de fato está na hora.

Octane, se a aplicação já usar

laravel/octane no composer.json sem Dockerfile no repositório significa que o processo web roda sob o FrankenPHP automaticamente (php artisan octane:start --server=frankenphp) em vez do ciclo de requisição tradicional do PHP-FPM — detectado, não algo pra conectar à mão num Procfile.

Configuração continua sendo configuração, não um rebuild

Tudo que o Laravel lê com env() vive em Variables, ou em railyard env:set my-app KEY=VALUE pela CLI — nunca embutido na imagem. O mesmo build roda sem mudanças desde uma branch de preview até a produção, que é o ponto real da paridade dev/prod: um bug de staging ou é real ou não é, nunca um artefato de staging rodando um bundle diferente do que a produção roda.

Referência completa: Laravel docs, Workers and scheduled jobs.