Centrifugo Bundle Laravel Package

Technical Evaluation

Naming discrepancy is the first finding. fre5h/CentrifugoBundle is a Symfony bundle, not a Laravel package. It ships a Symfony DI extension, service definitions, and bundle registration via config/bundles.php. Laravel has no bundle loader, so the package cannot be installed and used as documented inside a Laravel application. Any assessment of "leveraging this in a Laravel stack" must separate two assets: the Centrifugo server (the valuable, stable part) from this PHP glue (the incidental part).

Architecture fit. The bundle is a thin wrapper over Centrifugo's HTTP server API — a Symfony service that lets application code publish to channels, query presence/history, and disconnect users. The real-time transport is a standalone Go server that holds the WebSocket connections; PHP only fires commands at it. That architecture is framework-agnostic in principle. Symfony's container is doing roughly 100–200 lines of work: config tree, service alias, singleton instantiation. That is exactly the part that is not portable.

Integration feasibility. Low as-is, high after a small rewrite. The realistic paths are: (a) drop the bundle and use the underlying PHP HTTP client directly with a ~50-line Laravel service provider plus a config file; (b) use a Laravel-native Centrifugo client if one is maintained; (c) fork the bundle and replace the DI extension with a service provider (MIT license permits it). Option (a) is cheapest and removes the dependency question entirely. A TPM should budget this as a one-to-two-day glue task, not a package evaluation.

Technical risk.

• Zero dependents is the loudest signal. Nobody else is running this in production against the versions you will run. You will be the first integration test for edge cases.
• Bus factor of 1, no commercial backing, no support contract. Mitigated almost entirely by the thinness of the code and MIT licensing — a fork is a half-day, not a quarter.
• Framework coupling: the bundle must track Symfony major versions, which is irrelevant to a Laravel consumer but tells you where the maintainer's attention goes.
• API drift: Centrifugo's HTTP API has evolved across v4/v5/v6. An abandoned wrapper pinned to an older surface is the classic failure here.
• The Centrifugo server itself is not the risk — it is mature, permissively licensed, and widely deployed. Risk concentrates in the glue and in your operational design.

Key questions to put to the maintainer or resolve by reading the code. Which Centrifugo major versions are supported and tested? Does it vendor its own HTTP client or depend on a maintained one? Does it cover JWT connection auth (HMAC and RSA), token expiry/refresh, and namespace-level claims, or only publish? Is bulk publish batched or one HTTP round-trip per message? What is the test coverage, and is there a CI matrix against current Symfony/PHP?

Integration Approach

Stack fit. Runtime compatibility is a non-issue: PHP 8.1+ and Guzzle/PSR-18 are already present in any modern Laravel app, and JWT signing is available via firebase/php-jwt (often already a transitive dependency). The incompatibility is lifecycle, not language. Laravel's service provider, config repository, and facade system replace the Symfony equivalents one-for-one — this is mechanical porting, not redesign.

Migration path. Define a narrow internal interface (RealtimePublisher with publish, broadcast, presence, history) and bind it to a concrete Centrifugo client in a service provider. That interface is the actual asset. It lets you start with the official client, swap to a forked bundle later if it proves useful, and stub the whole thing in tests. Do not let Centrifugo's DTOs leak into domain code.

Compatibility. Connection authentication is JWT-based: Laravel issues a short-lived token carrying the user identity and permitted channels, Centrifugo validates it with a shared secret or public key. This is the one piece worth writing carefully — expiry windows, channel-prefix claims, and clock skew are where production incidents originate. Publishing from PHP is stateless HTTP, so it works identically from web requests, queue workers, and scheduled jobs.

Sequencing.

1. Stand up Centrifugo and decide the engine (Redis or NATS) before writing application code — presence and history are engine-dependent, and retrofitting multi-node later is disruptive.
2. Ship the JWT issuance endpoint and connection auth, tested against a real server.
3. Add the service provider and server-side publish path, wrapped with timeouts and failure isolation.
4. Integrate the browser/mobile client and channel subscriptions.
5. Layer presence and history only where the UX genuinely needs them — both carry real operational cost.

Operational Impact

Maintenance. The glue is low-maintenance but effectively self-supported. Assume you own it. Pin the Centrifugo server version explicitly, keep the PHP client behind your interface, and schedule a quarterly check that the HTTP API surface you use has not shifted. The fork-and-own posture is realistic here precisely because the code volume is small.

Support. No vendor SLA. Centrifugo's documentation and community are the real support channel, and they are good. Escalation for PHP-side defects lands on your team.

Scaling. Centrifugo scales horizontally with a shared engine; the PHP side scales trivially because publish is stateless HTTP. The bottleneck to watch is publish volume: one HTTP round-trip per message becomes visible at high fan-out rates. Batch publishes, move high-volume publishing into queued jobs, or write directly to the engine's pub/sub from PHP if you exceed a few hundred publishes per second.

Failure modes.

• Centrifugo unreachable → publish calls block PHP-FPM workers. Set aggressive connect/read timeouts and decide per call site whether failure is fatal or silent; for notifications it should be silent and logged.
• Token expiry mid-session → forced reconnect and dropped subscriptions unless the client refreshes proactively.
• Engine loss → presence and history degrade while live messaging continues. Design the UI to tolerate empty presence.
• Fire-and-forget publish that nobody confirms → messages silently lost. Publish should return and be checked, or be queued with retry.

Ramp-up. Team cost is dominated by Centrifugo's conceptual model — channels, namespaces, JWT claims, presence semantics — not by the PHP package. Budget one to two days of learning and roughly one sprint to a production MVP including auth, publish, and client integration. A TPM should frame the decision as "adopt Centrifugo as the real-time backbone," with the PHP wrapper treated as disposable plumbing rather than a dependency to be vetted. On that framing, the 84 stars and zero dependents stop mattering.