Pushover Bundle Laravel Package

Getting Started

First, calibrate expectations: sly/pushover-bundle is a Symfony2 bundle, not a Laravel package. There is no service provider, no facade, no config publishing, no notification channel. In a Laravel app you will not “install and go” — you’ll either (a) extract the underlying Pushover client from the bundle and wire it manually, or (b) skip the bundle entirely and call the Pushover REST API with Http::withToken() / Guzzle. Given 8 stars, 0 dependents, and a Symfony 2.x-era codebase (EOL 2018/2019), treat this package as reference material, not a dependency.

Where to look first, in this order:

1. README.md — for the config keys (app token + user/group key) and the service id.
2. DependencyInjection/*Extension.php and Resources/config/services.yml — this is where the bundle defines its service id and constructor arguments. That file is the real integration surface.
3. The PushOver/client class itself — usually a thin wrapper over curl or an HTTP call with a send()-style method.

If you decide to consume the client class directly (dropping the bundle scaffolding), the wiring looks like this:

// composer.json — only if the client class is usable standalone
"require": { "sly/pushover-bundle": "^1.0" }

// config/services.php
'pushover' => [
    'token' => env('PUSHOVER_APP_TOKEN'),
    'user'  => env('PUSHOVER_USER_KEY'),
],

// app/Providers/AppServiceProvider.php
$this->app->singleton(\Ph3nol\PushOverBundle\PushOver::class, fn () => new \Ph3nol\PushOverBundle\PushOver(
    config('services.pushover.token'),
    config('services.pushover.user'),
));

In a real Symfony2 app the equivalent is new Ph3nol\PushOverBundle\PushOverBundle() in AppKernel::registerBundles() plus a pushover: block in config.yml — but that path is only relevant if you are maintaining a legacy Symfony 2.x estate.

First use case: ops alerting. Send a push to your phone when a queued job fails permanently, when a deploy finishes, or when an exception hits the handler. That is where a single-user-key notification service shines and where you’ll get value in an afternoon.

Implementation Patterns

Wrap it, don’t sprinkle it. Create one App\Services\PushoverNotifier with a send(string $message, ?string $title = null, array $options = []) method. Everything else in the app depends on that class, not the bundle. This makes the Symfony2 dependency swappable when you inevitably migrate to a raw HTTP client.

class PushoverNotifier
{
    public function __construct(
        private string $token,
        private string $user,
        private int $timeout = 5,
    ) {}

    public function send(string $message, ?string $title = null, array $opts = []): void
    {
        Http::asForm()->timeout($this->timeout)->post('https://api.pushover.net/1/messages.json', array_merge([
            'token'   => $this->token,
            'user'    => $this->user,
            'message' => $message,
            'title'   => $title,
        ], $opts))->throw();
    }
}

This is ~15 lines and reproduces the entire feature set of the bundle, with no Symfony2 baggage.

Queue it, or at least fail soft. Pushover is an external HTTP call with rate limits. Never call it inline in a request cycle. Wrap send() in a queued job (ShouldQueue, $tries = 3, backoff = [10, 60, 300]) so a Pushover outage can’t take down a user-facing request. For a quick spike, at minimum wrap the call in try/catch and log — a notification that fails must never bubble into business logic.

Bind it into the container as a singleton. Use a ServiceProvider::register() with $this->app->singleton(PushoverNotifier::class, fn () => new PushoverNotifier(config('services.pushover.token'), ...)). If you keep the bundle’s client class, alias it to your own interface so tests can fake it.

Compose with Laravel’s notification system. The idiomatic path is a custom channel implementing send(object $notifiable, Notification $notification) that delegates to PushoverNotifier. This gives you Notifiable, queueing, and per-notification retry for free. If you go this route, first evaluate laravel-notification-channels/pushover — it’s the maintained Laravel-native option and worth comparing for release recency before writing your own.

Use it from the exception handler and schedules. Two high-value integrations:

// app/Exceptions/Handler.php
public function register(): void
{
    $this->reportable(function (Throwable $e) {
        if ($e instanceof ShouldPageOps) {
            PushoverNotifierJob::dispatch($e->getMessage())->onQueue('alerts');
        }
    });
}

// routes/console.php
Schedule::command('backup:run')
    ->daily()
    ->onFailure(fn () => PushoverNotifierJob::dispatch('Backup failed'));

Keep credentials in the secret store. PUSHOVER_APP_TOKEN and PUSHOVER_USER_KEY in your env/vault; never in config/*.php committed to the repo.

Gotchas and Tips

• Do not composer require this on a modern Laravel stack. The bundle’s composer constraints pin symfony/* at 2.x and PHP at 5.x/7.x-era versions, which will hard-conflict with Laravel’s Symfony 6/7 requirements. You can force install with --ignore-platform-reqs, but then the bundle’s boot hook never runs under Laravel’s kernel and the services are simply never wired. You get the transitive dependency tree without the functionality.

• The bundle name and repo don’t match. sly/pushover-bundle vs Ph3nol/PushOverBundle, 8 stars, 0 dependents. That is a supply-chain red flag even at this size. Code that holds API tokens warrants a maintenance and provenance review, and there is none here.

• Pushover’s advanced semantics are almost certainly uncovered. Emergency priority (priority=2) requires retry and expire fields, and acknowledgement polling goes through /1/receipts/{receipt}.json. The bundle predates most of this and you will implement it yourself regardless — another reason to write the client directly.

• Watch the response codes. Pushover returns 429 on rate limit and 4xx on invalid token/user — Guzzle throws on both by default, and the bundle typically doesn’t handle either. In your own client, distinguish 429 (backoff and retry) from 400/401 (config bug — fail loudly, don’t retry-storm).

• Pushover licensing is per-user, not per-app. Each recipient needs a one-time purchase on each platform (iOS/Android). That is fine for an ops team of five and unworkable for consumer engagement. Decide this before wiring anything.

• Message quotas are per-application, monthly. Track usage; a noisy alert loop can silently exhaust the quota and then all alerts drop.

• Debugging locally: a PushoverNotifier bound to a fake in the container ($this->app->instance(PushoverNotifier::class, new FakeNotifier())) is far easier than mocking HTTP, and lets you assert on notification dispatch without hitting the real API.

• Extension point worth knowing: if you must keep the bundle’s client class (e.g. it encapsulates some behavior you want), extract it into a single class and bind it behind your own Notifier interface. That one indirection is the whole migration. When you next touch the file, replace the import with a direct Http:: call and delete the dependency.

• Escape hatch: if the requirement is genuinely “legacy Symfony 2.x in production needs Pushover this week,” vendor/fork the bundle, patch it, and plan its removal. In every other scenario — Laravel stack, PHP 8, maintained dependency graph — the correct move is to spend half a day writing the ~30-line client and skip the dependency entirely.