starred/ntfy

Fork 0

mirror of https://github.com/binwiederhier/ntfy.git synced 2026-05-09 08:26:00 +02:00

[GH-ISSUE #227] ntfy clustering #182

New issue

Closed

opened 2026-05-07 00:21:08 +02:00 by BreizhHardware · 5 comments

BreizhHardware commented

2026-05-07 00:21:08 +02:00

Owner

Originally created by @mhameed on GitHub (Apr 29, 2022).
Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/227

Hi,

Thanks for ntfy, its a great project.
I am thinking maybe ntfy can be made into a highly available service.
I have an etcd cluster setup, and thought it would be a great fit for ntfy storage when we need ntfy to be HA.
unfortunately my golang foo is very limited, so this is only a RFE.
Thanks for your consideration.

Originally created by @mhameed on GitHub (Apr 29, 2022). Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/227 Hi, Thanks for ntfy, its a great project. I am thinking maybe ntfy can be made into a highly available service. I have an etcd cluster setup, and thought it would be a great fit for ntfy storage when we need ntfy to be HA. unfortunately my golang foo is very limited, so this is only a RFE. Thanks for your consideration.

BreizhHardware

2026-05-07 00:21:08 +02:00

closed this issue
added the
enhancement

server
labels

BreizhHardware commented

2026-05-07 00:21:09 +02:00

Author

Owner

@mhameed commented on GitHub (Apr 29, 2022):

@mhameed commented on GitHub (Apr 29, 2022): ![NTFY_HA](https://user-images.githubusercontent.com/447017/165934595-07c360f4-72b6-4c4e-ad87-60725a329f2c.jpg)

BreizhHardware commented

2026-05-07 00:21:09 +02:00

Author

Owner

@binwiederhier commented on GitHub (Apr 29, 2022):

Hi @mhameed and thank you for the kind words. You're not the first to suggest an HA setup (though the first one to draw a picture). While my approach in ntfy is "fun driven development" and this sounds like a lot of fun, I also have to acknowledge that not everything that can be done should be done.

The target audience for ntfy is largely selfhosters, and I doubt that anyone will ever use ntfy for anything mission critical (though that'd be cool), so it arguably doesn't make a ton of sense to spend effort on HA. Even for ntfy.sh itself, people would probably be fine with a 5-10min downtime for maintenance.

As for the design itself, given that ntfy is SQLite-backed, I'd probably look into rqlite, which is etcd-but-relational (as they say in their "why" section: "Think etcd or Consul, but with relational data modelling also available.").

I'd love to hear why you'd want HA? What are you using ntfy for?

I'll also leave this open so that others can chime in.

@binwiederhier commented on GitHub (Apr 29, 2022): Hi @mhameed and thank you for the kind words. You're not the first to suggest an HA setup (though the first one to draw a picture). While my approach in ntfy is "fun driven development" and this sounds like a lot of fun, I also have to acknowledge that not everything that can be done should be done. The target audience for ntfy is largely selfhosters, and I doubt that anyone will ever use ntfy for anything mission critical (though that'd be cool), so it arguably doesn't make a ton of sense to spend effort on HA. Even for ntfy.sh itself, people would probably be fine with a 5-10min downtime for maintenance. As for the design itself, given that ntfy is SQLite-backed, I'd probably look into [rqlite](https://github.com/rqlite/rqlite), which is etcd-but-relational (as they say in their "why" section: "Think [etcd](https://github.com/coreos/etcd/) or [Consul](https://github.com/hashicorp/consul), but with relational data modelling also available."). I'd love to hear why you'd want HA? What are you using ntfy for? I'll also leave this open so that others can chime in.

BreizhHardware commented

2026-05-07 00:21:10 +02:00

Author

Owner

@mhameed commented on GitHub (Apr 29, 2022):

Hi @binwiederhier,

I'm Only using ntfy for my home lab/personal use at the moment, but only came across it less than a week ago :-) and its already proving useful to me and another friend.
Although I can see potential uses for it at my place of work, at a university.

but yes, I was thinking of self-hosters, such as myself/friends, and reliable message deliveribility.

I am thinking of ntfy as another way to enable communication for improving modular/pluggable automation.
The way I was thinking of ntfy, was as a way of a serverless webhook alternative.
Imagine a tiny script that checks for a new version of ntfy, when a new release is found, a message is sent.
A diffrent script on each machine type (arm, x86, etc), picks up the message, and acts on it by downloading and installing depending on the current machine type.
and there we are, event driven processing, but not using any other server functionality other than the default ntfy, and a cron job, no webhooks/http servers needed.
Can then also be integrated with home assistant etc.
Of course this is nothing new, just mimics amqp.
The reason why I suggested it, is because I already have an etcd cluster, and ntfy looks useful enough and lite weight enough, so it would be an easy addition, whereas having to look after a rabbitmq cluster, would be a relatively sizable thing.
I haven't come across rqlite, but thanks for pointing it out, looks very useful.

It is understandable if you consider this RFE out of scope.
Thanks for your time.

@mhameed commented on GitHub (Apr 29, 2022): Hi @binwiederhier, I'm Only using ntfy for my home lab/personal use at the moment, but only came across it less than a week ago :-) and its already proving useful to me and another friend. Although I can see potential uses for it at my place of work, at a university. but yes, I was thinking of self-hosters, such as myself/friends, and reliable message deliveribility. I am thinking of ntfy as another way to enable communication for improving modular/pluggable automation. The way I was thinking of ntfy, was as a way of a serverless webhook alternative. Imagine a tiny script that checks for a new version of ntfy, when a new release is found, a message is sent. A diffrent script on each machine type (arm, x86, etc), picks up the message, and acts on it by downloading and installing depending on the current machine type. and there we are, event driven processing, but not using any other server functionality other than the default ntfy, and a cron job, no webhooks/http servers needed. Can then also be integrated with home assistant etc. Of course this is nothing new, just mimics amqp. The reason why I suggested it, is because I already have an etcd cluster, and ntfy looks useful enough and lite weight enough, so it would be an easy addition, whereas having to look after a rabbitmq cluster, would be a relatively sizable thing. I haven't come across rqlite, but thanks for pointing it out, looks very useful. It is understandable if you consider this RFE out of scope. Thanks for your time.

BreizhHardware commented

2026-05-07 00:21:10 +02:00

Author

Owner

@binwiederhier commented on GitHub (May 4, 2022):

It is understandable if you consider this RFE out of scope.

As I said before, I love the idea, but I think the target audience doesn't need it, and even for ntfy.sh, HA is a little out of scope. It's definitely a "super cool idea", but I want to keep things simple as much as possible.

I'll close this ticket for now, but that doesn't mean it has to stay closed forever. If there are every any serious thoughts about clustering, I'll reopen it.

Thank you for your idea, and for your input. Keep them coming!!

@binwiederhier commented on GitHub (May 4, 2022): > It is understandable if you consider this RFE out of scope. As I said before, I love the idea, but I think the target audience doesn't need it, and even for ntfy.sh, HA is a little out of scope. It's definitely a "super cool idea", but I want to keep things simple as much as possible. I'll close this ticket for now, but that doesn't mean it has to stay closed forever. If there are every any serious thoughts about clustering, I'll reopen it. Thank you for your idea, and for your input. Keep them coming!!

BreizhHardware commented

2026-05-07 00:21:10 +02:00

Author

Owner

@DarkSpir commented on GitHub (Sep 5, 2024):

I hope this does not open the ticket again but I want to add my thoughts about this (because I asked myself if ntfy in HA is possible, too, and looked through the issues to figure out if somebody already asked for this).

I'm also a homelab user. I have a few Server VMs hosted at serviceprovider and one of them is running ntfy to use for Unified Push on my android phone (for example on my Mastodon client). I also have a docker container named dion installed on every server, dion periodically checks if a new version of an container image is available and if yes, it sends a notification to a service. In my case it pushes a notification through my ntfy instance to my phone. Since a few friends and my family are using my servers, too, I start thinking about including a health monitoring to my services and that would include pushing notifications in case something goes wrong. And of course I'd use ntfy for this. But here is the issue: ntfy is also one of the services that could fail and if it does (for whatever reason) I won't get notifications from my monitoring system. And same goes for the monitoring system itself, of course.

Usually there is a simple and a complicated solution for these kind of problems:

Have a separate monitoring- and notification system to monitor the main monitoring system and notify issues. Have the main monitoring system monitor the separate one.
Put the monitoring- and notification system on a HA cluster. If one node fails, the other one takes over the service and can raise an alert

And no, I have not figured out yet which of these two is the simple and which is the complicated solution for my homelab and in general. Both of them violate the KISS-rule obviously. I just want to point out that there could be usecases out there even for homelab users (especially when they work in IT) but I also agree to @binwiederhier when they said, that not everything that can be done should be done. Or as we germans say: "Warum einfach, wenn es auch kompliziert geht?" (why doing something the easy way, when it also can be done complicated?)

@DarkSpir commented on GitHub (Sep 5, 2024): I hope this does not open the ticket again but I want to add my thoughts about this (because I asked myself if ntfy in HA is possible, too, and looked through the issues to figure out if somebody already asked for this). I'm also a homelab user. I have a few Server VMs hosted at serviceprovider and one of them is running ntfy to use for Unified Push on my android phone (for example on my Mastodon client). I also have a docker container named dion installed on every server, dion periodically checks if a new version of an container image is available and if yes, it sends a notification to a service. In my case it pushes a notification through my ntfy instance to my phone. Since a few friends and my family are using my servers, too, I start thinking about including a health monitoring to my services and that would include pushing notifications in case something goes wrong. And of course I'd use ntfy for this. But here is the issue: ntfy is also one of the services that could fail and if it does (for whatever reason) I won't get notifications from my monitoring system. And same goes for the monitoring system itself, of course. Usually there is a simple and a complicated solution for these kind of problems: 1. Have a separate monitoring- and notification system to monitor the main monitoring system and notify issues. Have the main monitoring system monitor the separate one. 2. Put the monitoring- and notification system on a HA cluster. If one node fails, the other one takes over the service and can raise an alert And no, I have not figured out yet which of these two is the simple and which is the complicated solution for my homelab and in general. Both of them violate the KISS-rule obviously. I just want to point out that there could be usecases out there even for homelab users (especially when they work in IT) but I also agree to @binwiederhier when they said, that not everything that can be done should be done. Or as we germans say: "Warum einfach, wenn es auch kompliziert geht?" (why doing something the easy way, when it also can be done complicated?)