WebSockets dans Laravel : Reverb, Pusher et alternatives

Avec le broadcasting de Laravel, le serveur prévient le navigateur au moment où quelque chose se produit : une notification, un message de chat, une commande qui change d'état. Dans le navigateur, c'est Laravel Echo qui écoute ; entre les deux, il faut un serveur WebSockets qui maintienne la connexion ouverte avec chaque visiteur. Ce serveur peut être Reverb, si vous l'hébergez vous-même, ou un service compatible avec le protocole Pusher, que Laravel prend en charge nativement.

Sur l'hébergement, nous utilisons la deuxième option : votre application reste ici et les connexions des navigateurs sont gérées par le service externe.

Pourquoi nous ne proposons pas Reverb sur l'hébergement

Reverb est un serveur qui reste actif et reçoit les connexions des navigateurs sur son propre port. Les processus persistants de l'hébergement sont destinés aux files d'attente et aux autres tâches en arrière-plan, et nous ne prenons pas en charge les programmes qui écoutent sur un port. C'est pourquoi nous ne proposons ni Reverb, ni Soketi, ni d'autres serveurs WebSockets à vous.

Comment cela fonctionne avec un service externe

Laravel sur l'hébergement  --HTTPS-->  service WebSockets  <--WSS--  navigateur avec Echo

Lorsque votre application émet un événement, PHP envoie une requête HTTPS au service. Le service le distribue aux navigateurs connectés au canal. Les navigateurs se connectent directement au service, et non à l'hébergement : ils ne consomment donc ni processus ni connexions de votre compte.

Comparatif

Prix et limites vérifiés le 11 octobre 2026. Ils changent souvent : confirmez-les sur le site de chaque service avant de décider.

Le facteur le plus important est le nombre de connexions simultanées : chaque onglet ou écran avec Echo ouvert en occupe une. Les messages sont comptés par livraison : un événement reçu par 150 écrans consomme 151 messages.

Ably (recommandé)

Gratuit : 200 connexions simultanées et 6 millions de messages par mois.
Payant : à partir de 29 $/mois plus l'utilisation, avec jusqu'à 10 000 connexions.
Europe : stocker les données uniquement dans l'UE est une option de l'offre Enterprise.
Dans Laravel : driver ably inclus dans Laravel, ou le broadcaster officiel ably/laravel-broadcaster. Dans le navigateur, Echo avec l'adaptateur du protocole Pusher.

C'est l'offre gratuite la plus généreuse parmi les services éprouvés : avec 200 connexions, on peut par exemple couvrir un établissement avec plus d'une centaine d'écrans.

Pusher Channels

Gratuit : 100 connexions simultanées et 200 000 messages par jour.
Payant : à partir de 49 $/mois, avec 500 connexions et 1 million de messages par jour.
Europe : cluster eu, en Irlande.
Dans Laravel : driver pusher, avec php artisan install:broadcasting --pusher.

C'est la voie la plus directe, celle qu'utilise la documentation de Laravel, et elle suffit si vous ne dépassez pas 100 connexions simultanées.

Autres options compatibles Pusher

