Deploying a Laravel application with queues and scheduled tasks

One repository, three processes

A production Laravel application usually needs more than its HTTP process. The web service handles requests, Horizon consumes queued work, and the scheduler dispatches recurring jobs. They should share one codebase and release, but run independently so each process can scale and restart safely.

Connect the repository to Darwa and select the production branch. Darwa detects PHP and Composer, installs locked dependencies, and creates an immutable release image. Add the application key, database URL, cache connection, and other secrets as environment variables rather than committing them to Git.

Define the services

Use the normal web command for the HTTP service. Create a worker from the same repository with php artisan horizon, then add a scheduled process with php artisan schedule:work. Because all three use the same release, a deployment never mixes application versions.

web        php artisan serve --host=0.0.0.0 --port=$PORT
worker     php artisan horizon
scheduler  php artisan schedule:work

Give the worker its own health and restart policy. Queue depth can then scale worker capacity without adding unnecessary web instances. Keep the scheduler at exactly one instance so a recurring task is not dispatched twice.

Release with confidence

Run migrations as a release command before traffic moves to the new version. Darwa keeps the previous release available for rollback and shows build output, process health, and application logs together. A failed worker no longer hides behind a healthy web process: every service reports its own state.

Push the next commit normally. Darwa builds once, rolls the three processes forward, and preserves the Git workflow your team already uses.