How push8030 works, what it can do, and everything you should know before using it.
push8030 is a web push notification gateway built on RFC 8030, the same open standard browsers use for push notifications, repurposed for personal automation.
You register one or more browsers, create a send endpoint, then POST to that endpoint URL from any script, webhook, cron job, or monitoring tool. Registered browsers receive the notification even when the page is closed. No app, no email, no third-party relay service.
/api/send/<token>. You can choose which browsers receive notifications
from each endpoint.
You can register up to 30 browsers across any number of devices, and create up to 5 send endpoints per profile. Each send endpoint and web form can be configured to notify only a subset of those browsers, so you can route different alerts to different devices rather than sending everything everywhere.
Endpoints can be created one per project, alert source, or use case, each independently configured with its own URL, notification defaults, and browser targets. Each endpoint can have preset values for any notification field (message, title, icon, URL, tag, TTL, urgency), and you control which of those fields a caller is allowed to override at send time.
Endpoint URLs contain a long random token. By default this is the only protection, but you can optionally require a separate auth token on a per-endpoint basis, supplied as a request header or query string parameter. If an endpoint URL is leaked regardless, delete it and create a new one with a fresh token. The old URL stops working immediately.
Each endpoint can optionally expose a web form at a separate URL, letting anyone with that link send a notification from their browser without ever seeing the API endpoint token. Pairing codes let you add browsers to an existing profile from a new device using a short-lived 6-digit code. The profile page shows per-endpoint and per-browser send counts for the last hour.
There are no passwords. A profile is accessed by being registered as a browser on it. The pairing code flow is the only way to add browsers to an existing profile.
Because of this, it is important to keep at least two browsers registered. If your only registered browser's push subscription becomes invalid (clearing site data, reinstalling the browser, OS reinstall), you lose access to the profile and cannot recover it. A second registered browser on another device is your fallback.
Send endpoint URLs contain a long random token. This is the only protection: anyone who has the URL can send notifications to the targeted browsers. If a URL is leaked or compromised, delete the endpoint and create a new one with a fresh random token. The old URL immediately stops working.
Web forms use a separate token from the send endpoint and only allow form submissions, so sharing a form URL does not expose the API endpoint token.
Sending a notification is a single HTTP POST to your endpoint URL. The design goal is to be compatible with whatever system is doing the sending, whether that is a shell script, a cron job, a monitoring tool, or an existing webhook from a third-party service.
Each endpoint accepts one of three input formats: JSON (the default), URL-encoded
or multipart form data, or values read from HTTP headers
(X-Msg, X-Title, etc.). The headers format is particularly useful when
integrating with a service that sends a fixed body you cannot control, such as Grafana or Alertmanager.
The notification fields you can set are: msg (body text), title,
url (opened on click), icon, tag (replaces an earlier
notification with the same tag), topic (replaces a queued message if the browser is
offline), ttl (seconds to hold while offline, default 86400), and urgency
(very-low, low, normal, or high).
For each field you can set a preset value on the endpoint, and independently control whether the caller is allowed to override it. This means you can, for example, lock the title and icon to match a particular source while still letting the caller supply the message text. The curl command on your profile page updates dynamically to reflect your current endpoint configuration, so you always have a ready-to-use example to copy.
Each send endpoint can expose a web form at /<username>/<slug>.
Anyone with that URL can fill in a short form in their browser to trigger a notification.
The form URL uses a separate token and only permits form submissions, not arbitrary API access. You can configure which browsers the form notifies independently of the main endpoint. The slug can be customised or the form disabled at any time from the endpoint panel.
Profile owners can enable guest signups, which lets other people subscribe to receive notifications from that profile. Guests appear in the owner's browser list (marked as guests).
Each send endpoint and web form can be configured to target any subset of browsers, including guest browsers. Guests cannot manage the profile, create endpoints, or see any credentials. They can unsubscribe themselves at any time, and the profile owner can remove any guest browser.
Each profile is limited to 5 send endpoints and 30 registered browsers. These numbers were picked arbitrarily to match the intended use case: Automation for one person or small team across a handful of devices and integrations. They are not meant to be punishing.
If you are doing something non-scummy and need more, get in touch and I can raise them.
Rate limits also apply per endpoint and per browser to prevent bursts. Specific numbers are not
published to avoid gaming, but occasional alerts from scripts or webhook integrations will not come
close. Rate-limited requests receive a 429 Too Many Requests response.
push8030 is a personal side project, not a commercial service. It runs on a single server with no redundancy, no SLA, and no uptime guarantee. Notifications may be delayed, dropped, or fail silently if the server is down, restarting, or under load.
It is intended for casual, non-critical use: personal monitoring, convenience alerts, hobby automation. Please do not use it for anything where a missed notification would cause real problems, such as production incident alerting, medical reminders, or financial transactions.
The service may go offline, change, or be discontinued at any time without notice. Your data (browser subscriptions, endpoint configuration) is stored in a local database on the server and is not backed up to any external system.
push8030 stores only what is necessary to deliver notifications: your chosen username, your browser's Web Push subscription endpoint (provided by your browser/OS vendor), and your endpoint configuration.
Your data is never shared with anyone, ever. There are no analytics, no advertising, no third-party tracking scripts, and no external services that receive your data beyond the browser push infrastructure (such as FCM or APNs) that your device already uses for all web push notifications.
Notification content (message text, title, etc.) is transmitted to your browser's push server encrypted using VAPID keys held on this server. The browser vendor (Google, Apple, Mozilla, etc.) cannot read the content of your notifications. I could read them if I chose to, but I am not logging or inspecting message content. If I notice usage patterns that look like abuse, I may take a look and may delete a profile if I do not like what I see.
No logs of notification content are retained beyond what is needed to show the per-hour send counts visible in the UI. You can delete your profile and all associated data at any time by removing all browsers from your profile.
curl POST is all you need.
The curl command for each endpoint is shown on your profile page for easy copy-paste.
410 Gone response from the vendor means the subscription is permanently invalid.
Remove that browser and re-register it.
Questions, feedback, something broken, or anything else, please get in touch.
Happy to hear from anyone using this, for any reason.