Product Decisions This Supports
- Real-time feature scoping — this package is the self-hosted, Pusher-protocol WebSocket server option for Laravel. It informs decisions on whether live notifications, presence channels, chat, collaborative editing, or broadcast-driven UI are viable without a third-party SaaS dependency.
- Build vs. buy vs. self-host — the three-way tradeoff between building a WebSocket tier in-house, paying Pusher/Ably, or self-hosting an open-source server with its own ops burden (supervisor process, port/TLS config, horizontal scaling and Redis pub/sub for multi-node, monitoring).
- Framework upgrade roadmap (now the dominant constraint) — v2.0.0 pins the package to Laravel 10. This is a roadmap-level dependency: any decision to standardize on Laravel 11/12 makes this package unavailable. The PM decision is not "should we use it" but "how and when do we exit it."
- Use-case fit — best suited to internal tools, admin dashboards, and prototype/MVP broadcast features where the team already runs Laravel and self-manages infrastructure. Poor fit for customer-facing SLAs, regulated environments, or high-concurrency real-time products.
- Cost modeling — self-hosting trades SaaS subscription cost for infrastructure plus engineering ownership. Because the package is archived, that ownership cost now includes permanent maintenance (forking, patching) rather than just operations.
When to Consider This Package
Consider it only when all of the following hold:
- The application is on Laravel 10 (v2.0.0 hard-constrains this; there is no supported path to 11+).
- A Pusher-compatible protocol is required by existing frontend code (Laravel Echo / pusher-js), so swapping to a different wire protocol is expensive.
- The feature is internal or low-criticality — no uptime SLA, no regulated data, tolerance for an unmaintained dependency.
- The team is willing to accept ownership of a frozen dependency: security patching, PHP version bumps, and framework compatibility are now yours, not the maintainer's.
Look elsewhere if any of these are true — which is the common case:
- You are planning, or already on, Laravel 11 or later. Use Laravel Reverb (the first-party successor) instead; it is the intended migration target and the reason the ecosystem moved on.
- You need vendor support, CVE response, or a documented security posture — this package is archived and receives no upstream fixes.
- Your product needs elastic scaling, guaranteed delivery, or multi-region real-time — a managed service (Pusher, Ably, Supabase Realtime) is the lower-risk buy.
- You want self-hosting but not a dead dependency — Soketi is an actively maintained Pusher-compatible server.
- The real-time requirement is genuinely optional; polling or SSE may remove the dependency entirely.
How to Pitch It (Stakeholders)
To executives: This is a free, open-source WebSocket server for Laravel that would let us add live-updating features (notifications, dashboards, chat) without a monthly SaaS bill. The tradeoff has just changed against us: the package is archived and its newest release, v2.0.0, explicitly locks us to Laravel 10. Adopting it means either freezing our framework version or committing to an indefinite maintenance burden with no security patches. My recommendation is do not adopt for new work; if we already use it, treat it as technical debt with a funded migration to Laravel Reverb or a managed service tied to our Laravel 11+ upgrade.
To engineering: v2.0.0 is a compatibility-only release that constrains illuminate/* to ^10.0 so the archived package remains installable on Laravel 10 — it is not a feature release, and it is effectively the project's final state. Concretely: no Laravel 11/12 support, no upstream security response, and no PHP-version guarantee going forward. Treat it as frozen. If it is in the codebase today, budget a migration spike to Laravel Reverb (same Pusher protocol, so Echo client changes should be minimal — mostly config and connection credentials), or to a managed provider if we'd rather buy than operate. Do not let new features take a dependency on its APIs.
To the product team: this does not block current real-time features, but it constrains what we can promise next. Any roadmap item that assumes Laravel 11+, or that assumes live features will keep receiving fixes, should be re-scoped now rather than at upgrade time.