Websocket Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for the realtime layer. This package represents the "build/own it" option: a websocket server that ships inside the application stack rather than a managed service. Evaluating it forces the right comparison — Pusher/Ably/Superset vs. self-hosted (Reverb, Soketi, Mercure, Ratchet/Wrench) — on cost per connection, latency SLOs, and ops headcount rather than on feature checklists.
• Feature scoping: is realtime a v1 requirement or a v2 differentiator? The existence of an in-stack server lowers the "time to first websocket" cost, which can tempt teams to pull live notifications, presence, and collaborative editing into the first release. A PM decision, not an engineering one.
• Channel and multiplexing architecture. Multiplexing many topics over a single connection is a product-visible constraint: it determines how many concurrent users a single process supports, whether presence/typing indicators are affordable, and how per-connection pricing maps to unit economics.
• Deployment topology and its operational bill. An in-process server implies long-running workers, exposed ports, sticky sessions, and health checks. That is a roadmap input: it changes the hosting tier, the on-call model, and whether the platform team can absorb the service.
• Configuration surface and change management. "Semantic configuration" means channels and endpoints are declared, reviewable, and diffable — which affects onboarding time for new engineers and the auditability of who enabled which realtime endpoint.
• Adoption risk as a gate. 49 stars and zero dependents is a signal, not a footnote. Treat this repository as a reference design for how realtime is wired into a PHP framework, not as a dependency to schedule.

Caveat that must lead the discussion: this is a Symfony2 bundle, not a Laravel package. It cannot be dropped into a Laravel application. The decisions above are still the right ones to make; the artifact is useful as a pattern to reason against, and as a contrast case for what Laravel's own broadcasting stack now provides out of the box.

When to Consider This Package

Consider it only when all of the following hold:

• You are maintaining a legacy Symfony2 / PHP 5.x application that is not being migrated within the planning horizon, and you need to add websocket capability without a platform rewrite.
• You require self-hosted, in-perimeter messaging — data residency, regulated data, air-gapped environments, or a hard prohibition on third-party SaaS.
• Scale is modest and predictable: a prototype, an internal tool, a single-region deployment with a known concurrency ceiling and no autoscaling requirement.
• Your team already operates long-running PHP processes and is comfortable with the failure modes (memory growth, restarts, connection draining).
• You have accepted that you will vendor and patch it yourself — there is no maintainer to lean on.

Look elsewhere when:

• You are on Laravel. Use Laravel's first-party broadcasting with Reverb (self-hosted, first-party, actively maintained) or a managed driver. Soketi, Mercure, or FrankenPHP/Swoole/RoaRunner are the credible self-hosted alternatives. This bundle is not an option here at all.
• You need horizontal scale or high availability. A single websocket process has no clustering story in this package; you would be building the fan-out layer (Redis pub/sub, broker) yourself, which erases the "in-built server" advantage.
• You need a security patch SLA. Symfony2 is end-of-life, Wrench is effectively unmaintained, and zero dependents means no downstream pressure to fix anything. If your threat model includes timely CVE response, this fails the bar.
• Your team's PHP version is 8.x. Compatibility is not something to assume and not something worth paying to discover.

How to Pitch It (Stakeholders)

To executives — one line: this is not a dependency we should adopt; it is a useful reference point that shows what "owning our realtime infrastructure" actually costs, and it argues for buying or using a first-party managed option instead.

The commercial framing is straightforward. Self-hosting realtime avoids per-connection SaaS spend and keeps message data in our perimeter, which matters for data-residency commitments and for any enterprise deal that requires it. But the price of that saving is a long-running stateful service: capacity planning, connection draining on deploy, sticky-session load balancing, and on-call coverage for a component that fails in user-visible ways. This package makes that trade-off legible — and it also makes the risk legible. It targets Symfony2, a platform that reached end of life years ago; it has 49 stars and no downstream dependents; it has no active maintainer. Committing to it would mean we own the code, the security posture, and the upgrade path indefinitely, with no community backstop. The recommendation is therefore not to adopt this package, and to treat the evaluation as completed diligence that de-risks the real decision: managed service versus a maintained self-hosted option such as Laravel Reverb.

To engineering — the technical read: the design is a single in-process websocket server built on Wrench, with semantic configuration and topic multiplexing across one connection per client. The multiplexing model is the genuinely interesting part: it minimises connection count against the browser's per-origin limits and is the right shape for notification and presence features. The constraints are equally clear — one process, no clustering, no built-in pub/sub fan-out, and PHP 5-era assumptions throughout. If the team wants to borrow the design, multiplexing plus declarative channel configuration is the piece worth copying into whatever we choose. If the team is on Laravel, there is nothing to port: broadcasting, channel authorization, and Reverb cover this surface as first-party, maintained code, and we should spend our effort on channel design and authorization rules rather than on server plumbing.