Think of it more like a push notification server than a messaging platform. You would need a service that sends push notifications to Gotify topics. I get the sense that under the covers it works a lot like MQTT where you have apps publishing messages to topics, and you have consumers (in my case, iGotify app on iOS) that pull those messages off the topic and present them to the user as push notifications.

Though… I think I need a better iOS client than iGotify. It’s not actually giving me any push notifications so it’s missing the whole point for me.

Probably something here that you can use like that:

https://github.com/gotify/contrib

I use it with apprise and mailrise (email interface over apprise) typically. Apprise is basically a generic notification sender that can send push notifications to a bunch of different clients, including gotify.

So, things like Proxmox errors get set to a fake mailrise address -> apprise -> gotify. And a lot of Linux apps in general (especially older ones) only support email notifications, so this is quite useful. You can also use apprise directly, even as a commandline interface. So you can make scripts to notify you of problems in cases where there isn’t already proper logging and notification support.

And I’ve setup diun to give me notifications for docker version updates. In this case, diun sends notifications to gotify directly.

It is designed for one user, multi-channel push notifications. Like Firebase Messaging but self-hosted. You can use Markdown when composing the messages and do about whatever you want.

It’s got an open API so really there’s a lot more than my own use case.

I’m using it right now for getting notifications from flows in ActivePieces (I don’t want to get spammy with my site, which is the link in the original post, but there’s a how-to on getting that up and running also… ActivePieces is like a self-hosted Zapier)

For anything. You can get a push notification for anything you can make run a script or send an http request.