Run Laravel queues and the scheduler on shared hosting

Introduction

Laravel’s queue worker and scheduler run as worker processes. A worker process is a command the panel starts inside your site’s container, keeps running, and restarts if it exits. It does the job Supervisor does on a VPS, using a form instead of a configuration file.

Worker processes are available on every plan.

This guide covers the two workers most Laravel applications need. Horizon, Reverb, and Octane are covered in the Horizon, Reverb and Octane guide.

Running the Queue Worker

Open the site, then Advanced and Worker processes, and click Launch:

• Keep Automatic (Production). The worker starts with the site and restarts if it exits.
• Choose Laravel. The command field is filled in with php artisan queue:work.
• Set Working directory to the folder that holds artisan. For a site deployed from GitHub, this is deploys/current. For a site you uploaded yourself, it is wherever the project lives, for example app or public_html.
• Leave HTTP proxy off, since a queue worker does not serve web requests.

After you click Launch, the card shows the command and a View logs link within a few seconds. The first lines come from the launcher preparing the container, followed by your worker’s own output.

You may add flags as you would in Supervisor. The panel restarts the worker when max-time ends, which helps keep memory usage under control:

php artisan queue:work --tries=3 --sleep=2 --max-time=3600

Running the Scheduler

Launch a second worker with the same working directory and the following command:

php artisan schedule:work

The schedule:work command runs the scheduler every minute in the foreground, so you do not need a cron entry. Both workers may run side by side. There is no limit of one Laravel worker per site.

Checking Your Workers

Each worker card has a View logs link. A healthy queue worker prints a line per job. A healthy scheduler prints Running [task name] lines once a minute, or nothing when no task is due.

If the log stops after the launcher lines and the card keeps restarting, the command is crashing within its first few seconds. The log is cleared on every restart, so the error is lost. Run the exact command over SSH from the same working directory to see it.

Worker Requirements

Keep the following in mind when configuring workers:

• The working directory is required. A worker with an empty working directory never starts and reports no error.
• Commands may only contain single quotes. The command runs inside a shell wrapper that breaks on a double quote. php artisan queue:work --queue='high,default' will work, but the same command with double quotes will not.
• Every change restarts every worker. Editing or adding one worker restarts the others on the same site, so queue processing will pause briefly.
• The container must be awake. Workers start after the site has served at least one request. If the cards appear stuck after you create the site, open it in a browser.

Deploying

If the site deploys from GitHub, end the build script with php artisan queue:restart so the queue worker picks up the new release. The scheduler does not listen for that signal, so press Restart container on the site overview after deploying. The full script is in the GitHub deploy guide.

Queue Drivers

The database queue driver works on every plan and is sufficient for most applications. Redis is included on every Laravel Hosting and Node.js Hosting plan, and on Business and Cloud Enterprise for Linux and WordPress. It is enabled per site and listens on 127.0.0.1:6379 inside the container. To use it, set REDIS_HOST=127.0.0.1 and QUEUE_CONNECTION=redis.