Reverb Laravel Package

Technical Evaluation

Architecture fit. Reverb is a first-party, MIT-licensed WebSocket server that speaks the Pusher wire protocol and is consumed through Laravel's existing broadcasting abstraction. For any application already on Laravel's broadcasting system with Echo on the client, it is a configuration-level substitution rather than an architectural change: the broadcaster driver, channel authorization, and client library (pusher-js) all remain the same. The material architectural difference is that Reverb runs as a long-lived, stateful process outside the request lifecycle (php artisan reverb:start). That introduces a new deployable unit with its own port, its own process supervisor, its own TLS/upgrade-handling reverse proxy, and its own scaling topology. Teams whose operational model is strictly "PHP-FPM behind Nginx, deploy = replace code" are adding a genuinely new class of workload, not just a package.

Integration feasibility. High. Installation is scaffolded (reverb:install) and configuration is environment-driven (REVERB_APP_ID/KEY/SECRET, host/port, allowed origins, REVERB_SCALING_ENABLED). Private and presence channel authorization reuses Laravel's broadcasting auth routes, so existing authorization logic carries over. Frontend change is limited to the Echo connection block. Because the protocol is Pusher-compatible, there is a credible rollback path back to a managed provider, which materially de-risks the decision.

Technical risk.

• Stateful PHP is the dominant risk. The changelog shows a memory-leak fix (v1.7.0) and repeated hot-path performance work (v1.10.1 dropped an O(N²) merge), which is reassuring evidence of active investment but also confirms that long-uptime memory behavior is a live concern requiring monitoring and periodic recycling.
• Horizontal correctness is recent. Cross-node toOthers via socket-id propagation only landed in v1.11.0, and rate limiting (v1.9.0) and per-app connection limits (v1.6.0) are also recent. These are exactly the controls a production rollout depends on, so pinning to a current 1.11.x is non-negotiable.
• Redis becomes a hard dependency and failure domain once scaling is enabled.
• Delivery semantics are at-most-once. No persistence or replay; the application must reconcile missed state over HTTP on reconnect. This is a product requirement to design for, not a bug.
• Proxy/TLS misconfiguration silently degrades or blocks upgrades; allowed-origin and custom-path handling have both needed fixes (v1.8.1, v1.10.0, v1.10.2).
• The aggregate score (40.3, opportunity 56.4) and the "0 dependents" signal should be discounted: dependents is a library-ecosystem metric and does not describe server-runtime packages. Package quality here is not reflected by that score.

Key questions for the team.

1. What is peak concurrent connection count today, and projected in 12 months?
2. Do we already run Redis in production, and is it HA?
3. Who owns a new 24/7 stateful service — is there an existing supervisor/proxy pattern we can reuse?
4. Does any feature depend on guaranteed message delivery or offline replay?
5. What is the acceptable connection-drop window during a deploy?
6. Are client-initiated ("whisper") events required, and on which channel types?
7. What is our fallback if Redis or the Reverb node fails — degraded real-time, or hard outage?

Integration Approach

Stack fit. Requires a Laravel application on a version supported by the installed Reverb release (Laravel 12 and 13 are both covered per changelog; PHP 8.4/8.5 are in the test matrix). Production topology: reverse proxy terminating TLS and forwarding WebSocket upgrades → one or more reverb:start processes under Supervisor/systemd → Redis pub/sub when more than one node. Client: Echo + pusher-js. Reverb is independent of Octane; it does not require or conflict with it.

Migration path. Treat it as a phased provider swap, not a rewrite.

1. Replace managed-provider credentials with Reverb app credentials in non-production; keep pusher-js unchanged.
2. Validate private/presence authorization against the existing broadcasting auth routes.
3. Run both configurations across environments in parallel (managed in prod, Reverb in staging) so rollback is a one-variable change.
4. Canary in production by tenant or by feature surface, not by dual-publishing the same event — dual-publish doubles fan-out cost and creates duplicate-delivery bugs in the client.

Compatibility. Confirm: application Laravel/PHP version against the pinned Reverb minor; whether a path-prefixed server URL is needed behind the proxy (supported since v1.4.7); allowed-origins configuration for every first-party and partner origin, including wildcard subdomains if used; and whether any consuming client is a non-pusher-js SDK whose protocol assumptions we have not tested.

Sequencing.

1. Pin the Reverb version and record the compatibility matrix.
2. Provision staging: Redis, process supervision, proxy with upgrade headers and TLS, health/restart policy.
3. Install and configure; verify a private channel end-to-end.
4. Verify presence join/leave and member-count correctness (historically the most bug-prone area).
5. Verify client events/whisper if in scope.
6. Load test at 2× projected peak: connections, fan-out to large channels, presence churn.
7. Wire observability against the dispatched events (connection pruned, channel created/removed) plus process memory/RSS and connection gauges.
8. Production canary, then cut over, then decommission the managed provider only after a full rollback window has elapsed.

Operational Impact

Maintenance. Actively maintained first-party package with a frequent minor cadence, Dependabot automation, and a published security policy — low ongoing engineering cost, but non-zero release-tracking cost. Upgrades require process restarts, which means every upgrade is a visible client-reconnect event; treat upgrades as scheduled changes with a maintenance note, and use the reload command rather than a hard kill where possible. Because minors ship frequently, pin and upgrade deliberately rather than floating.

Support. MIT with community plus Laravel-maintainer involvement; there is no commercial SLA attached to the package itself. Escalation is GitHub issues. If real-time is revenue-critical, that gap must be explicitly accepted by the business or backstopped by commercial Laravel support.

Scaling. Start vertical: the event loop is effectively single-core, so a single node's ceiling is bounded by one CPU and by per-connection memory — measure RSS per connection rather than assuming published benchmarks. Horizontal scale is Redis pub/sub, which removes the need for sticky sessions but makes Redis a single point of failure for cross-node delivery and presence coherence. Capacity plan on: connections × memory, messages/sec × fan-out, and presence channel size. Enable the per-app connection limit and rate limiting as guardrails before launch, not after the first incident.

Failure modes to instrument. Process crash → supervisor restart → mass reconnect thundering herd (verify client backoff and jitter); Redis outage → cross-node delivery and presence break while single-node traffic may still work; deploy/restart → connection drop, requiring client-side state reconciliation over HTTP; slow memory growth over multi-day uptime → planned recycling; proxy stripping Upgrade → silent degradation or 400s with no application-level error; origin/signature mismatch → connection refused with a confusing client-side message; abusive clients → mitigated only if rate limiting and payload validation are configured. Note the absence of any replay/persistence layer as a designed limitation: the product must tolerate lost in-flight messages and recover state on reconnect.

Ramp-up. Expect roughly one to two weeks for a mid-level Laravel team to reach production confidence, dominated by the ops work (supervisor, proxy upgrade handling, Redis scaling, observability) rather than the application integration. Add explicit load-testing time before committing to a peak-connection SLO. The primary skill gap to close is operating stateful PHP processes with graceful restarts — that is the capability that determines whether this succeeds, more than any property of the package.