Laravel Centrifugo Broadcaster Laravel Package

Technical Evaluation

Package: opekunov/laravel-centrifugo-broadcaster v3.0.2 — a Laravel broadcast driver that publishes ShouldBroadcast events to a self-hosted Centrifugo real-time messaging server.

Architecture fit. The package integrates at Laravel's BroadcastManager extension point, which is the correct and lowest-friction seam: it does not patch the framework, does not require a service provider override beyond driver registration, and leaves event classes, channel authorization, and queue semantics in native Laravel hands. For teams already using the broadcasting abstraction, Centrifugo becomes a swappable transport rather than a new programming model. The trade-off is that Centrifugo is out-of-process infrastructure (typically Go binary + Redis/NATS engine), so the package is a thin HTTP client in front of a stateful system — architecture risk lives in the server, not the library.

Integration feasibility. High on the PHP side: composer require, a centrifugo connection block in config/broadcasting.php, and env-provided API credentials. Supported matrix is laravel/framework ^8.75 – ^13.0 on PHP 8.0 – 8.4, which covers essentially every maintained and near-EOL Laravel line. The v3.0.2 release strengthens feasibility in two concrete ways: (1) Laravel 13 is CI-verified on PHP 8.3/8.4 rather than merely declared in composer.json, which is the difference between a constraint and a guarantee; (2) the timeout/retry tests no longer depend on the external httpstat.us service, removing a third-party availability dependency from the verification story. The honest gap is client-side: Laravel Echo has no first-party Centrifugo connector, so front-end integration is centrifuge-js (or a community connector) and is a separate workstream from the PHP install.

Technical risk. Moderate-low, with three named risks. Maintainer concentration — a single-maintainer package in the real-time critical path; mitigated by a small, auditable surface area (a driver plus a publisher), but it should be treated as a vendored dependency with a fork-ready posture. Server-version coupling — Centrifugo's auth model has changed across majors (API key vs. token/HMAC-based publish auth), and the release notes are silent on which Centrifugo server versions are validated; a Laravel 13 upgrade is meaningless if the pinned Centrifugo server is two majors behind. Coverage claims — "100% code coverage" plus Pint/PHPStan is a positive hygiene signal, but coverage percentage says nothing about assertion quality, and PHPStan level is unspecified (level 5 vs. max is a large difference in confidence).

Key questions.

1. Which Centrifugo server versions (v4/v5/v6) are exercised in CI, and is publish auth tested against each server's token/API-key scheme?
2. What PHPStan level is enforced, and is it enforced as a blocking CI gate or advisory?
3. Does the driver honor broadcastAs, broadcastWith, broadcastWhen, dontBroadcastToCurrentUser / toOthers(), and per-event channel overrides?
4. Is publishing batched, or one HTTP request per event? Does it support connection pooling / keep-alive to Centrifugo?
5. Is the package Octane-safe (no request-scoped state held in singletons)?
6. What is the documented behavior when Centrifugo returns 5xx or times out — throw, log-and-drop, or retry? Does it interact correctly with Laravel's queue $tries/$backoff?
7. Is Laravel 13 GA at the time of adoption, and does the ^13.0 constraint resolve to a stable tag?
8. Are private/presence channel authorization callbacks documented, or does the team own that contract end-to-end?

Integration Approach

Stack fit. Strong for Laravel shops that have outgrown Pusher/Ably on cost or data-residency grounds and are willing to operate a messaging server. Weak fit for teams with no appetite for stateful infrastructure — in that case the managed-broadcaster path remains cheaper than the engineering time Centrifugo consumes. The package is a good citizen of the framework: it uses the standard driver contract, which means php artisan event:list, broadcast:, and channel authorization all continue to work unchanged.

Migration path. From Pusher/Ably: event classes are untouched; the change is the BROADCAST_DRIVER value, the connection block, credentials, and the front-end client swap from pusher-js to centrifuge-js. Budget front-end effort as the dominant cost, not the backend swap. From laravel-websockets: similar shape, but private-channel auth endpoints and presence semantics must be re-verified because Centrifugo's subscription-token model differs from the Pusher protocol. From Redis broadcasting (no external client): this is a genuine architecture change, not a swap — plan it as a project.

