Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

ianflanagan1's avatar

Supervisor when deploying new build

In production, how do you gracefully handle Supervisor (which is managing queue workers and reverb) when deploying a new build and switching directories? Currently I'm doing nothing at all, just leaving the supervisor processes running, and it's working perfectly, which is a welcome surprise, but I'm curious why, and what pitfalls there might be.

In particular, I'm interested in queued jobs that might be incompatible with the new build. Will they be forced through new code?

Please let me know if these questions need editing to be more understandable. This is my first week learning Laravel and first time using Supervisor.

Thanks!

0 likes
2 replies
JussiMannisto's avatar

You can restart queue workers and Reverb gracefully through Artisan commands:

php artisan queue:restart
php artisan reverb:restart

These won't interfere with running jobs or connections, so you can run them as part of your deployment script. The processes are terminated at a safe point, and then get restarted by Supervisor. If you don't restart them, they'll keep running with your old code loaded, and you're sure to have issues.

1 like
ianflanagan1's avatar

I set up some scenarios to test it hands on.

php artisan queue:restart

worked well for editing code within the same directory, but when placing the new build in a new directory, supervisor restarted the workers in the old directory. So the command needs to come from supervisor, not artisan.

supervisorctl restart

allowed the workers to finish their current job, die, and then restarted them in the new build directory :D

"supervisorctl restart" also re-evaluates any symlink in the config file, so you can point a symlink at the new build directory, instead of editing the /etc/supervisor/conf.d files each deployment.

So the question is solved and I'm happy!

I don't think there will be an easy way to make queued jobs complete on the old build, so I'm dropping that requirement, and accounting for it in the software design rules instead (don't change the signature of any Job deployed to production)

Is there anything I got wrong here?

Please or to participate in this conversation.