Everything you need to know about using push8030.
push8030 is a personal push notification service. You register your browsers once, then trigger notifications from wherever you like: a script, a cron job, a monitoring tool, or a link you share with someone. Notifications arrive on your device even when the browser is closed.
Each endpoint and form can be configured to target any subset of your registered browsers, so you can route different alerts to different devices. For example: send server alerts only to your laptop, share a form that notifies your phone, or ping your whole team's browsers at once.
Under the hood it uses RFC 8030 Web Push, the same standard browsers use for all push notifications. No proprietary app, no email, no third-party relay.
happy-otter-42) which you can rename inline at the top of your profile.
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, keep at least two browsers registered. If your only 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 device is your fallback.
You can send notifications in three different ways
An API endpoint gives you a URL like /api/send/<token> that you can POST to from
anywhere. The token in the URL is the only protection by default, so keep it out of public repos.
If it leaks, delete the endpoint and create a new one; the old URL stops working immediately.
You can optionally require a separate auth token, supplied as a request header or query string parameter, for an extra layer of security.
Your profile page shows a ready-to-copy curl command for each endpoint:
curl -X POST https://push8030.com/api/send/<token> \
-H 'Content-Type: application/json' \
-d '{"msg": "Deploy finished"}'Endpoints accept three different input formats so you can integrate with whatever system is sending:
| Format | How to use | Best for |
|---|---|---|
| JSON | Content-Type: application/json with a JSON body |
Scripts, webhooks, most services |
| Form data | URL-encoded or multipart form body | Simple HTML forms, some monitoring tools |
| HTTP headers | X-Msg, X-Title, etc. |
Services like Grafana or Alertmanager where you can't control the body |
A web form gives you a shareable URL at /<username>/<slug> that anyone
can open in a browser to send you a notification by filling in a short form, no script, no API token,
no account required. Useful for alerting yourself from a shared dashboard, letting a teammate ping you,
or triggering a notification from your phone.
Forms have their own token, separate from any API endpoint, so sharing a form link does not expose API credentials. You choose which browsers the form notifies, and the slug can be customised or the form disabled at any time from your profile.
If you want to send push notifications directly from your own server, without routing through push8030 at all — you can download your VAPID key pair. From your profile, click "Download VAPID keys" to get a JSON file containing your public and private keys. You can also download a per-browser bundle that includes the browser's push subscription alongside the keys.
VAPID keys work with standard Web Push libraries in any language. Here are a few popular ones:
All three accept a VAPID public/private key pair plus a browser subscription object, which is exactly what the per-browser download bundle contains. This is the right option if you want full control over delivery, prefer not to depend on this service at send time, or need to send from a private network.
These are the fields available on any notification:
| Field | Description |
|---|---|
msg | The notification body text |
title | Notification title (defaults to your username) |
url | URL to open when the notification is clicked |
icon | Icon image URL |
tag | Replaces an earlier notification with the same tag |
topic | Replaces a queued message if the browser is offline |
ttl | Seconds to hold the notification while the device is offline (default: 86400) |
urgency | very-low, low, normal, or high |
For both API endpoints and web forms, you can set a default value for any field. You then control, per field, whether the sender is allowed to override it:
The curl command on your profile page updates live to reflect your current endpoint settings, so you always have an accurate copy-paste example.
Profile owners can enable guest signups, letting other people subscribe to receive notifications from that profile. Guests appear in the owner's browser list (marked as guests) and can be targeted by any endpoint or form.
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 limits reflect the intended use case: personal automation for one person or a small team. If you're doing something non-scummy and need more, get in touch and I can raise them.
Rate limits apply per endpoint and per browser to prevent bursts.
Specific numbers are not published, but occasional alerts from scripts or webhooks won't 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 or restarting.
It is intended for casual, non-critical use: personal monitoring, convenience alerts, hobby automation. Please do not use it for production incident alerting, medical reminders, or anything where a missed notification would cause real problems.
The service may go offline, change, or be discontinued at any time without notice.
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. There are no analytics, no advertising, no third-party tracking scripts. The only external systems that see any data are the browser push infrastructure (FCM, APNs, etc.) your device already uses for all web push notifications.
Notification content is transmitted encrypted using VAPID keys held on this server. The browser vendor cannot read the content of your notifications. No logs of notification content are retained beyond the per-hour send counts shown in the UI. You can delete your profile at any time by removing all browsers from it.
push8030 is open source (github.com/ollybee/webnotify). If you want guaranteed uptime, full control, or to keep your push traffic on your own infrastructure, run your own instance.
The whole service is a single Go binary with all HTML, JS, and CSS embedded. All state lives in one BoltDB file, created on first run. No database server, no Redis, no message queue, no other moving parts.
git clone https://github.com/ollybee/webnotify.git
cd webnotify
go build -o webnotify .
PORT=8080 DB_PATH=/var/lib/webnotify/webnotify.db ./webnotifyThe binary speaks plain HTTP only — there is no built-in TLS. Web Push requires HTTPS (browsers refuse to register service workers over plain HTTP on non-localhost origins), so you must run it behind a reverse proxy that terminates TLS. A one-line Caddyfile is enough:
push.example.com {
reverse_proxy 127.0.0.1:8080
}nginx, Traefik, HAProxy or any other HTTPS reverse proxy will do the same job.
Everything the service knows — profiles, subscriptions, endpoints, VAPID keys — lives in
webnotify.db. Back up that one file and you can restore the whole instance.
410 Gone response means the subscription is permanently invalid; remove that
browser and re-register it.