PieSocket (gratuit jusqu'à 200 connexions) et Vask (à partir de 10 $/mois pour 500 connexions) utilisent le protocole Pusher : ils se configurent donc comme Pusher en changeant l'hôte. Ce sont des services plus récents qui n'indiquent pas où ils stockent les données : testez-les avant de les utiliser en production.

Ce dont votre compte a besoin

Des requêtes HTTPS sortantes depuis PHP, que l'hébergement autorise. Inutile d'ouvrir des ports ou d'installer quoi que ce soit sur le serveur.
Node.js pour compiler Echo avec Vite, depuis le Gestionnaire de paquets. Deploy+ l'installe si votre script l'utilise.
Un worker de files d'attente si vos événements implémentent ShouldBroadcast : Laravel les envoie depuis la file, et sans worker actif ils arrivent en retard ou n'arrivent pas. Dans Avanza, Max et Elastic, créez un Worker de files d'attente dans les processus persistants. Dans Inicia et Webmaster, implémentez ShouldBroadcastNow : l'événement est envoyé dans la même requête, sans file, en contrepartie de quoi cette requête attend la réponse du service. Une file traitée par le scheduler chaque minute ne convient pas au temps réel.

Vous n'avez pas besoin de Redis pour le broadcasting.

Configurer Ably

Créez un compte sur Ably, une application et une API key. Elle a la forme xxxx.yyyy:zzzz.
Dans les réglages de l'application, sous Protocol Adapter Settings, activez la compatibilité avec le protocole Pusher : Echo se connecte à Ably avec pusher-js.
Dans votre projet, en local :
```
php artisan install:broadcasting --ably
```
Si vous préférez le faire à la main, composer require ably/ably-php installe le SDK PHP.
Dans le .env de production :
```
BROADCAST_CONNECTION=ably
ABLY_KEY="xxxx.yyyy:zzzz"
VITE_ABLY_PUBLIC_KEY="xxxx.yyyy"
```
VITE_ABLY_PUBLIC_KEY est uniquement la partie de la clé située avant les deux-points. La clé complète ne doit figurer dans aucune variable VITE_.

Configurez Echo avec l'adaptateur Pusher d'Ably :

import Echo from 'laravel-echo';
import Pusher from 'pusher-js';
window.Pusher = Pusher;

window.Echo = new Echo({
    broadcaster: 'pusher',
    key: import.meta.env.VITE_ABLY_PUBLIC_KEY,
    wsHost: 'main.pusher.ably.net',
    wsPort: 443,
    forceTLS: true,
    disableStats: true,
    enabledTransports: ['ws', 'wss'],
});

Déployez et vérifiez les événements dans la console de votre application sur Ably.

Ably maintient en outre son propre broadcaster pour Laravel, ably/laravel-broadcaster, avec des fonctions propres à sa plateforme. Si vous l'utilisez, suivez sa documentation pour la partie navigateur.

Configurer Pusher Channels

Créez un compte sur Pusher et une application Channels dans le cluster eu. Dans App Keys, vous trouverez app_id, key et secret.
Dans votre projet, en local, installez le broadcasting :
```
php artisan install:broadcasting --pusher
```
La commande demande les identifiants, installe le SDK PHP (pusher/pusher-php-server), Laravel Echo et pusher-js, crée routes/channels.php et laisse Echo configuré. Enregistrez les modifications dans votre dépôt.

Dans le .env de production (avec Deploy+, depuis le menu du dépôt, Modifier le .env) :

BROADCAST_CONNECTION=pusher

PUSHER_APP_ID="tu_app_id"
PUSHER_APP_KEY="tu_key"
PUSHER_APP_SECRET="tu_secret"
PUSHER_HOST=
PUSHER_PORT=443
PUSHER_SCHEME="https"
PUSHER_APP_CLUSTER="eu"

VITE_PUSHER_APP_KEY="${PUSHER_APP_KEY}"
VITE_PUSHER_HOST="${PUSHER_HOST}"
VITE_PUSHER_PORT="${PUSHER_PORT}"
VITE_PUSHER_SCHEME="${PUSHER_SCHEME}"
VITE_PUSHER_APP_CLUSTER="${PUSHER_APP_CLUSTER}"

Les variables VITE_ finissent dans le JavaScript public : elles contiennent la key, qui est publique, mais jamais le secret.

Vérifiez la configuration d'Echo laissée par l'installeur. Dans sa forme de base, pour Pusher, la voici :

import Echo from 'laravel-echo';
import Pusher from 'pusher-js';
window.Pusher = Pusher;

window.Echo = new Echo({
    broadcaster: 'pusher',
    key: import.meta.env.VITE_PUSHER_APP_KEY,
    cluster: import.meta.env.VITE_PUSHER_APP_CLUSTER,
    forceTLS: true,
});

Déployez. Les variables VITE_ sont lues lors de la compilation avec npm run build : si vous les modifiez ensuite, redéployez pour que le JavaScript les prenne en compte.
Ouvrez le site et la Debug Console de votre application sur Pusher : vous verrez chaque connexion et chaque événement envoyé.

Pour les canaux privés ou de présence, autorisez chaque utilisateur dans routes/channels.php. Laravel enregistre la route /broadcasting/auth qu'utilise Echo pour demander cette autorisation.

Émettre un événement

Un événement émis depuis la file d'attente :

namespace App\Events;

use App\Models\Pedido;
use Illuminate\Broadcasting\PrivateChannel;
use Illuminate\Contracts\Broadcasting\ShouldBroadcast;

class PedidoActualizado implements ShouldBroadcast
{
    public function __construct(public Pedido $pedido) {}

    public function broadcastOn(): array
    {
        return [new PrivateChannel('pedidos.'.$this->pedido->user_id)];
    }
}

Sans worker de files d'attente actif, remplacez ShouldBroadcast par ShouldBroadcastNow. Dans le navigateur :

window.Echo.private(`pedidos.${userId}`)
    .listen('PedidoActualizado', (e) => console.log(e.pedido));

Si l'événement n'arrive pas, vérifiez dans l'ordre : que BROADCAST_CONNECTION correspond au service, que la configuration n'est pas mise en cache avec d'anciennes valeurs (php artisan config:cache), qu'un worker traite la file, que la console du service reçoit l'événement et que le navigateur se connecte avec la bonne key.

Nous vous aidons à le connecter

Si votre application utilisait Reverb sur un autre serveur, le changement se limite généralement au .env, à la configuration d'Echo et à un déploiement. Si vous avez besoin d'aide, écrivez-nous depuis l'espace client.

Plus d'informations sur Laravel sur l'hébergement dans Installer Laravel. Référence : broadcasting dans Laravel.