> ## Knowledge Base Index
> Fetch the complete knowledge base index at: https://help.hodi.host/sitemap.xml
> Use this file to discover available pages before exploring further.
> Pure-Markdown content can be obtained by appending a '.md' suffix to the content URLs listed in the sitemap (without the trailing slash).

# 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](https://help.hodi.host/fr/article/comment-utiliser-redis-sur-mon-site-1o1y2iu/).
* **Symfony Messenger** - `php artisan messenger:consume`, un consommateur pour vos transports configurés.

||| 💡 Bon à savoir : votre worker tourne dans votre propre espace d'hébergement, avec votre version de PHP.

## Si vous déployez avec Hodifly : rien à faire

[Hodifly](https://help.hodi.host/fr/article/quest-ce-que-hodifly-1x4tzo6/) 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](https://help.hodi.host/fr/article/comment-ajouter-une-tache-planifiee-cron-1y07j6v/) 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.