WebSockets no Laravel: Reverb, Pusher e alternativas

Com o broadcasting do Laravel, o servidor avisa o navegador no momento em que algo acontece: uma notificação, uma mensagem de chat, uma encomenda que muda de estado. No navegador escuta o Laravel Echo; entre os dois é necessário um servidor de WebSockets que mantenha aberta a ligação com cada visitante. Esse servidor pode ser o Reverb, se for o próprio cliente a alojá-lo, ou um serviço compatível com o protocolo do Pusher, que o Laravel suporta de origem.

No alojamento utilizamos a segunda opção: a sua aplicação continua aqui e as ligações dos navegadores são atendidas pelo serviço externo.

Porque não oferecemos o Reverb no alojamento

O Reverb é um servidor que fica em execução e recebe as ligações dos navegadores na sua própria porta. Os processos persistentes do alojamento destinam-se a filas e outros trabalhos em segundo plano, e não damos suporte a programas que escutem numa porta. Por isso, não oferecemos o Reverb, nem o Soketi, nem outros servidores de WebSockets próprios.

Como funciona com um serviço externo

Laravel en el hosting  --HTTPS-->  servicio de WebSockets  <--WSS--  navegador con Echo

Quando a sua aplicação emite um evento, o PHP faz um pedido HTTPS ao serviço. O serviço distribui-o pelos navegadores ligados ao canal. Os navegadores ligam-se diretamente ao serviço, não ao alojamento, pelo que não consomem processos nem ligações da sua conta.

Comparação

Preços e limites verificados a 11 de outubro de 2026. Mudam com frequência: confirme-os no site de cada serviço antes de decidir.

O que mais pesa é o número de ligações simultâneas: cada separador ou ecrã com o Echo aberto ocupa uma. As mensagens contam-se por entrega: um evento recebido por 150 ecrãs consome 151 mensagens.

Ably (recomendado)

Grátis: 200 ligações simultâneas e 6 milhões de mensagens por mês.
Pago: a partir de 29 $/mês mais a utilização, com até 10.000 ligações.
Europa: guardar os dados apenas na UE é uma opção do plano Enterprise.
No Laravel: driver ably incluído no Laravel, ou o broadcaster oficial ably/laravel-broadcaster. No navegador, o Echo com o adaptador do protocolo do Pusher.

É o plano gratuito mais amplo de um serviço maduro: com 200 ligações cabe, por exemplo, um centro com bem mais de uma centena de ecrãs.

Pusher Channels

Grátis: 100 ligações simultâneas e 200.000 mensagens por dia.
Pago: a partir de 49 $/mês, com 500 ligações e 1 milhão de mensagens por dia.
Europa: cluster eu, na Irlanda.
No Laravel: driver pusher, com php artisan install:broadcasting --pusher.

É o caminho mais direto, o que a documentação do Laravel utiliza, e é suficiente se não passar de 100 ligações em simultâneo.

Outras opções compatíveis com Pusher

O PieSocket (grátis até 200 ligações) e o Vask (a partir de 10 $/mês por 500 ligações) falam o protocolo do Pusher, pelo que se configuram como o Pusher mudando o anfitrião. São serviços mais recentes e não publicam onde guardam os dados: teste-os antes de os utilizar em produção.

O que a sua conta precisa

Pedidos HTTPS de saída a partir do PHP, que o alojamento permite. Não é necessário abrir portas nem instalar nada no servidor.
Node.js para compilar o Echo com o Vite, a partir do Gestor de pacotes. O Deploy+ instala-o se o seu script o utilizar.
Um worker de filas se os seus eventos implementarem ShouldBroadcast: o Laravel envia-os a partir da fila e, sem um worker em execução, chegam tarde ou não chegam. No Avanza, Max e Elastic, crie um Worker de filas em processos persistentes. No Inicia e no Webmaster, implemente ShouldBroadcastNow: o evento é enviado no mesmo pedido, sem fila, com a contrapartida de esse pedido esperar pela resposta do serviço. Uma fila processada pelo scheduler a cada minuto não serve para tempo real.

Não precisa de Redis para o broadcasting.

Configurar o Ably

Crie uma conta no Ably, uma aplicação e uma API key. Tem a forma xxxx.yyyy:zzzz.
Nas definições da aplicação, em Protocol Adapter Settings, ative a compatibilidade com o protocolo do Pusher: o Echo liga-se ao Ably com pusher-js.
No seu projeto, em local:
```
php artisan install:broadcasting --ably
```
Se preferir fazê-lo à mão, composer require ably/ably-php instala o SDK de PHP.
No .env de produção:
```
BROADCAST_CONNECTION=ably
ABLY_KEY="xxxx.yyyy:zzzz"
VITE_ABLY_PUBLIC_KEY="xxxx.yyyy"
```
VITE_ABLY_PUBLIC_KEY é apenas a parte da chave anterior aos dois pontos. A chave completa não deve ir em nenhuma variável VITE_.

Configure o Echo com o adaptador Pusher do 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'],
});

Implemente e verifique os eventos na consola da sua aplicação no Ably.

O Ably mantém também o seu próprio broadcaster para Laravel, ably/laravel-broadcaster, com funções próprias da sua plataforma. Se o utilizar, siga a sua documentação para a parte do navegador.

Configurar o Pusher Channels

Crie uma conta no Pusher e uma aplicação de Channels no cluster eu. Em App Keys tem app_id, key e secret.
No seu projeto, em local, instale o broadcasting:
```
php artisan install:broadcasting --pusher
```
O comando pede as credenciais, instala o SDK de PHP (pusher/pusher-php-server), o Laravel Echo e o pusher-js, cria routes/channels.php e deixa o Echo configurado. Guarde as alterações no seu repositório.

No .env de produção (com o Deploy+, no menu do repositório, Editar .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}"

As variáveis VITE_ acabam dentro do JavaScript público: levam a key, que é pública, mas nunca o secret.

Verifique a configuração do Echo que o instalador deixou. Na sua forma básica, para o Pusher, é esta:

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,
});

Implemente. As variáveis VITE_ são lidas ao compilar com npm run build: se as alterar depois, volte a implementar para que o JavaScript as apanhe.
Abra o site e a Debug Console da sua aplicação no Pusher: verá cada ligação e cada evento enviado.

Para canais privados ou de presença, autorize cada utilizador em routes/channels.php. O Laravel regista a rota /broadcasting/auth que o Echo utiliza para pedir essa autorização.

Emitir um evento

Um evento emitido a partir da fila:

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)];
    }
}

Sem um worker de filas em execução, troque ShouldBroadcast por ShouldBroadcastNow. No navegador:

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

Se o evento não chegar, reveja por ordem: que BROADCAST_CONNECTION seja o do serviço, que a configuração não esteja em cache com valores antigos (php artisan config:cache), que haja um worker a processar a fila, que a consola do serviço receba o evento e que o navegador se ligue com a key correta.

Ajudamos a ligá-lo

Se a sua aplicação utilizava o Reverb noutro servidor, a mudança costuma limitar-se ao .env, à configuração do Echo e a uma implementação. Se precisar de ajuda, escreva-nos a partir da área de cliente.

Mais sobre o Laravel no alojamento em Instalar o Laravel. Referência: broadcasting no Laravel.