Weave Code
Pusher Push Notifications Laravel Package
laravel-notification-channels/pusher-push-notifications
Send Laravel notifications as push notifications through Pusher's Push Notifications (Beams) service. This channel lets you deliver mobile and web push messages using Laravel's familiar notification system, with support for device interest subscriptions and rich payloads.
Pusher native Push Notifications driver.
Frequently asked questions about Pusher Push Notifications
- How do I install laravel-notification-channels/pusher-push-notifications?
- Install it with Composer using composer require laravel-notification-channels/pusher-push-notifications. The service provider is auto-discovered, so no manual registration is needed in modern Laravel versions. Publish the package config file with vendor:publish and fill in your Pusher Beams instance ID and secret key. After that you reference the channel in a notification's via() array and implement a toPusherBeams() method.
- Which Laravel versions does this Pusher Beams notification channel support?
- Release 4.4.0 adds Laravel 13.x compatibility, and the package is kept current with Laravel majors through automated laravel-shift pull requests. Because a minor bump that adds support for a new major can coincide with dropping older versions, check the composer.json constraint before assuming your current Laravel release is still covered. The upgrade itself does not change the integration surface: no new config keys, features, or client-side implications.
- How do I send a push notification from a Laravel notification using this channel?
- Add the package's channel class to the via() array of your notification and implement a toPusherBeams() method that returns the package's message object. In that message you declaratively set the title, body, deep link, sound, and the interests or user IDs to target. The channel then hands the payload to Pusher Beams, which fans it out to the subscribed devices. No schema changes, workers, or custom transport code are required on your side.
- How do I target specific users or device groups with Pusher Beams?
- Beams targets interests and authenticated user IDs rather than raw device tokens, so your mobile clients must embed the Beams SDK and call your auth endpoint to bind each device to a user ID. You then design an interest taxonomy (per-user, per-topic, per-tenant) and publish to those interests from the notification message. Plan this taxonomy before shipping client builds, because retrofitting it later means republishing your apps. The PHP adapter is the easy part; targeting design is where the real effort sits.
- Do push notifications sent through this channel need to be queued?
- They do not have to be, but the channel composes cleanly with Laravel's ShouldQueue interface and with notification rate limiting. Queueing is recommended so a slow Beams API call never blocks a web request or an existing job. No queue, worker, or schema changes are needed beyond what you already use for queued notifications.
- What credentials and configuration does the package need?
- You need a Pusher Beams instance ID and a secret key, supplied through environment variables or your secret manager rather than committed config. After installing, publish the config file and map those values into it. Treat the secret key as high-risk: a leaked instance secret allows arbitrary pushes to your entire install base, so plan storage and rotation deliberately. The package itself stores no device state and owns no transport, retries, or registration flow.
- Does this package support web push as well as iOS and Android?
- Pusher Beams supports iOS, Android, and web push, and this channel is simply a Laravel-side adapter for the Beams API. In practice, web push through Beams is the least mature surface and is worth scoping out of an initial rollout unless it is explicitly required. Deciding which platforms are in scope for v1 materially changes both the client effort and the risk profile.
- How can I test Pusher Beams notifications without sending real pushes?
- Use Laravel's Notification::fake() to assert that a notification was routed to the channel with assertSentTo, which keeps CI from hitting the Beams API. To assert the actual payload your toPusherBeams() method builds, instantiate the notification and inspect the returned message object directly. For end-to-end paths, bind a fake or mock of the Beams client in the container instead of relying on the real service. Be aware that Beams offers minimal per-message observability, so verifying real delivery is largely a manual exercise.
- What are the alternatives to using Pusher Beams for Laravel push notifications?
- You can integrate directly with FCM and APNs, use another Laravel notification channel package, or call the Beams PHP SDK yourself without this adapter. Because this package is a thin wrapper contributing one channel class and one message object, replacing it is quick. The harder dependency is Beams itself: the vendor account, the device-registration flow in your clients, and the interest topology are what actually lock you in.
- Is the package actively maintained, and what are the production risks?
- Maintenance looks healthy on the adapter side, with an automated cadence of Laravel compatibility releases such as 4.4.0 for Laravel 13.x. Community validation is thin, however: roughly 279 stars and effectively no dependent packages means you should expect to debug against the Pusher Beams API docs rather than finding answers on Stack Overflow or GitHub issues. The larger production risks are vendor concentration on a managed push service with a niche footprint, best-effort delivery with limited per-message observability, and the blast radius of a leaked instance secret.
Weaver
How can I help you explore Laravel packages today?