By Ankit Verma
A Laravel queue worker is a long-running PHP process. On a VPS, nothing keeps it running unless you set that up. There are three common approaches, and picking the wrong one shows up as jobs that silently stop processing.
Cron: right for the scheduler, wrong for workers
Cron is perfect for the one line every Laravel app needs: schedule:run every minute. People then try to reuse it for the queue by cron-ing queue:work --once, which pays PHP bootstrap cost on every job and gives you no control over concurrency or restarts. Use cron for scheduled tasks, not as a worker manager.
Supervisor: the default, and it earns it
Supervisor is built for exactly this: keep N copies of a command running, restart them on crash, capture their output to a log, and start them on boot. A short program block with numprocs, autorestart=true, and a stopwaitsecs long enough for your slowest job covers almost every case. If the app is PHP-only, this is the answer.
PM2: reach for it when Node is already on the box
If the same server already runs a Node process under PM2, running the queue worker there too keeps supervision in one place with one dashboard. PM2 handles restarts and log rotation well. The catch is that it is a Node tool managing a PHP process, so pm2 startup and the ecosystem file have to be correct or the workers do not come back after a reboot.
Whichever you choose, restart on deploy
Workers hold old code in memory until they exit. Every deploy has to run queue:restart and let the supervisor bring them back on the new release. Skip that and the web app is on the new version while the background jobs quietly run the old one.
My default is Supervisor for pure Laravel, PM2 only when it is already there, and cron kept strictly for the scheduler.
