- How do I install pusher/pusher-php-server with Composer?
- Run composer require pusher/pusher-php-server, or pin something like ^7.3 in your composer.json require block and run composer update. Laravel 8.29 and above already pulls the package in transitively via the framework's Pusher broadcasting driver, so a fresh install often needs no extra step. Then set PUSHER_APP_ID, PUSHER_APP_KEY, PUSHER_APP_SECRET, and PUSHER_APP_CLUSTER in your environment file.
- Which Laravel and PHP versions does pusher/pusher-php-server support?
- The library supports PHP 7.3 through 8.4 and works with any framework running those versions. Laravel 8.29 and above ships a first-class Pusher Channels broadcasting driver, so no custom package service provider is needed there. For non-Laravel projects you simply instantiate the Pusher class directly with your app key, secret, app id, and cluster.
- Do I need a service provider to use pusher/pusher-php-server in Laravel?
- No. Laravel's BroadcastManager resolves the Pusher driver for you, so the only setup is config/broadcasting.php plus environment variables. If you also call the SDK outside of broadcasting, register a singleton binding in a service provider so the Pusher client is injected instead of instantiated ad hoc. That keeps credentials, host, and timeout options in one place.
- How do I trigger a Pusher event from a Laravel controller or job?
- Create a Pusher instance with your key, secret, app id, and cluster option, then call trigger with a channel name, event name, and payload array. In Laravel the cleaner path is a broadcast event implementing ShouldBroadcast, which hands the work to the broadcasting driver. Always dispatch from a queued job or listener, because trigger performs a blocking HTTP request.
- Why did my Laravel requests get slow after adding Pusher broadcasting?
- Because trigger is a synchronous HTTP call to the Pusher REST API, so user-facing latency now includes a third-party round trip. Move broadcasts onto queued events or a dedicated job so the request path stays fast. The library itself has no retry, backoff, or circuit breaker, so add Guzzle middleware or queue-level retries for resilience.
- Does pusher/pusher-php-server support end-to-end encrypted channels?
- Yes, it implements end-to-end encryption for private-encrypted channels, configured with a 32-byte base64 master key in the options array. A single trigger call cannot mix encrypted and unencrypted channels, so channel naming becomes a deliberate design decision. Losing the master key permanently destroys the ability to decrypt historical ciphertext, so store it in a KMS or secrets manager with a named owner for rotation.
- How do I authenticate private and presence channels with pusher/pusher-php-server?
- Call authorizeChannel with the socket id and channel name for private channels, and authorizePresenceChannel with user data for presence channels; both return the auth signature your frontend expects. In Laravel these are usually handled by the channel authorization routes defined in routes/channels.php, so you rarely call them by hand. Use authenticateUser when you need Pusher's user authentication flow for server-side identity verification.
- What are the payload, batch, and rate limits of the Pusher REST API?
- Expect roughly 10KB per event payload, a maximum of 10 events per triggerBatch call, and a per-call cap on channels. REST rate limits depend on your Pusher plan, so enforce budgets inside your own publish layer instead of discovering them in production. Pair those guards with retry middleware so a 429 response does not silently drop events.
- Can I use pusher/pusher-php-server with self-hosted Reverb or soketi?
- Yes. Laravel Reverb and soketi speak the same Pusher protocol, so the SDK works unchanged once the host, port, scheme, and useTLS options point at your own server instead of the hosted endpoint. That is why this package behaves like a replaceable infrastructure port: the coupling sits in credentials and channel naming, not in the wire format. Adopting Reverb or soketi from day one avoids a migration later if you need on-prem or data residency options.
- How do I test code that uses pusher/pusher-php-server?
- Wrap the client behind your own broadcaster interface, mock or fake that interface in unit tests, and assert the expected channel, event, and payload were passed through. In Laravel you can fake broadcasting entirely so no HTTP request leaves the test suite. Because the package is a thin HTTP adapter, a single sandbox integration test covering credentials and channel conventions is usually enough.