Compatibility. Pin to ^3.0 and let the widened framework constraint float; the package's own floor of Laravel 8.75 / PHP 8.0 does not force an upgrade, so the constraint should be driven by the application's support policy, not the driver's. Verify Centrifugo server version against the package's tested matrix before pinning — the Laravel side is the easy half of the compatibility question. Confirm orchestra/testbench ^11.0 and phpunit ^12 do not leak into production autoload (they should be require-dev; validate with composer why).

Sequencing.

1. Spike (1 sprint): stand up Centrifugo in staging with the target engine (Redis), publish one public and one private channel end-to-end, confirm token auth and presence.
2. Pin and audit: lock ^3.0, run composer audit, record the resolved Centrifugo server version and PHPStan level in the dependency register.
3. Dual-run: keep the existing broadcaster live behind a config flag; run Centrifugo in shadow mode on a subset of non-critical channels to compare delivery behavior.
4. Queue hardening: ensure broadcasting events implement ShouldBroadcast and run on a dedicated queue with explicit $tries, $backoff, and failed() handling — the driver cannot compensate for a misconfigured worker.
5. Client cutover: ship centrifuge-js integration channel-by-channel, not as a big bang.
6. Decommission: remove old driver config and credentials only after a full release cycle of clean delivery metrics.

Operational Impact

Maintenance. Low code-churn, moderate ownership burden. The package is a thin adapter, so the maintenance surface is small — but it is single-maintainer, so the team must own a contingency: vendor the package or maintain a fork branch, and subscribe to releases. v3.0.2's addition of Pint + PHPStan and deterministic tests materially lowers the cost of reviewing future upgrades, because the project now has a quality baseline to regress against. Track the Laravel major cadence explicitly: this release proves the maintainer ships framework support early (Laravel 13 landed in a patch release), which is the single best predictor of a healthy dependency.

Support. No commercial SLA. Support is GitHub issues plus reading the source, which is tractable at this size but must be staffed. Two artifacts are non-negotiable and are not supplied by the package: an internal runbook for Centrifugo operations (upgrades, engine failover, token rotation) and a documented channel-authorization contract between Laravel and Centrifugo. Assign a named owner for both.

Scaling. Centrifugo scales horizontally by design via its Redis/NATS engine, so the server tier is the well-trodden part. The scaling pressure point introduced by this package is on the Laravel side: each broadcast is an outbound HTTP call to the Centrifugo API, so throughput is bounded by HTTP round-trip latency and connection reuse. At high event volume this makes queued broadcasting mandatory and makes the broadcast queue a first-class capacity concern — size workers, monitor queue depth, and confirm keep-alive/pooling behavior. Fan-out cost is Centrifugo's problem, not the driver's, which is the right division.

Failure modes. Enumerate and monitor each: (a) Centrifugo unreachable or slow → broadcast timeout; without queue-level $tries/$backoff these become silent event loss; (b) credential/token mismatch after a Centrifugo major upgrade → publishes rejected with 401/403, often discovered only by users noticing missing real-time updates; (c) queue worker starvation → events enqueued but never published, invisible unless queue depth is alerted on; (d) channel-name or namespace drift between publish and subscribe paths → messages published to a channel nobody is listening on, which fails silently by design; (e) private-channel auth endpoint regression → subscription rejected client-side. Each needs an alert or a synthetic canary that publishes and asserts receipt. The removal of the httpstat.us dependency is a genuine operational win — it eliminates one class of CI-only false negatives that would otherwise erode trust in the test suite.

Ramp-up. Backend ramp-up is roughly a day for a Laravel-fluent engineer: one config block, one client library, one auth contract. Front-end ramp-up is the real cost — centrifuge-js is a different API from pusher-js, with different subscription lifecycle, presence, and reconnection semantics; budget 3–5 days for the first team and capture the result as an internal reference implementation. Centrifugo server operations (deployment, engine configuration, graceful upgrade) is a separate skill from either and should be assigned to whoever owns infrastructure, not to the application team by default. Net: low framework risk, moderate platform risk, front-end effort routinely underestimated.