Comment faire tourner des workers en arrière-plan (files, Horizon, Messenger) ?

Les files d'attente Laravel, Laravel Horizon et Symfony Messenger ont besoin d'un processus qui tourne en permanence en arrière-plan pour consommer les jobs. cPanel > Workers s'en charge : il les lance, les relance s'ils s'arrêtent et les maintient en vie après un redémarrage du serveur.

Jusqu'ici, la seule solution en hébergement mutualisé était une tâche cron qui démarrait et arrêtait un worker chaque minute. Un worker supervisé est toujours présent : un job est traité dès qu'il est mis en file.

Ce que vous pouvez lancer

• Files d'attente Laravel - php artisan queue:work, le cas classique pour Mail::queue(), les notifications, le traitement d'images et tout ce que vous envoyez dans un job.
• Laravel Horizon - php artisan horizon, pour les applications qui gèrent leurs files avec Horizon. Horizon nécessite Redis, que vous pouvez activer dans cPanel > Redis.
• Symfony Messenger - php artisan messenger:consume, un consommateur pour vos transports configurés.

Si vous déployez avec Hodifly : rien à faire

Hodifly met le worker en place tout seul, à chaque déploiement. Et uniquement si votre application en a réellement besoin :

• Une application Laravel dont QUEUE_CONNECTION est un vrai driver (database, redis, etc.) reçoit un worker queue:work.
• Une application qui requiert laravel/horizon reçoit un processus horizon à la place - jamais les deux, car Horizon gère son propre pool et faire tourner les deux traiterait chaque job en double.
• Une application Symfony reçoit un worker messenger:consume pour chaque transport qui n'est pas sync.
• Une application en QUEUE_CONNECTION=sync ne reçoit aucun worker, puisqu'elle exécute ses jobs pendant la requête. Ce n'est pas un problème : un worker resterait inactif.

Après chaque déploiement, le worker est redémarré automatiquement : il exécute donc toujours votre nouveau code, jamais la version précédente.

Le configurer à la main

Si vous avez installé votre application vous-même plutôt que via Hodifly :

1. Ouvrez cPanel > Workers puis cliquez sur Ajouter un worker.
2. Donnez-lui un nom court (queue, emails, etc.).
3. Choisissez le type : Laravel queue:work, Laravel Horizon ou Symfony Messenger.
4. Sélectionnez le dossier de l'application. Le champ vous propose les dossiers où nous trouvons un artisan (Laravel) ou un bin/console (Symfony) : il suffit normalement de choisir le vôtre dans la liste.
5. Laissez les noms de files vides pour la file par défaut, ou indiquez-les séparés par des virgules.
6. Enregistrez. Le worker démarre immédiatement.

Vous pouvez démarrer, arrêter et redémarrer chaque worker depuis cette page, et ouvrir son journal pour voir les jobs traités.

Combien de workers puis-je lancer ?

Un processus worker par vCore inclus dans votre offre. Une offre à 4 vCores permet 4 workers, et un worker configuré avec plusieurs processus en consomme autant. La page affiche votre consommation, par exemple 2 / 4.

Les workers en arrière-plan sont inclus à partir de l'offre SITE PRO. Si vous avez besoin de plus de workers, c'est le passage à une offre avec plus de vCores qui relève la limite.

Bonnes pratiques

• L'arrêt est progressif. Quand un worker est arrêté ou redémarré, il termine d'abord le job en cours : rien n'est coupé au milieu. Cela peut prendre quelques secondes, c'est normal.
• Les workers se recyclent. Chacun redémarre périodiquement, ce qui libère la mémoire que PHP accumule sur les processus de longue durée. La file n'est jamais laissée sans surveillance : le remplaçant démarre aussitôt.
• Un worker qui plante en boucle est arrêté. Si votre application ne démarre pas, nous arrêtons après quelques tentatives et affichons l'état FATAL avec le journal, plutôt que de réessayer indéfiniment en consommant vos ressources. La cause est presque toujours dans l'application : lisez le journal.
• queue:work ne recharge pas votre code tout seul. C'est pourquoi Hodifly le redémarre à chaque déploiement. Si vous modifiez une classe de job à la main (en SSH ou FTP), redémarrez le worker depuis la page.

Les tâches planifiées, c'est autre chose

Le planificateur de Laravel (schedule:run) n'est pas un worker : c'est une tâche cron, et Hodifly l'ajoute tout seul quand votre application planifie quelque chose. Les deux se complètent : le planificateur peut mettre des jobs en file, que votre worker traite ensuite.

Ce qui n'est pas pris en charge

Les serveurs WebSockets (Reverb, Soketi) et Laravel Octane ne sont pas disponibles en hébergement mutualisé. Pour du temps réel, utilisez du polling, ou un serveur virtuel ou dédié où vous maîtrisez toute la pile.

Mis à jour le : 20/09/2026