People searching “queue:work vs queue:listen” run queue:listen under systemd and then wonder why production is slow. listen boots the framework for every job. work boots once. The queue guide is the job the Vue page polls. This page is the process.
TL;DR
- queue:work is the long-running worker.
- queue:listen reloads your code each job and is the local command.
- Do not add it to a Cloud release because a forum post listed it.
- Do not call
queue:workfrom a controller so a Vue button “starts the worker”.
The fix#
Local, while you are changing the job class:
php artisan queue:listenProduction:
php artisan queue:workqueue:work does not see new code until the process restarts. On a VPS, php artisan queue:restart after deploy signals those workers. Laravel Cloud skips queue:restart. The deploy guide says so. Do not add it to a Cloud release because a forum post listed it.
What to avoid#
Gotcha
Do not call queue:work from a controller so a Vue button “starts the worker”. The button dispatches a job. A supervisor, or the platform, runs the worker. Do not run queue:work in the request that handled the click.
FAQ#
Should I use queue:work or queue:listen?
queue:work is the long-running worker. queue:listen reloads your code each job and is the local command.
What goes wrong with queue:work vs queue:listen?
Many developers run queue:listen under systemd and then wonder why production is slow. Do not add it to a Cloud release because a forum post listed it.
