Gotify Alternatives

Similar projects and alternatives to Gotify

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a better Gotify alternative or higher similarity.

Suggest an alternative to Gotify

Reviews and mentions

Posts with mentions or reviews of Gotify. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2022-01-11.
  • ⟳ 1 apps added, 64 updated at
    35 projects | | 11 Jan 2022
    Gotify (version 2.3.1): A client for receiving push notifications
  • Show HN: A tool to send push notifications to your phone, written in Go
    16 projects | | 28 Dec 2021
    Hello Philipp, what benefits do you think make the app shine against something like Gotify? It looks like you have integrated with firebase. What else should I be looking for? The firebase path looks interesting for my 'toy' messages so save some battery life.

  • Simple Raspberry Pi Powered SMS Gateway
    5 projects | | 5 Dec 2021
    If you're on Android, there's Gotify [1]. You can self-host the server and install the app on either the Play Store, F-Droid, or just by downloading the APK.


  • Sending mobile push notifications to yourself
    2 projects | | 25 Nov 2021
  • a way to send short messages between devices?
    6 projects | | 24 Nov 2021
    Sounds like a good use for gotify
  • Google Play permitting alternative billing systems for users in South Korea
    2 projects | | 19 Nov 2021
    Restricting background apps by default is probably good. But Google didn't have to lock users in to their service to provide a good push notification system on Android.

    The correct solution here would have been a system-level, open source, provider-agnostic push notification API built into AOSP. The Web Push API is a great example of how a push API can be provider-agnostic: It makes sense that push notifications should be consolidated to one provider -- this way, your device only needs to maintain one 24/7 connection to a server which it receives all notifications from all apps through, rather than having each app run its own notification service in the background, killing your data and battery life. Push services, like Google's, work by providing an HTTP endpoint to apps that they deliver to their backend and can use to send notifications.

    The Web Push API also works by allowing a web page to request an HTTP endpoint to use for sending push notifications, but the returned endpoint can be for any provider. If you use Firefox, the domain will be; on Chrome, it's But each provider's endpoint uses the same standardized API, so the backend doesn't have to care what the URL is. And this isn't a security risk either, because everything sent through the push service is encrypted.

    This could have been done for Android, but that would have given Google much less control over the platform, so they decided to do it in a monopolistic way. This is one of the many ways Google aims to maintain their monopolistic control over "open source" Android. Another example is SafetyNet hardware-backed attestation.

    Projects like GrapheneOS are really interesting because they are finally providing a real, secure, de-Googled OS option, with excellent app compatibility due to sandboxed Play Services (which allows you to run Play Services without giving it root access to your device). But will we ever be able to fully decouple Google from Android? I'm not sure. I expect most users of custom ROMs to continue installing Play Services on top of them for a long time, if they want something as basic as push notifications to work.

    By the way, while I personally have qualms with Google, I believe users should have the choice to use Google apps, if they are comfortable with the inherit privacy risks. This is how the GrapheneOS developers approach it, as well. [1] My problem with Android is that it was not built to function without Play Services. Community projects that allow it to do so will always be a cat-and-mouse game with Google. I think sandboxed Play Services is the most sane solution to the problem of Play dependencies the community has come up with so far, but I think if we want real change to happen, we need to target app developers. Each developer has the choice of whether to include Google or not within their app. We just need to convince them that they don't need Google.

    Google owns `` and points developers towards using Play Services APIs wherever possible. Perhaps the community should create their own open-source alternatives to the most commonly used APIs (e.g. push notifications) and developer documentation that provides instructions on how to switch from Google (ideally making the transition as easy as possible by emulating the Google API syntax). It would probably be possible to offer an installable platform-agnostic push notification API that developers can use. Providers could be installed as separate apps. Google could be one such provider. Perhaps we could implement a Web Push compatible API, and reverse engineer Chrome's Firebase integration to implement it as an option from the get-go, hoping other providers show up over time. We could perhaps allow users to self-host their push service as well. Modify Gotify (, an open source self-hosted push server, to accept push notifications in the Web Push format.

    In the hacker circles it seems there's two groups of people: those who think Android is a lost cause because it will always be controlled by Google, and think Linux phones are the only real alternative, and those who believe we can actually "steal" Android back from Google and make it into a true open source project. I fall into the latter, but I think a lot more work still needs to be done.


    > We aren't against users using Google services but it doesn't belong integrated into the OS in an invasive way. GrapheneOS won't take the shortcut of simply bundling a very incomplete and poorly secured third party reimplementation of Google services into the OS. That wouldn't ever be something users could rely upon. It will also always be chasing a moving target while offering poorer security than the real thing if the focus is on simply getting things working without great care for doing it robustly and securely.

  • Überleben mit einem Handy ohne Google oder Apple
    1 project | | 5 Nov 2021
  • A simple server for sending and receiving messages in real-time per WebSocket.
    1 project | | 16 Oct 2021
    1 project | | 16 Oct 2021
  • Gotify/server: A simple server for sending and receiving messages in real-time
    4 projects | | 16 Oct 2021
  • How do you use Gotify?
    8 projects | | 25 Sep 2021
    I am a novice in the self-hosted apps world with no programming experience and recently discovered Gotify. I currently only have two services using Gotify notifications but I think there can be a lot more use cases for this.
  • Self-hosting all these services on two Raspberry Pi 4s!
    62 projects | | 14 Sep 2021
  • Help a beginner, what can you do with a home server/storage rack?
    18 projects | | 7 Sep 2021
    Push notifications + Android app - Gotify (
  • HTTP API to send notifications to mobile device?
    2 projects | | 3 Sep 2021
    Try hosting gotify
  • ⟳ 5 apps added, 66 updated at
    59 projects | | 8 Aug 2021
    Gotify 2.1.3: A client for receiving push notifications


Basic Gotify repo stats
3 days ago

gotify/server is an open source project licensed under GNU General Public License v3.0 or later which is an OSI approved license.

Less time debugging, more time building
Scout APM allows you to find and fix performance issues with no hassle. Now with error monitoring and external services monitoring, Scout is a developer's best friend when it comes to application development.
Find remote Go jobs at our new job board There are 5 new remote jobs listed recently.
Are you hiring? Post a new remote job listing for free.