Skip to contentNode.js on every plan · private Redis & PostgreSQLSee what's included →

Guides

How to run Laravel queue workers and the scheduler on shared hosting

Run php artisan queue:work and schedule:work as worker processes that start with your site and restart if they die. No cron line, no Supervisor.

Yes, 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 is what Supervisor did for you on a VPS, with a form instead of a config file. Worker processes are on every plan.

This guide covers the two workers almost every Laravel app needs. The next guide covers Horizon, Reverb and Octane.

Launch a 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.
  • Pick Laravel. The command field fills in with php artisan queue:work.
  • Set Working directory to the folder that holds artisan. For a site deployed from GitHub that 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. A queue worker does not serve web requests.

Click Launch. Within a few seconds the card shows the command and a View logs link. The first lines are the launcher preparing the container, then your worker’s own output.

Add flags the same way you would in Supervisor, for example php artisan queue:work --tries=3 --sleep=2 --max-time=3600. The panel restarts the worker when max-time ends, which is a cheap way to keep memory in check.

Launch the scheduler

Launch a second worker with the command php artisan schedule:work and the same working directory. That is the whole setup. schedule:work runs the scheduler every minute in the foreground, so you no longer need the cron entry that older guides tell you to add.

Both workers can run side by side. There is no limit of one Laravel worker per site.

Check it is working

Each worker card has View logs. A healthy queue worker prints a line per job. A healthy scheduler prints Running [task name] lines once a minute, or nothing at all 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 seconds and the real error is being lost, because the log is cleared on every restart. Run the exact command once over SSH from the same working directory. The error you see there is the one the worker is hitting.

Four things that trip people up

  • The working directory must be filled in. A worker with an empty working directory never starts and never says why.
  • Use single quotes only. The command runs inside a shell wrapper that breaks on a double quote. php artisan queue:work --queue='high,default' is fine, the same with double quotes is not.
  • Every change restarts every worker. Editing or adding one worker restarts the others on the same site. Expect a short gap in queue processing when you do.
  • The container has to be awake. Workers start after the site has served at least one request. Open the site in a browser if the cards look stuck right after creating it.

Deploys

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 GitHub deploy guide has the full script.

Which driver

The database queue driver works on every plan and is enough for most apps. Redis is on every Laravel Hosting plan, and on Business and Cloud Enterprise for Linux and WordPress, switched on per site, and listens on 127.0.0.1:6379 inside the container. Set REDIS_HOST=127.0.0.1 and QUEUE_CONNECTION=redis and you are done.

Keep reading

Other guides