Reverb Rs Laravel Package

Technical Evaluation

Architecture fit

• baggins800/reverb-rs is a third-party Rust reimplementation of Laravel Reverb, the first-party WebSocket server that speaks the Pusher protocol. It is intended as a drop-in substitute at the network boundary: Laravel broadcasting + Laravel Echo keep talking Pusher-protocol, only the server process changes.
• The distribution model is explicitly two-channel: a ~10 MB statically linked distroless/static container image (linux/amd64, linux/arm64, runs as nonroot) and a Composer package that shells out via php artisan reverb-rs:binary to fetch the binary, then reverb-rs:start to launch it.
• This is an infrastructure swap, not an application-code change. Architectural fit is therefore high in principle (same protocol contract, dramatically smaller runtime footprint than a PHP/Reverb process), but it is unproven against our specific channel semantics.

Integration feasibility

• Low-friction to trial: composer require baggins800/reverb-rs plus two artisan commands gets a running server; existing config/reverb.php-style app credentials and Echo client config likely carry over unchanged.
• Two viable deployment shapes: (a) Composer package inside the app image, downloading the binary at build time; (b) the GHCR sidecar/standalone container, which is the cleaner production path given distroless + multi-arch.
• The reverb-rs:binary download step introduces an outbound network dependency at build/deploy time — must be mirrored or cached internally, not executed at container start.

Technical risk

• Maturity: high. v0.1.1 is the second patch of a pre-1.0 package. The changelog shows only packaging and distribution changes (image publication, artisan commands) — no functional changelog, no protocol-parity statement, no test/benchmark evidence. There is no signal yet on feature completeness.
• Protocol parity: unknown and material. Presence channels, private channels, client events, channel auth callbacks, pusher: webhooks, connection recovery, and activity timeouts are all places a reimplementation typically diverges. No claim of parity is made in the notes.
• Horizontal scaling: unverified. Reverb's scaling story depends on Redis pub/sub for cross-node fan-out; nothing here indicates reverb-rs implements it. This gates any multi-replica deployment.
• Supply chain: elevated. Fetching a prebuilt binary from GitHub Releases via an artisan command, for a project under a single personal GitHub account, is a meaningful trust and continuity exposure. Checksum/signature verification is not mentioned.
• Bus factor / governance. Single-maintainer OSS reimplementation of a first-party component. No stated support, SLA, or security disclosure process.

Key questions

1. Which Pusher protocol features are implemented, and what is the parity test suite against laravel/reverb?
2. Is Redis-backed horizontal scaling supported, and is the config schema compatible with config/reverb.php?
3. Does the binary download verify a published checksum/signature? Can it be pointed at an internal mirror and skip network entirely?
4. What are the TLS and proxy-termination expectations, and does it support binding below port 1024 (it runs as nonroot)?
5. What is the observability surface — structured logs, /metrics, health endpoint — given there is no shell in the image for ad-hoc debugging?
6. License terms, security disclosure policy, and the maintainer's stated path to 1.0.

Integration Approach

Stack fit

• Fits a standard Laravel broadcasting stack with no application changes: same Pusher app key/secret/cluster contract, same Echo client, same channel authorization endpoint on the Laravel side.
• The distroless nonroot image aligns well with hardened Kubernetes/ECS baselines: no shell, minimal CVE surface, ~10 MB pull, trivial cold-start on both amd64 and arm64 (relevant for Graviton/Fargate cost profiles).

Migration path

• Treat as a shadow deployment, not a migration. Run reverb-rs alongside the existing Reverb instance on a non-production hostname, point a small internal Echo client at it, and diff behaviour on the channel types we actually use.
• Do not swap the production WebSocket endpoint until parity is demonstrated for presence channels and auth callbacks specifically — those are the highest-blast-radius divergences (silent auth failures, dropped presence state).
• Preferred production shape is the container image, not the Composer package: the composer path re-introduces a runtime download and couples a Rust binary to a PHP release cycle.

Compatibility

• Requires a Laravel version compatible with the package's constraints (not stated in the notes — must verify before composer require).
• Multi-arch images cover both x86 and ARM fleets; confirm our base images and CI runners match.
• Because it is a drop-in at the protocol level, rollback is a DNS/service swap back to Reverb — cheap, provided we do not delete the existing deployment.

Sequencing

1. Pin an exact version (0.1.1), vendor or mirror the image into our registry, never pull latest from GHCR at deploy time.
2. Spike: stand up the sidecar in staging, exercise private/presence/client-event paths, record gaps.
3. Harden: add checksum verification if using the composer path; add TCP/HTTP health probes since distroless has no curl.
4. Pilot one low-traffic, non-critical realtime feature behind a feature flag.
5. Decide on broad adoption only after a 1.0 milestone or an explicit parity commitment — not before.

Operational Impact

Maintenance

• Low runtime maintenance if pinned: a static binary in a distroless image has essentially no patch treadmill and no PHP-extension drift.
• Higher tracking maintenance: pre-1.0 means breaking changes are expected in minor versions. Budget for reading every changelog and re-running parity tests on each bump; avoid floating version constraints entirely.
• Dual-stack burden during evaluation: two WebSocket servers to operate, monitor, and secure.

Support

• No vendor support. Recourse is GitHub issues on a personal-account project. Escalation path for a production incident is effectively "roll back to Reverb."
• Internal ownership must be explicit: whoever owns realtime owns this dependency, including the pinning policy.

Scaling

• Single-node scaling is the headline benefit: a ~10 MB static binary with a small RSS footprint should handle high concurrent-connection counts more cheaply than a PHP worker-per-connection model. Confirm with our own load test rather than assuming.
• Horizontal scaling is the open question. Without Redis pub/sub fan-out, we are capped at one replica with no HA — acceptable for a pilot, disqualifying for a tier-1 realtime surface.
• nonroot binding means the listen port must be ≥1024; ensure service definitions and probes reflect the actual port.

Failure modes

• Deploy-time binary fetch failure (composer path) → build breaks or, worse, container starts without a binary. Mitigate by baking into the image at build time.
• Architecture mismatch on an unexpected runner → immediate startup failure; mitigate with an explicit --platform pin.
• Silent protocol divergence → clients connect but presence state or client events misbehave; this is the dangerous class because it may not trip alerts. Mitigate with synthetic Echo probes asserting round-trip and presence membership.
• No shell in the image → no exec debugging, no ad-hoc curl. Health checks must use TCP or an in-binary endpoint; rely on structured logs shipped to the platform.
• Maintainer abandonment or a compromised release artifact → no upstream fix available; mitigate by mirroring artifacts internally and treating upgrades as deliberate, reviewed events.

Ramp-up

• Engineer ramp-up is small for the container path (familiar deployment, unfamiliar internals) but requires the team to accept that debugging happens via logs and metrics only, with no ability to inspect the running process.
• Add a short written runbook covering: pin/mirror procedure, parity test suite, rollback to Reverb, and health-probe semantics.
• Net recommendation: evaluate, do not adopt. The v0.1.1 release is a packaging milestone only — it improves distribution ergonomics (multi-arch, distroless, artisan tooling) without answering any of the protocol-parity, scaling, or governance questions that gate production use.