When a push provider shuts down, your subscribers’ browser permission stays, but the push subscriptions stop working. They’re tied to the provider’s service worker and VAPID keys, and you usually can’t export them. Visitors who return can often be resubscribed silently by a new tool on the same domain. Subscribers who never return are lost.
This isn’t a hypothetical risk. Truepush, a well-known free web push service, told users in its dashboard that it would suspend services from August 31, 2024, as Punto Informatico reported. We covered that at the time in Notix and Truepush are shut down. In this post I explain, step by step, what happens to push subscribers when a provider closes, what you can save, and how to protect your list next time.
What happens to push subscribers when a provider shuts down?
When a push provider shuts down, nobody can send to the existing subscriptions it managed, because the provider’s server held the signing key. The subscribers themselves aren’t notified. Their browsers still show your site as allowed, but no messages arrive.
Here’s what changes and what doesn’t:
| Item | After the provider shuts down |
|---|---|
| Browser notification permission for your domain | Stays granted; it belongs to your site’s origin, not the provider |
| Push subscriptions (endpoints) created by the provider | Become unusable unless you hold the matching VAPID private key |
| Provider’s service worker file on your site | Keeps running until you remove or replace it |
| Subscriber data in the provider’s dashboard | Gone once the service closes, unless you exported it |
| Your own traffic and visitors | Unaffected; they can be resubscribed on return |
In other words, you lose the ability to reach people, but you don’t lose their permission. That difference is what makes recovery possible.
Why can’t you just export your web push subscribers?
You usually can’t export working subscriptions because each one is locked to the key that created it. Under RFC 8292, a push service must reject messages to a restricted subscription unless they’re signed with the private key used at subscribe time. Hosted providers normally create and keep that private key.
OneSignal says this directly in its migration guide: “Web subscriptions cannot be imported” because of browser security limits. Even moving between two OneSignal apps doesn’t transfer web push subscriptions, since each one is tied to the site origin and the app.
So an export of subscriber IDs is useful for counting and analysis. However, it doesn’t let a new tool send to those people. I explain the key mechanics in what VAPID keys are and why they matter.
Can you get your subscribers back after a shutdown?
You can get many of them back, but only the ones who visit your site again. Browser notification permission is granted per origin. So if a visitor already allowed notifications for your domain, a new push tool on the same domain can create a fresh subscription without showing the permission prompt again.
OneSignal documents exactly this behaviour for its own migrations. On the same HTTPS origin, existing subscribers are “silently added to OneSignal on their next visit” with no prompt, once the old service worker is removed. Other tools can use the same browser behaviour, since it comes from the Notifications API rather than any vendor.
The limits are just as clear:
- No visit, no subscription: people who don’t return can’t be resubscribed.
- Same origin only: moving from www to non-www, or to a new domain, breaks the link.
- Old service worker must go: OneSignal’s guide says to unregister the old provider’s service worker before the new tool takes over.
- Blocked users stay blocked: anyone who denied or turned off notifications isn’t recoverable.
What should you do in the first week after a shutdown notice?
Act before the shutdown date, while the old dashboard still works. Here’s the sequence I’d follow:
- Export everything you can: subscriber counts, segments, campaign history and any tags. You’ll want the numbers to measure recovery.
- Pick the replacement tool: choose one that runs on your same domain and supports silent resubscription for granted users.
- Remove the old SDK and service worker: delete the provider’s script and service worker file, and unregister the old worker.
- Install the new tool on the same origin: keep the exact same protocol and domain, including www or not.
- Send campaigns from the new tool as subscribers return: your list rebuilds as regular visitors come back.
- Track recovery weekly: compare new subscriber counts with your exported total.
Speed matters here. Every day without a working tool is a day returning visitors aren’t being resubscribed.
How do you protect your subscribers from the next shutdown?
You protect your list by controlling the parts a shutdown would take away: the keys, the subscriber database and the domain. Here’s how common setups compare on that risk:
| Setup | Who holds the VAPID private key | Who stores subscriber data | Risk if the vendor closes |
|---|---|---|---|
| Hosted SaaS push service | Usually the vendor | Vendor | High: sending stops at shutdown |
| Free ad-funded push service | Usually the vendor | Vendor | High: plus the business model may change |
| Self-hosted panel on your server | You (your server or your own Firebase project) | Your server | Lower: your data stays with you, but you maintain it |
| Your own code with open-source libraries | You | You | Lowest vendor risk, highest build effort |
Whatever you use, a few habits help:
- Use your own domain for the service worker, not a provider subdomain.
- Export subscriber data regularly, if your tool allows it.
- Read the provider’s terms on data ownership and closure notice.
- Watch for warning signs, such as sudden plan changes or long gaps in support.
For more on the trade-offs, see self-hosted vs SaaS push notifications and the pillar guide to push notification services.
Does this apply to mobile app push too?
Partly. Mobile app push works differently, because the push token belongs to your app on the device. OneSignal’s migration guide says iOS subscriptions can receive push right after import, while Android needs the new SDK active on the device. So app tokens can often be moved, but web push subscriptions can’t.
Where does LaraPush fit?
LaraPush is a self-hosted web push panel that runs on your own VPS, so subscriber data lives on your server, not a vendor’s. It’s a one-time purchase, from $499 (see LaraPush pricing), with unlimited subscribers.
There are trade-offs. You maintain the server and backups, there’s no free plan, and the licence covers one server. For switching from another provider, LaraPush offers a Migration Add-on; contact the team for details on what carries over in your case. The LaraPush guide covers setup on your own domain.
Frequently asked questions
Your subscribers keep the notification permission they gave your domain, but the provider’s push subscriptions stop working because only the provider could sign messages to them. Visitors who return can usually be resubscribed silently by a new tool on the same domain. Those who never return are lost.
Usually not in a way that keeps them working. Web push subscriptions are bound to the VAPID key used when they were created, and hosted providers normally keep that key. OneSignal’s migration guide states that web push subscriptions cannot be imported because of browser security limits.
Not if you stay on the same origin. Notification permission is stored per origin, so a new push tool can create a fresh subscription without a prompt when a subscriber with granted permission returns. Changing domain, or switching between www and non-www, means they’d need to opt in again.
As soon as possible, and before the shutdown date. Export your data while the dashboard still works, then replace the old service worker with your new tool on the same domain. Every day without a working tool means returning visitors aren’t being resubscribed.
Self-hosting lowers vendor risk, because the subscriber database and sending setup sit on your own server rather than in a vendor’s account. However, you take on server maintenance, backups and security yourself.
