If you’ve ever worked with Laravel queues, you know one thing for sure:
👉 in production, you need something to keep them running.
Without a process manager, your php artisan queue:work will eventually die, and you’ll be stuck restarting it manually.
For a long time, I (like many developers) defaulted to Supervisor for this job. But recently I explored another option: systemd — and honestly, it’s clean, simple, and already built into most Linux distros.
Let’s walk through how you can set up systemd to manage your Laravel queues.
Why systemd?
- ✅ Already part of most Linux servers (no extra install needed)
- ✅ Can automatically restart your queue worker if it crashes
- ✅ Starts queue workers on boot
- ✅ Built-in logging via
journalctl
- ✅ Fewer moving parts compared to Supervisor
Step 1: Create a systemd service file
We’ll create a service definition for our Laravel queue worker.
sudo nano /etc/systemd/system/laravel-queue.service
Paste in the following configuration:
[Unit]
Description=Laravel Queue Worker
After=network.target
[Service]
User=www-data
Restart=always
ExecStart=/usr/bin/php /path/to/your/laravel/artisan queue:work --tries=3 --sleep=3
[Install]
WantedBy=multi-user.target
Explanation:
User=www-data → Runs the queue worker under the web server user (change if needed).
Restart=always → Ensures the process restarts if it crashes.
ExecStart → The actual command that runs your queue worker. Update the path to match your Laravel app.
WantedBy=multi-user.target → Ensures it starts with the system at boot.
Step 2: Reload systemd and enable the service
After saving the file, reload systemd so it picks up the new service:
sudo systemctl daemon-reload
sudo systemctl enable laravel-queue
sudo systemctl start laravel-queue
Step 3: Manage your queue worker
Now you can use standard systemctl commands:
sudo systemctl status laravel-queue # Check status
sudo systemctl restart laravel-queue # Restart worker
sudo systemctl stop laravel-queue # Stop worker
And check logs with:
journalctl -u laravel-queue -f
This will stream logs from your queue worker in real-time.
Step 4: Scale it up (Optional)
If you want multiple workers, you can use systemd templates. For example:
Then you can run:
sudo systemctl start laravel-queue@1
sudo systemctl start laravel-queue@2
sudo systemctl start laravel-queue@3
Each one runs independently, and you can scale up as needed.
Supervisor vs systemd
| Feature | Supervisor | systemd |
|---|---|---|
| Install required | ✅ Yes | ❌ No (already included) |
| Auto restart | ✅ Yes | ✅ Yes |
| Logging | ✅ Yes | ✅ Yes (journalctl) |
| Scaling workers | ✅ Easy | ✅ Easy with templates |
| Startup on boot | ✅ Yes | ✅ Yes |
| Complexity | Higher | Lower |
If you’re already comfortable with Supervisor, it works great. But if you want fewer dependencies and tighter integration with your OS, systemd is a solid choice.
Conclusion
Laravel queues are essential for background jobs, but keeping them alive in production is just as important.
While Supervisor has been the go-to for years, systemd provides a simpler, more native approach to managing queue workers.
Next time you’re deploying a Laravel app, give systemd a try. You might not look back. 🚀