Yes. Laravel queue workers are long-lived processes that keep the booted application in memory, so they do not notice code changes until restarted. After a security patch, a dependency update or a secret rotation, run php artisan queue:restart as part of every deploy.
Why this is a security issue, not just a bug
The Laravel documentation states that workers store the booted application state in memory and will not see changes to your code base once started. It adds that static state is not reset between jobs.
Think about what that means after a fix. You merge a patch for a validation flaw, deploy, and the web servers run the new code. If the workers were not restarted, background jobs still execute the vulnerable version. The same goes for rotated credentials and a new APP_KEY: a worker that booted before the change keeps using what it loaded.
The routine
php artisan queue:restart
The documented behaviour is a graceful restart. Workers finish the job they are on, then exit, and your process manager starts fresh ones. The documentation recommends running workers under Supervisor so a stopped worker comes back automatically.
| Option | What it does | When to use |
|---|---|---|
queue:restart in deploy script | Graceful restart of all workers | Every deploy |
queue:listen | Reloads code each job, but is slower | Local development |
| Max jobs option with Supervisor | Worker exits after N jobs | Limit memory growth |
| Max time option with Supervisor | Worker exits after N seconds | Bound how stale a worker can get |
The max jobs and max time options are described in the docs as ways to release accumulated memory, but they also put a ceiling on how long a worker can run old state.
Checklist for a patch deploy
- Deploy the code and update the environment.
- Run
php artisan optimizeif you cache config, routes and views. - Run
php artisan queue:restart. - Confirm Supervisor started new worker processes.
- Check worker start times, not only web responses.
- Watch the failed jobs list for new errors.
Step 5 is the one people skip. A healthy website tells you nothing about the age of a worker.
Watch the timeout interplay
By default the job timeout is 60 seconds, and a job running past it makes the worker exit with an error. Your process manager normally restarts it. If a job has a long timeout, a graceful restart waits for it to finish, so a patch may take that long to reach all workers. For urgent fixes, know your longest timeout.
Quick check
Does queue:restart kill running jobs?
No. It signals workers to exit after they finish the current job, so in flight work is not cut off.
What if I forget to restart?
Workers keep running the version they booted with, including vulnerable code or an old secret, until they exit for another reason.
Safeguard's reachability analysis and fix pull requests can show which updates matter for your code, and autonomous remediation is off by default. A free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
