Goodbye Discord webhooks, hello Gotify
Home<br>Post<br>Projects<br>Search<br>Cats<br>Tags<br>Rss
Previous post<br>Next post<br>Back to top<br>Share post
1. What Gotify actually does<br>2. My setup<br>3. Create a dedicated user and directories<br>4. Install the required tools<br>5. Download and verify Gotify<br>6. Prepare the first administrator account<br>7. Configure Gotify 3<br>8. Run Gotify with systemd<br>9. Put Nginx in front of Gotify<br>10. First login<br>11. Create a test application<br>12. Connect the Android application<br>13. Connect Uptime Kuma<br>14. Use a separate application for every service<br>15. Add Gotify to a shell script<br>16. Hack Hub notifications<br>17. Pick priorities that mean something<br>18. Do not turn Gotify into another source of noise<br>19. Logs and basic checks<br>20. Review the systemd sandbox<br>21. Back up Gotify<br>22. Update the standalone binary<br>23. Removing the standalone installation<br>24. Was it worth it?
For a long time I used Discord webhooks for notifications from my services. It was easy, it worked and almost every application knew how to send something to Discord. Create a private channel, copy a webhook URL, paste it into a service and wait until something breaks. Very advanced engineering.
The more services I added, however, the stranger it started to feel. My own servers were sending operational information to a third-party chat platform only so the same platform could send it back to my phone.
Discord was not doing anything wrong here. I was simply using a communication platform as my private monitoring inbox because it was convenient.
If you are a regular reader, you probably already know what happened next. I found a self-hosted alternative and created more work for myself in the name of independence.
This time the solution is Gotify.
Gotify is a small self-hosted server for sending and receiving real-time notifications. It has a WebUI, an Android application, a REST API and native support in many self-hosted tools. When native support is missing, sending a message still requires only one HTTP request.
I have connected it to my Uptime Kuma instance, so availability and recovery alerts now arrive through my own notification server. I also added Gotify notifications to HackHub.fyi for administrative events such as registrations, submissions, update suggestions, reports and contact messages.
No Discord server, no private notification channel and no webhook controlled by another company. Just my service talking to my other service.
As nature intended.
What Gotify actually does<br>The model is simple.
A Gotify user owns clients and applications. A client receives and manages messages. An application sends messages and receives its own application token.
A server, script or website sends an HTTPS request using that token. Gotify stores the message and delivers it to connected clients through WebSockets.
Website, server or script<br>| HTTPS request with an application token<br>Gotify server<br>+---- WebUI<br>+---- Android application
There are no channels to create and no bot account to invite.
I can create an application called Uptime Kuma and use its token only in Uptime Kuma. Another application can be called Hack Hub and receive a different token. A third one can be used by a backup script or a VPS health checker.
This separation matters. If one token leaks, I rotate only that application token instead of replacing one universal secret in every service I own.
Gotify 3 also changed token handling. Application and client tokens are exposed only when they are created or rotated. Save a new token immediately. Closing the window and expecting it to remain visible later will provide a practical lesson about token rotation.
My setup<br>I installed Gotify 3.0.0 on a small Debian VPS which already runs Nginx and Uptime Kuma.
Gotify listens only on localhost. Nginx handles the public HTTPS connection and proxies traffic to the local Gotify service.
Internet<br>Nginx on ports 80 and 443<br>Gotify on 127.0.0.1:2586
The examples use:
notify.example.com
Replace that domain everywhere with your own.
I use SQLite because this is a private notification server for a small number of applications. The database and uploaded application images live under /var/lib/gotify.
Gotify supports Docker and the official container images are probably the easiest route when the rest of a server already uses Docker Compose. My monitoring VPS did not use Docker. Installing Docker, containerd, extra networking and the rest of the machinery only to run one small Go binary felt like using a forklift to move a coffee cup.
I therefore installed the official standalone binary and created a hardened systemd service.
This article uses Gotify 3.0.0, released on July 18, 2026. Check the Gotify releases before installing because the current version may have changed by the time you read this.
Gotify 3 uses a new environment-based configuration format and the server binary now supports commands such as serve, version and migrate-config. A configuration written for Gotify 2 should not...