Pusher Push Notifications Laravel Package

Product Decisions This Supports

• Feature scoping for push. This package turns push into "one more via() channel" on Laravel's existing notification abstraction. That reframes the decision from "do we build a notification service?" to "which channels ship this quarter?" — push becomes a scoping call, not an engineering program.
• Build vs. buy at the delivery layer. You keep Notification classes as the product-facing contract and buy only the last mile (APNs/FCM credentials, device-token lifecycle, fan-out). The buy surface is one channel class plus config, so the decision is reversible.
• Platform coverage roadmap. One API covers iOS, Android, and web push. That materially affects sequencing: native apps vs. PWA-first, and whether "web push" is a launch feature or a fast-follow.
• Vendor concentration. If Pusher Channels is already in the stack, Beams is a marginal add on an existing contract. If not, this introduces a new vendor with its own pricing, quota, and data-processing terms — a procurement decision, not just a technical one.
• Notification taxonomy and segmentation. Beams' interest/topic model determines whether PM can run targeted broadcasts (per-segment, per-topic) without a data-team request, or whether everything is per-user device targeting.
• Lock-in cost estimation. Because the integration is thin, an exit to direct FCM/APNs or another provider is a contained engineering task rather than a re-architecture. Useful evidence when arguing for or against the vendor.

When to Consider This Package

Adopt when:

• You're on Laravel and notifications are already centralized in Notification classes — adoption cost is roughly a config entry plus a channel reference.
• You're on, or planning to move to, a current Laravel major. 4.4.0 adds Laravel 13.x compatibility, so the package is tracking framework upgrades rather than pinning you to an older Laravel — worth confirming the release line you adopt matches your framework version constraint (4.3.x for pre-13, 4.4.x for 13.x).
• You need push on iOS and Android and web without owning APNs certificate rotation, FCM setup, and stale-token cleanup.
• Volume is small-to-mid and Beams pricing is not material next to time-to-market.
• Pusher is already a vendor — one dashboard, one bill, one set of credentials.
• You specifically want interest/topic-based broadcast. That's the clearest product differentiator versus raw FCM; if you don't need it, the intermediary is harder to justify.

Look elsewhere when:

• You need rich push (images, action buttons, precise deep-link payloads), FCM data messages, or silent background sync — direct FCM via kreait/laravel-firebase gives more control.
• Web push only — laravel-notification-channels/webpush (VAPID) removes the paid intermediary entirely.
• High volume or cost-sensitive — per-notification pricing at scale generally loses to direct FCM/APNs.
• The client is Expo / React Native heavy — Expo push or native SDKs may fit better.
• You need an SLA, guaranteed maintenance, or a vendor security review. dependents: 0 and modest stars are diligence signals: treat this as spike-and-validate, pin the version, and accept that forking is a realistic fallback. That said, the 4.4.0 Laravel 13 compatibility release (via laravel-shift) is a positive maintenance signal — the package is being kept current with the framework, which is the failure mode that usually kills abandoned channel packages. It is still not a commercial support commitment, and low dependents means few public war stories — budget for your own edge-case testing.
• Push analytics, A/B testing, or journey orchestration are requirements — that's a different tool class (OneSignal, Braze, Airship) and shouldn't be smuggled into this decision.

How to Pitch It (Stakeholders)

Executives. For roughly a day of integration work we get cross-platform push — iOS, Android, and web — without standing up notification infrastructure or owning APNs/FCM credential operations. It rides on the notification system we already have, so every future push is a small addition rather than a new project. The trade-offs are a delivery-layer dependency on Pusher Beams and a modest community package; both are bounded, because the integration surface is a single channel class we can replace or fork without product-visible change. Maintenance risk is contained: the package shipped a Laravel 13 compatibility release, so it's being actively kept current, and if it ever stalls we own the fallback (pin, fork, or swap to a direct FCM/APNs channel).

Engineering. This is a thin adapter: config entry, a BeamsChannel, and device interest registration on login/logout. No new queue topology, no new worker fleet — it uses Laravel's existing queue and Notifiable models. 4.4.0 is a compatibility-only release (Laravel 13.x support, no API or config changes), so upgrading from 4.3.0 carries no migration work — but align the package constraint with the Laravel major you deploy. Validate in a one-week spike: multi-device users and interest lifecycle, web push behavior, stale-device cleanup, and failure/retry semantics when Beams is unreachable. If we later need richer payloads or lower per-message cost, the fallback is swapping one class for a direct FCM/APNs channel behind the same via() contract.