Pushover

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build me notifications from my own scripts, replacing Pushover — and read the obstacle, because it is the whole verdict.

**Delivery goes through Apple and Google, and the applications on the stores are what you are paying for.** Publishing your own means developer accounts, a review queue and a release every time something changes — for a tool that costs a few euros once. That is why this is ALMOST rather than YES. But there are two routes that need no store at all, and for most people one of them is the right answer.

STACK
- Node 20+ with Fastify
- SQLite through better-sqlite3, WAL mode
- Web push with VAPID keys, which needs no account and no store
- Caddy in front

THE THREE ROUTES, IN ORDER OF EFFORT
- **Web push to an installed web application.** Generate a VAPID key pair once, serve a small installable page, and the browser's own push service delivers your notifications. No developer account, no fee, no review. Works on desktop browsers and Android; on iOS it works only for a web application added to the home screen, which is a real limitation to state plainly
- **An existing self-hosted notification service** with published applications. Several exist, they are free, and they solve exactly the store problem. Using one is not a failure — it is the sensible answer for most people, and the README should say so
- **Your own native applications**, if you genuinely need iOS reliability, priority handling and acknowledgement. Then you are running a small mobile release process forever

THE API, WHICH IS THE EASY PART
- POST a title, a message, a priority, a URL, and optionally a sound and an image
- A token per application and a key per recipient device group, both revocable
- Answer in a couple of milliseconds and deliver after responding
- Idempotency by a caller-supplied key, so a script retried by cron does not notify twice
- Rate limits per token, generous but present, because a loop in a shell script will find them

THE DATA MODEL
- applications: id, name, token_hash, icon_path, is_active
- devices: id, user_id, platform, endpoint, keys_json, label, created_at, last_seen_at, invalid_at, invalid_reason
- messages: id, application_id, title, body, priority, url, url_title, sound, image_path, ttl_seconds, created_at
- targets: id, message_id, device_id, status, attempts, provider_ref, sent_at, delivered_at, acknowledged_at, error
- One target row per device, written before sending, which makes a resume exact and a duplicate impossible

PRIORITIES, WHICH IS THE FEATURE THAT MATTERS
- Low: no sound, no vibration, delivered quietly
- Normal: the usual notification
- High: bypasses quiet hours, because some things genuinely cannot wait
- Emergency: repeats at an interval until acknowledged, with an expiry. That acknowledgement loop is the reason this category exists — a disk-full alert that appears once at three in the morning is an alert you sleep through
- Acknowledgement from the notification itself, recorded, and the repeat stops everywhere including on other devices

TOKEN LIFECYCLE
- Tokens expire and are revoked. Every rejection tells you why: a permanent failure marks the device invalid immediately, a transient one retries with backoff
- Never keep retrying an endpoint the platform has told you is gone
- Prune devices not seen in a long time, and record why

RESPECTING YOURSELF
- Quiet hours per device in its own zone, with high and emergency ignoring them
- A frequency cap per application, so one broken script cannot send four hundred notifications
- Categories with a per-category preference, because a nightly backup report and a production alert are not the same thing

OPERATIONS
- .env: DATABASE_PATH, BASE_URL, VAPID keys, SESSION_SECRET
- Migrations on boot, each once; nightly backup off the machine
- Health endpoint reporting invalid-token rate and queue depth
- A curl example in the README that works, because that is how anybody will actually use this

WHAT MATTERS MOST
Emergency acknowledgement and honest platform limits. Build the repeat-until-acknowledged loop, and write down clearly which of the three routes you chose and what it cannot do.