Reverb Rs Laravel Package

Product Decisions This Supports

• Self-hosting real-time at lower cost. reverb-rs is a Rust reimplementation of Laravel Reverb's WebSocket server, shipped as a ~10 MB statically linked distroless image running as nonroot. This makes the "run our own WebSocket tier instead of paying Pusher/Ably" decision materially cheaper and simpler to operate — smaller nodes, faster cold starts, fewer CVEs to patch in the base image.
• Infrastructure footprint / hosting tier decisions. A 10 MB no-shell container changes the conversation about capacity planning: you can plausibly co-locate the WebSocket tier on smaller instances or scale it horizontally behind a load balancer without a proportional cost increase. Useful input when sizing for peak concurrent connections.
• Build vs. buy (the real decision). Three options now exist: hosted provider (fastest, recurring cost, vendor lock-in on protocol), official Laravel Reverb (first-party, PHP runtime, larger image), or this package (smallest ops surface, community-maintained). A recommendation to prototype on this and keep hosted as the fallback is defensible.
• Rollout/deployment decisions. The php artisan reverb-rs:binary command downloads a binary at deploy time, while the container path delivers the same artifact via a pinned image tag. This directly informs an architecture decision: container image with a digest pin for production, the artisan downloader only for local/dev and single-host setups.
• Not yet a roadmap commitment. At v0.1.1 this is a spike/evaluation candidate, not a platform standard. It should not gate a real-time feature launch without a compatibility and failover plan.

When to Consider This Package

Consider it when:

• You already run Laravel broadcasting + Echo (Pusher protocol) and want to drop the PHP-based Reverb process for a smaller, faster, statically linked alternative.
• Container size, attack surface (no shell, nonroot, distroless), and multi-arch (amd64/arm64) support are explicit operational requirements — e.g. ARM-based cheap compute or edge deployments.
• Your real-time usage is comparatively simple: public/private channels, modest concurrency, single-region, no need for first-party SLAs.
• You have engineering appetite to validate protocol compatibility and to own the fallback path.

Look elsewhere when:

• You need an LTS/support contract, security advisories, or a named vendor — use official Laravel Reverb or a hosted provider.
• You depend on Reverb's advanced surface: horizontal scaling via Redis pub/sub, presence channel semantics at scale, rate limiting, metrics/prometheus endpoints, TLS termination inside the app, webhook hooks. Verify each explicitly before assuming parity — the release notes say nothing about feature parity, only packaging.
• Your deploy environment forbids runtime binary downloads or outbound egress during release (a genuine blocker for reverb-rs:binary in locked-down CI; the container path mitigates this).
• You are pre-1.0-averse: v0.1.x implies unstable interfaces and possible breaking changes between patches.

Due diligence required: single-maintainer namespace (baggins800), pre-1.0 version, and an unexplained jump — the composer package appears new in v0.1.1 while v0.1.0 predates it, so treat the packaging as brand new even if the binary is not. Confirm the Pusher protocol handshake version, message size limits, and reconnect/backoff behaviour under load before committing.

How to Pitch It (Stakeholders)

To executives: There's a small, early-stage open-source server that speaks Laravel's real-time WebSocket protocol but runs as a 10 MB hardened container instead of a full PHP process. It could cut the cost and operational overhead of our real-time tier meaningfully, but it's a v0.1 community project with one maintainer and no support contract. Recommendation: a short, time-boxed spike to validate compatibility and load behaviour, with a hosted provider as the fallback if it doesn't hold up. No production commitment requested yet.

To engineering: composer require baggins800/reverb-rs, then reverb-rs:binary to fetch the binary and reverb-rs:start to run it; alternatively pull ghcr.io/baggins800/reverb-rs:v0.1.1 (multi-arch, distroless, nonroot). Ask: does it match the Pusher protocol version our Echo client uses, and does it cover the channels, presence semantics, and scaling behaviour we actually need? Flag: runtime binary download in the artisan path is an egress/supply-chain consideration — pin the image by digest in production. Version is pre-1.0; assume breaking changes.