Recently, I released a Laravel package called EasyDeploy, and someone asked me why I included php artisan queue:restart instead of just using php artisan queue:work or php artisan queue:listen.
This question made me realize that many developers aren't fully aware of how Laravel's queue system works, especially when using Supervisor. So in this post, let's break it down step by step.
By the way, I will shorten the command to like queue:work. I hope you can understand that it's mean php artisan queue:work
🚀 queue:work vs queue:listen
Before we talk about queue:restart, let's first understand the difference between queue:work and queue:listen.
🛠 php artisan queue:work
Runs a queue worker once and then exits.
Since Laravel now runs
queue:workin daemon mode by default, you can simply use:
php artisan queue:work
- Because of
queue:workruns in daemon mode by default, the worker stays running without restarting Laravel for every job, making it faster and more efficient for production.
🎧 php artisan queue:listen
Listens for new jobs continuously.
Restarts Laravel for every job, which ensures fresh code but makes it slower than queue:work.
Good for development, but not recommended for production due to performance overhead.
✅ Which One to Use?
Use queue:work in production for better performance since it already runs in daemon mode by default.
Use queue:listen in development when you want changes to be reflected immediately without restarting the worker.
🔄 Why queue:restart Is Necessary
Now that we understand the difference, let's talk about queue:restart.
Even if you're using queue:work, the worker keeps running indefinitely. This means:
If you deploy new code, the worker still runs old code because it never restarted.
If you update a model, job, or database structure, the queue worker won’t pick up the changes. Because the worker does not automatically reload the application state.
To solve this, Laravel provides:
php artisan queue:restart
This command signals all workers to gracefully exit after finishing their current job, allowing them to be restarted and reload the updated code.
🤖 How Supervisor Fits In
Many Laravel developers use Supervisor to keep queue workers running.
Supervisor auto-restarts workers if they crash, ensuring that queue jobs are always processed.
However, Supervisor does not restart workers when you deploy new code.
This is why
queue:restartis important: it tells existing workers to stop so that Supervisor can restart them with the latest code.
📌 Without queue:restart, your queue workers might continue using old code after deployment.
🔥 Best Practices for Laravel Queues in Production
When deploying updates, always do:
php artisan migrate --force
php artisan queue:restart
This ensures that:
✅ Database migrations apply correctly.
✅ Queue workers reload the latest code.
✅ No jobs get stuck due to outdated logic.
This command is included in my package. I'm using this for years
🎯 Final Thoughts
Understanding how Laravel queues work is crucial for building reliable and scalable applications. If you're using Supervisor, make sure to include queue:restart in your deployment workflow to prevent workers from running outdated code.
I hope this post clarifies the difference between queue:work, queue:listen, and why queue:restart is necessary.
If you're interested in automating your Laravel deployments, check out EasyDeploy!
Have any questions? Let's discuss in the comments! 🚀
Top comments (0)