Weave Code
Laravel Broadcaster Laravel Package
ably/laravel-broadcaster
Official Ably broadcaster for Laravel. Send broadcast events over Ably’s realtime messaging platform with support for public, private, and presence channels, token authentication, and seamless integration with Laravel’s broadcasting system.
Official Laravel Ably Broadcaster
Frequently asked questions about Laravel Broadcaster
- What Laravel versions does ably/laravel-broadcaster support?
- The package registers as a broadcast driver inside Laravel's built-in broadcasting system, and release v1.0.8 adds explicit Laravel 13 support. Laravel 10, 11, and 12 applications can generally use the same package version, but you should confirm the exact constraints in the package's composer.json before upgrading. Because v1.0.8 is an additive minor release, upgrading from v1.0.7 involves no breaking changes.
- How do I install and configure the Ably broadcaster in Laravel?
- Install it with Composer, then add an Ably connection entry in config/broadcasting.php and set your Ably credentials through environment variables. Set the broadcast driver to ably so Laravel routes broadcast events through the Ably PHP SDK instead of Pusher or Redis. No custom WebSocket server or additional infrastructure is required beyond an Ably account.
- Does the package support private and presence channels?
- Yes. The broadcaster supports public, private, and presence channels, matching the channel types Laravel's broadcasting abstraction exposes. Private and presence channels rely on Ably's channel authorization rather than Laravel's default Pusher-style auth endpoint, so plan your token authentication accordingly. Verify your specific channel naming and authorization callbacks with an integration test before shipping.
- How does token authentication work with Ably in Laravel?
- Ably authorizes clients with short-lived tokens rather than a static key, so your Laravel app issues token requests to authenticated users. The package integrates with Laravel's broadcasting authorization flow, but your client-side code must request tokens from your application instead of connecting with an API key. Keep your Ably API key server-side only, and scope tokens to the capabilities each user actually needs.
- Can I migrate from the Pusher or Redis broadcaster to Ably?
- Migration means swapping the broadcast driver, updating your config/broadcasting.php connection, and replacing the client-side library with Ably's JavaScript SDK. The biggest conceptual change is channel authorization: Ably uses token-based auth rather than Pusher's signature endpoint. Server-side event and broadcast code usually stays largely the same because the package plugs into Laravel's existing broadcasting API.
- Is upgrading to v1.0.8 a breaking change?
- No. v1.0.8 is a minor release that adds Laravel 13 support without altering existing behavior, so upgrades from v1.0.7 should require no code changes. If you are also moving to Laravel 13, upgrade the framework first and then update this package. Run broadcasting smoke tests afterward, since Laravel 13 compatibility is new and edge cases may not yet be widely reported.
- Which client-side SDK should I use with the Ably Laravel broadcaster?
- Use Ably's JavaScript SDK on the client, following the version documented by the package and Ably. The broadcaster only handles server-side publishing, so subscribing clients connect to Ably directly rather than to your Laravel server. Make sure your client requests tokens from your Laravel app so private and presence channel access is authorized correctly.
- How do I test broadcasting with the Ably driver in Laravel?
- Laravel's broadcasting fakes and event assertions let you verify that broadcast events are dispatched without hitting Ably at all. For end-to-end confidence, add a small integration test that publishes to a test Ably channel and confirms delivery, plus a check that token authorization succeeds for private and presence channels. Keeping real-network tests out of your main suite avoids flakiness and rate-limit issues.
- What production risks come with using Ably as my broadcast backend?
- The main risks are vendor dependency: Ably's service availability, pricing changes, and API evolution all sit outside the package's control. The package itself is a thin adapter, so its technical risk is largely inherited from Ably and from Laravel's broadcasting layer. Mitigate by monitoring delivery failures, keeping your client SDK current, and abstracting broadcast logic behind Laravel events so a future driver swap stays contained.
- How actively is ably/laravel-broadcaster maintained, and what are the alternatives?
- It is an official Ably package with a small surface area, and releases are infrequent, typically tracking new Laravel major versions and Ably SDK bumps. That low churn is normal for an adapter, but it means you should watch the repository for Laravel compatibility updates before adopting a new framework major. Alternatives include Laravel's built-in Pusher and Redis drivers, self-hosted Soketi, or Reverb, depending on whether you need Ably's global edge network and presence features.
Weaver
How can I help you explore Laravel packages today?