Web Push Bundle Laravel Package

Product Decisions This Supports

• Channel strategy: in-app re-engagement without a per-message vendor bill. Web Push is a free, standards-based channel (RFC 8030 + VAPID) that reaches users through the browser without an app store, an SDK contract, or a marketing-automation subscription. This package lets you validate "is push a channel we should own?" with roughly days of backend effort instead of a vendor procurement cycle.
• Build vs. buy, decided in layers. The right framing is: buy the protocol implementation, build the product logic. minishlink/web-push (the library this bundle wraps) absorbs the painful, low-differentiation parts — payload encryption (aes128gcm), VAPID JWT signing, endpoint fan-out. What stays in-house and is product-differentiating: subscription lifecycle, send triggers, segmentation, frequency caps, and notification copy.
• PWA / web-first roadmap validation. If you are investing in a PWA, offline support, or a mobile-web experience, push is the retention counterpart to that investment. This is the cheapest way to test whether push actually moves a retention or reactivation metric before committing to native apps, FCM/APNs plumbing, or a CPaaS (OneSignal, Braze, Iterable).
• Vendor independence as a hedge. Self-hosted VAPID means no lock-in on the delivery path and no per-subscriber pricing. That is a legitimate hedge if push volume is uncertain or if the channel may be sunset — you can kill it without renegotiating a contract.
• Feature-level decisions it enables: event-triggered notifications (order shipped, price drop, comment reply, trial expiring), silent/background pushes for cache and data refresh, topic-based broadcast to segments, and TTL-based "stale by design" messages.
• Observability and egress control as first-class config, not a fork. The v7.0.0 release makes the bundle's HTTP client customizable through configuration. For teams where outbound traffic must traverse a proxy, carry tracing/metrics middleware, or enforce timeouts and retry policy centrally, that moves a previously "fork the vendor code" concern into supported configuration — which strengthens the build-vs-buy case for owning the send path in-house.
• Explicit non-goal to socialize: this is not a marketing campaign platform. It ships no analytics, no A/B testing, no send-time optimization, no segmentation UI, no delivery dashboards. Those are your build items or your buy items — decide which before scoping.

Adoption caveat you must surface up front: despite the "Laravel/PHP" framing, this package is a Symfony bundle. It will not drop into a Laravel application. Laravel teams should evaluate the underlying minishlink/web-push library directly (or a Laravel notification-channel wrapper) and treat this bundle as evidence that the library is conventional enough to have framework glue — not as the artifact to adopt.

Release note (v7.0.0): this is a major version bump with a required migration, tracking upstream web-push-php v11.0.0. Practical implications for the decision: (a) confirm your PHP runtime and HTTP client stack meet the new upstream baseline before committing to an upgrade slot — this is a "verify, don't assume" item; (b) budget a small, bounded migration task rather than treating the bundle as version-drift-free; (c) read the customizing-the-HTTP-client documentation, since that is now where proxy/timeout/middleware concerns belong instead of custom patches. The strategic recommendation is unchanged — the bundle remains thin glue — but the upgrade cadence is now a known, recurring line item rather than a hypothetical.

When to Consider This Package

Adopt (or, more precisely, adopt its underlying library) when:

• The application is Symfony and you want the client wired into the service container with config-based VAPID keys rather than hand-rolled bootstrap code. This bundle's entire value is DI configuration and key management — a thin but real convenience.
• You need standards-based Web Push only — browser endpoints, no APNs/FCM native tokens.
• Your team is PHP-native and you want to avoid standing up a Node microservice purely to send push. Keeping the send path inside the monolith reduces operational surface and on-call complexity.
• You want self-managed VAPID keys for compliance, data-residency, or cost reasons, and can accept the operational burden of key custody and rotation.
• You need controlled egress — proxy support, custom timeouts, retry policy, or instrumentation on outbound push calls. As of v7.0.0 this is configuration, not a code fork, which is a real win for regulated or platform-engineering-governed environments.
• The bundle is a low-risk thin wrapper: because the real logic lives in the upstream library, swapping out the bundle layer later is cheap. v7.0.0 both confirms and qualifies this — the bundle does track upstream majors, so "cheap to swap" is true but not free; expect a documented migration each time the upstream library takes a major bump.

Look elsewhere when:

• You are on Laravel. Use minishlink/web-push directly or a Laravel-native notification channel. Do not attempt to adapt this bundle; the coupling tax exceeds the convenience.
• You need native mobile push. iOS/Android app push requires APNs/FCM credentials and SDKs. Web Push covers the browser; it is not a substitute.
• Push is a growth campaign surface, not an engineering primitive. The moment you need segments, journeys, scheduling, A/B tests, and per-message attribution, a CPaaS buys you months. Building those on top of this is a multi-quarter commitment, not a sprint.
• You need delivery SLAs, per-message support, or guaranteed throughput at scale. Self-hosted means you own the endpoint-failure tail, retry policy, and the 404/410 pruning loop.
• You cannot absorb periodic major-version upgrades. v7.0.0 is a breaking release requiring a migration step. If your roadmap has no room for a recurring, small dependency-upgrade task, that friction is real — pin the upstream library version deliberately and schedule the bump.
• Ecosystem-risk tolerance is low. 61 stars and zero dependents is a weak adoption signal, and single-maintainer bundles carry bus-factor risk. Mitigate by treating the upstream library as the dependency of record and pinning versions. The v7.0.0 release, tracking upstream v11, is a positive maintenance signal — the bundle is being kept current, not abandoned.
• Your users are predominantly on iOS Safari with low PWA install rates. Web Push reach on iOS is constrained by install-to-home-screen behavior; model realistic addressable audience before promising reach.

How to Pitch It (Stakeholders)

For executives (30 seconds): "Web Push is an owned re-engagement channel that costs nothing per message and needs no app store approval. This MIT-licensed library gives us the hard part — encryption and authentication to browser push services — for free, so we can test whether push improves retention in days rather than signing a vendor contract. If the channel works, we keep it and pay nothing at scale; if it doesn't, we delete a dependency. The strategic value is optionality: we learn whether push matters before we spend on a platform. The project is actively maintained — the latest major release just brought it in line with the current upstream library — which is the signal we want before building on it."

For engineering (the actual decision): "The bundle is thin Symfony glue over minishlink/web-push, a mature PHP implementation of Web Push with VAPID and payload encryption. Real work is not the send call — it's the subscription store, the lifecycle (prune endpoints on 404/410, handle expired), the client service worker and permission flow, and the trigger points in our domain events. Estimate the backend at days; the client and subscription management is where the sprint goes. For our Laravel services, do not use this bundle — use the underlying library. Pin the library version; the bundle is replaceable, the library is the contract. Note the v7.0.0 release is breaking and follows upstream web-push-php v11 — verify our PHP version and HTTP client stack against the new baseline, schedule the migration explicitly rather than letting it ride along with a feature branch, and put any proxy, timeout, retry, or metric instrumentation into the supported HTTP client configuration the release now exposes instead of patching the vendor."

Risks to state, not bury: single-maintainer, low-adoption ecosystem; a recurring major-version upgrade burden now demonstrated by v7.0.0; no built-in analytics or delivery observability (we instrument it ourselves); permission-prompt UX is the single biggest determinant of success and lives entirely in our product layer, not in this package.