Reverb Laravel Package

Product Decisions This Supports

• Build vs. buy for real-time: Reverb is the "build" option delivered as a maintained first-party package. The decision becomes infrastructure spend (a supervised PHP process + Redis) instead of per-connection SaaS spend with Pusher or Ably. Model both at projected peak concurrency before committing.
• Feature roadmap unblocking: Live notifications, in-app chat, presence ("who's viewing/typing"), live dashboards, order/shipment status streaming, and collaborative editing cues all become deliverable within the existing Laravel broadcasting model — no new vendor contract, no procurement cycle.
• Low-risk, reversible bet: Reverb speaks the Pusher protocol, so Laravel Echo clients, channel/event names, and broadcast() calls stay the same. Choosing it does not foreclose switching back to Pusher or Ably later — the migration is largely configuration. Frame this as an option, not a lock-in.
• Packaging and pricing: Because marginal cost is server capacity rather than per-seat/per-connection billing, real-time can be included in all tiers instead of gated as a premium add-on — useful for competitive positioning and for reducing sales friction.
• Ops/capacity decision: Redis pub/sub scaling, per-app connection limits, rate limiting, activity timeouts, and origin allowlists exist as knobs. That supports a deliberate decision on single-node vs. horizontally scaled deployment and on how much abuse/backpressure protection is needed at launch.
• Privacy/compliance positioning: Self-hosting keeps message payloads and presence metadata inside your own infrastructure — a concrete answer for customers or reviewers asking where real-time data lives.

When to Consider This Package

Consider it when:

• The product is already on Laravel (Laravel 10/11/12/13 are supported) with broadcasting configured and events already being dispatched.
• You need private/presence channels, client "whisper" events, and toOthers() semantics — all supported, with whisper restricted to channel members.
• Current or projected Pusher/Ably bills are material, or procurement/DPAs are slowing delivery.
• You have (or will fund) someone to run a long-lived process: Supervisor/systemd, a reverse proxy terminating TLS, health checks, log/metric collection, and Redis if you plan more than one node.
• You want the escape hatch of a protocol-compatible vendor swap.

Look elsewhere when:

• The stack is not Laravel/PHP, or you need a language-agnostic real-time service shared by multiple backends.
• You need a hard SLA, global edge presence, or guaranteed delivery — managed vendors carry that burden.
• Clients sit behind restrictive corporate networks needing HTTP fallback/long-polling; Reverb does not provide that transport fallback.
• Scale targets are extreme (very high concurrent connections or fan-out) and you don't want to own capacity planning, load testing, and incident response for the socket tier.
• You need durable/offline message delivery or non-WebSocket protocols (MQTT/IoT).
• You require a vendor support contract with an escalation path.

Caveats worth flagging: the project is young (v1.x, first release 2024) and iterating quickly — recent releases include security-relevant fixes (timing-safe API signature checks, event/whisper authorization hardening), so pin versions and track releases. Ecosystem signals are modest (roughly 1.6k stars), so treat adoption evidence as coming from Laravel's first-party backing and documentation rather than from broad third-party case studies.

How to Pitch It (Stakeholders)

To executives: Laravel Reverb is the official, MIT-licensed WebSocket server for Laravel, maintained by the framework's own team. It lets us ship real-time features — live notifications, chat, presence, live status updates — on our existing stack, replacing per-connection SaaS fees with predictable server cost. It is protocol-compatible with Pusher, so adoption is reversible and does not create a vendor lock-in we can't exit. No new language, no new hiring profile, no new procurement.

To engineering: It slots into Laravel's existing broadcasting and Echo setup; broadcast() events and channel authorization work as-is. Single-node is near-trivial; multi-node uses Redis pub/sub, and the package ships connection limits, rate limiting, activity timeouts, origin allowlisting, and signature verification. What we take on is operational: a supervised long-running process, TLS termination at the proxy, Redis for scale, and monitoring of connection counts and memory. Recent releases have addressed memory leaks and hot-path performance, so pin the version and review the changelog on upgrade.

Headline risk and mitigation: the real cost is operational ownership and the absence of an HTTP fallback transport for locked-down networks. Mitigate with a load test at target concurrency before launch, a documented rollback to Pusher via config, and a monitoring/alerting plan for the socket tier.