Laravel and ecosystem / Pusher Protocol Pusher/Reverb mode

Pusher Protocol

Socket Conveyor provides a Pusher protocol mode for WebSocket connections and REST broadcasting. This guide describes configuration with Laravel's reverb or pusher broadcaster, Laravel Echo, and pusher-js. Migration requires matching server, broadcaster, client, and authorization settings; application changes may also be needed for your integration.

These examples do not establish full Pusher or Reverb feature parity. Verify the features and package versions your application uses before switching servers; see the installation requirements for the current compatibility evidence.

When to use Pusher mode

Keep Laravel's event broadcasting — broadcast(), ShouldBroadcast.

Your frontend uses Laravel Echo — .channel(), .private(), .join().

Configure pusher-js clients and Laravel's broadcaster to use Conveyor's Pusher protocol mode.

Evaluate Conveyor as a WebSocket and REST broadcast server for your Laravel deployment.

For custom WebSocket clients that don't go through Laravel Echo, native Conveyor mode is simpler.

Start Conveyor in Pusher mode

server.phppusher/reverb

<?php

use Conveyor\Constants;
use Conveyor\ConveyorServer;

require __DIR__ . '/vendor/autoload.php';

(new ConveyorServer())
    ->host('127.0.0.1')
    ->port(8990)
    ->serverOptions([
        'worker_num' => 1,
        'task_worker_num' => 1,
    ])
    ->conveyorOptions([
        Constants::WEBSOCKET_SUBPROTOCOL => Constants::PUSHER,
        Constants::USE_PRESENCE => true,
        Constants::APPS => [[
            'app_id' => 'local-app',
            'key' => 'local-key',
            'secret' => 'local-secret',
            'enable_client_messages' => true,
            'enabled' => true,
        ]],
    ])
    ->start();

Constants::PUSHERSelects the pusher.com WebSocket subprotocol.

APPSOne or more logical Pusher apps. Each id, key, and secret must match your Laravel broadcasting config.

enable_client_messagesAllows client events (whispers) on presence or private channels. Enable only when needed; payloads are untrusted and cannot establish identity or permissions.

USE_PRESENCEEnables presence channel support. Presence user data is shared with room members; return only minimal public fields from server authorization. See presence privacy and whisper validation.

A runnable example ships with the repository:

shell

php examples/pusher-real/run-conveyor.php

Connection URL

Clients use the standard Pusher path that includes the app key:

text

ws://127.0.0.1:8990/app/local-key

known, enabled appConveyor sends pusher:connection_established with a socket_id.

unknown or disabledConveyor sends pusher:error with code 4001 and closes the socket.

Apps configuration

APPS accepts multiple applications. Each defines app_id, key, secret, enable_client_messages, and enabled. Apps are isolated: connections and channels are scoped per app key.

php

Constants::APPS => [
    [
        'app_id' => 'app-1',
        'key' => 'key-1',
        'secret' => 'secret-1',
        'enable_client_messages' => true,
        'enabled' => true,
    ],
    [
        'app_id' => 'app-2',
        'key' => 'key-2',
        'secret' => 'secret-2',
        'enable_client_messages' => false,
        'enabled' => true,
    ],
],

REST broadcast API

Laravel's reverb and pusher broadcasters publish events with authenticated HTTP POST requests. Conveyor implements the compatible endpoint:

POST/apps/{app_id}/events

It validates the Pusher signature with the app secret, then delivers the payload to every matching WebSocket connection. This is how broadcast(...) and broadcast(...)->toOthers() work when BROADCAST_CONNECTION=reverb (or pusher) points at Conveyor. Full endpoint details: HTTP Requests.

Presence and private channels

Socket Conveyor handlesThe WebSocket transport and the publish REST API.

Laravel handlesPresence and private channel authorization at /broadcasting/auth.

Point Echo's WebSocket host at Conveyor and keep authEndpoint on the Laravel HTTP app. The client-side API and examples are on Presence.

Hooks and filters in Pusher mode

Pusher mode supports FILTER_PUSH_MESSAGE and ACTION_AFTER_PUSH_MESSAGE, plus ACTION_PUSHER_MESSAGE_RECEIVED for incoming WebSocket frames and ACTION_PUSHER_REST_EVENT_RECEIVED before REST event delivery. See Events, hooks & filters for callback arguments and registration examples.

Native presence-message filters, the native HTTP fallback filter, and custom native handlers in Constants::ACTIONS are not used by the Pusher pipeline. Register hook callbacks in your PHP entrypoint before starting your configured server.

Next steps

Laravel Echo / ReverbLaravel, Echo, environment variables, and authorization. AuthorizationHow Laravel Echo authorization works with Conveyor. UsageNative Conveyor mode for direct WebSocket clients.