ntfy/docs/faq.md

Frequently asked questions (FAQ)

Isn't this like ...?

Who knows. I didn't do a lot of research before making this. It was fun making it.

Can I use this in my app? Will it stay free?

Yes. As long as you don't abuse it, it'll be available and free of charge. While I will always allow usage of the ntfy.sh server without signup and free of charge, I may also offer paid plans in the future.

What are the uptime guarantees?

Best effort.

ntfy currently runs on a single DigitalOcean droplet, without any scale out strategy or redundancies. When the time comes, I'll add scale out features, but for now it is what it is.

In the first year of its life, and to this day (Dec'22), ntfy had no outages that I can remember. Other than short blips and some HTTP 500 spikes, it has been rock solid.

There is a status page which is updated based on some automated checks via the amazingly awesome healthchecks.io (no affiliation, just a fan).

What happens if there are multiple subscribers to the same topic?

As per usual with pub-sub, all subscribers receive notifications if they are subscribed to a topic.

Will you know what topics exist, can you spy on me?

If you don't trust me or your messages are sensitive, run your own server. It's open source. That said, the logs do contain topic names and IP addresses, but I don't use them for anything other than troubleshooting and rate limiting. Messages are cached for the duration configured in server.yml (12h by default) to facilitate service restarts, message polling and to overcome client network disruptions.

Can I self-host it?

Yes. The server (including this Web UI) can be self-hosted, and the Android/iOS app supports adding topics from your own server as well. Check out the install instructions.

Is Firebase used?

In addition to caching messages locally and delivering them to long-polling subscribers, all messages are also published to Firebase Cloud Messaging (FCM) (if FirebaseKeyFile is set, which it is on ntfy.sh). This is to facilitate notifications on Android.

If you do not care for Firebase, I suggest you install the F-Droid version of the app and self-host your own ntfy server.

How much battery does the Android app use?

If you use the ntfy.sh server, and you don't use the instant delivery feature, the Android/iOS app uses no additional battery, since Firebase Cloud Messaging (FCM) is used. If you use your own server, or you use instant delivery (Android only), or install from F-droid (which does not support FCM), the app has to maintain a constant connection to the server, which consumes about 0-1% of battery in 17h of use (on my phone). There has been a ton of testing and improvement around this. I think it's pretty decent now.

Paid plans? I thought it was open source?

All of ntfy will remain open source, with a free software license (Apache 2.0 and GPLv2). If you'd like to self-host, you can (and should do that). The paid plans I am offering are for people that do not want to self-host, and/or need higher limits.

What is instant delivery?

Instant delivery is a feature in the Android app. If turned on, the app maintains a constant connection to the server and listens for incoming notifications. This consumes additional battery (see above), but delivers notifications instantly.

Can you implement feature X?

Yes, maybe. Check out existing GitHub issues to see if somebody else had the same idea before you, or file a new issue. I'll likely get back to you within a few days.

I'm having issues with iOS, can you help? The iOS app is behind compared to the Android app, can you fix that?

The iOS is very bare bones and quite frankly a little buggy. I wanted to get something out the door to make the iOS users happy, but halfway through I got frustrated with iOS development and paused development. I will eventually get back to it, or hopefully, somebody else will come along and help out. Please review the known issues for details.

Can I disable the web app? Can I protect it with a login screen?

The web app is a static website without a backend (other than the ntfy API). All data is stored locally in the browser cache and local storage. That means it does not need to be protected with a login screen, and it poses no additional security risk. So technically, it does not need to be disabled.

However, if you still want to disable it, you can do so with the web-root: disable option in the server.yml file.

Think of the ntfy web app like an Android/iOS app. It is freely available and accessible to anyone, yet useless without a proper backend. So as long as you secure your backend with ACLs, exposing the ntfy web app to the Internet is harmless.

If topic names are public, could I not just brute force them?

If you don't have ACLs set up, the topic name is your password, it says so everywhere. If you choose a easy-to-guess/dumb topic name, people will be able to guess it. If you choose a randomly generated topic name, the topic is as good as a good password.

As for brute forcing: It's not possible to brute force a ntfy server for very long, as you'll get quickly rate limited. In the default configuration, you'll be able to do 60 requests as a burst, and then 1 request per 10 seconds. Assuming you choose a random 10 digit topic name using only A-Z, a-z, 0-9, _ and -, there are 64^10 possible topic names. Even if you could do hundreds of requests per seconds (which you cannot), it would take many years to brute force a topic name.

For ntfy.sh, there's even a fail2ban in place which will ban your IP pretty quickly.

Where can I donate?

I have just very recently started accepting donations via GitHub Sponsors. I would be humbled if you helped me carry the server and developer account costs. Even small donations are very much appreciated.

Can I email you? Can I DM you on Discord/Matrix?

While I love chatting on Discord, Matrix, Lemmy, or GitHub, I generally do not respond to emails about ntfy or direct messages about ntfy, unless you are paying for a ntfy Pro plan, or you are inquiring about business opportunities.

I am sorry, but answering individual questions about ntfy on a 1-on-1 basis is not scalable. Answering your questions in the above-mentioned forums benefits others, since I can link to the discussion at a later point in time, or other users may be able to help out. I hope you understand.