- How do I install the Centrifugo broadcast driver in a Laravel app?
- Install it with composer require denis660/laravel-centrifugo, then run the bundled php artisan centrifuge:install command to scaffold the configuration. Set the CENTRIFUGO_* environment variables (API endpoint and secret) and point your default broadcaster in config/broadcasting.php at the centrifugo driver. Restart any queue workers after changing broadcasting config so long-running processes pick up the new driver.
- Which Laravel and PHP versions does denis660/laravel-centrifugo support?
- The v5.3 line targets Laravel 9 through Laravel 13, and the centrifuge:install command was reworked to handle the app skeleton changes introduced across those releases. Laravel 13 support means the package is tracking current framework releases rather than lagging behind. Always confirm the minimum PHP constraint in the package's composer.json before upgrading, since it moves with the supported Laravel versions.
- How do I configure the Centrifugo API endpoint and secret in Laravel?
- Configuration lives in the published config/centrifugo.php file and is driven by environment variables, so you keep credentials out of source control. You define the Centrifugo HTTP API URL and the shared secret, and register the broadcaster under the connections array in config/broadcasting.php. After upgrading to v5.3, re-run the installer and diff the generated config against your existing file instead of overwriting it.
- How does the package authenticate users and generate Centrifugo JWT tokens?
- The package mints JWT connection and subscription tokens using the Centrifugo secret and binds the token identity to the authenticated Laravel user id. In v5.3 a bug was fixed where token generation used the wrong identity, so tokens now correctly reflect the logged-in user. If you previously worked around that behaviour with custom token minting or a forked broadcaster, treat the upgrade as a potential breaking change and validate the auth path in staging first.
- Does it support private channels, presence, and channel subscriptions?
- Yes. It plugs into Laravel's existing broadcast authorization callbacks and ShouldBroadcast contracts, so private and presence channels are authorized through the same Broadcast::channel definitions you already use. On the client, centrifuge-js handles private and websocket subscriptions, and the package's E2E tests exercise a real private-subscribe flow rather than mocks. Presence and subscription state are handled server side by Centrifugo itself.
- How do I catch errors when a Centrifugo HTTP API call fails?
- The v5.3 release normalizes transport failures into Laravel's native BroadcastException instead of letting raw Guzzle or HTTP exceptions bubble out. Any code that previously caught Guzzle exceptions from the client must be updated to catch BroadcastException, otherwise failures will surface as unhandled errors. This also means failures that were silently swallowed before may now propagate, which is usually what you want in production monitoring.
- Can I publish messages to Centrifugo directly without firing a broadcast event?
- Yes, the package exposes a CentrifugoInterface container binding with publish helpers you can inject into services, jobs, or controllers. That lets you push arbitrary payloads to a channel without defining a ShouldBroadcast event, which is handy for system notifications or one-off messages. Because the binding was fixed in v5.3, remove any custom bind() override or workaround service provider you added to compensate for the previous behaviour.
- How do I test a Centrifugo integration in a Laravel test suite?
- For unit and feature tests, fake the event layer or swap the CentrifugoInterface binding with a mock so you assert payloads without hitting a live server. The package itself ships Docker-based integration checks, including a fresh-install end-to-end test for Laravel apps and a private-subscribe test using centrifuge-js. Use those as a reference for validating the client/server contract when you build your own smoke tests.
- Is upgrading from v5.2 to v5.3 of this package a breaking change?
- The release is labelled a bug-fix release but carries real upgrade risk, because it changes behaviour rather than just adding features. The three items to check are the auth token identity fix, the container binding fix, and transport errors now being normalized to BroadcastException. Pin the current version, grep your codebase for local workarounds around CentrifugoInterface, token generation, or raw transport exceptions, and upgrade in a non-production environment before rolling out.
- Is this package a good alternative to Pusher or Redis broadcasting in Laravel?
- It is not a replacement for Pusher or Redis broadcasting so much as a driver for teams that already run, or plan to run, a Centrifugo server. The natural fit is high-fanout or high-concurrency realtime workloads where Centrifugo's scaling model helps, and you still keep Laravel's standard broadcast() and ShouldBroadcast abstractions. If your app is small or already happy on Pusher, there is little reason to migrate.