When you’re new to the self-hosting ecosystem, you’ll come across several FOSS utilities capable of replacing their premium, cloud-based mainstream equivalents. So many, in fact, that you’ll often have a hard time choosing the right application for your specific tasks. But once you’ve built an empire of locally-hosted utilities, you’ll come across services specifically designed to help you maintain your application stack.

Gotify is one such tool, but unlike Uptime Kuma, Homarr, Watchtower, and other maintenance-oriented compatriots, you’ll have to dig deep into the self-hosted rabbit hole. That’s kind of a shame, as Gotify is a neat addition to every home lab enthusiast’s setup.

What’s Gotify, anyway?

And how does it function?

In simple terms, Gotify is a notification server that pulls alerts from other applications and pushes them to its neat UI. Under the hood, Gotify relies on three components: clients, apps, and the (Gotify) server itself. Applications are the entities that can send messages to the Gotify server, and can range from self-hosted services to the virtualization platform(s) running them.

Meanwhile, clients are machines capable of managing the notifications generated by applications, though they can’t generate their own alerts. As such, any device you use to manage your Gotify server – smartphone or web UI – counts as a client, while the applications are essentially your self-hosted services(and other platforms) that communicate with the Gotify instance. Gotify acts as a bridge between the two, allowing your apps to push notifications and view said alerts on your client devices.

Deploying Gotify as a container

It’s pretty easy to set up

One of the perks of self-hosted apps is the sheer number of options at your disposal for running them on your server, and Gotify is no exception. My preferred method involves deploying Gotify inside Docker/Podman (or another container environment), and it’s as simple as launching the terminal and running the sudo docker run -p 80:80 -v /path_to_file:/app/data gotify/server command (or you could go the Podman route by removing sudo and replacing gotify/server with docker.io/gotify/server). Just remember to create a folder for the Gotify server and add its path instead of the /path_to_file variable.

If you’re on Proxmox, you can utilize the super-helpful Proxmox VE Helper-Scripts repository to bring a Gotify container to life. To do so, simply paste the bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/gotify.sh)" command into the Proxmox Shell, select the Default Options, and watch the script work its magic.

That said, I’d actually advise against hosting Gotify on your Proxmox home lab unless you’re using more than one node. That’s because your Gotify server will go offline if something happens to your Proxmox server, meaning you won’t receive any alerts about your broken home lab.

Dedicated NAS setups that run 24/7 are perfect for deploying a Gotify instance, with both TrueNAS Scale and Unraid supporting app templates for this neat utility. Likewise, most containerization platforms, be it UmbrelOS, CasaOS, Cosmos, or Yunohost, include a Gotify template to help you deploy the service in less time than it takes to finish reading this sentence.

Regardless of the method you’ve used to spin up Gotify, you’ll find a few options on the UI. The Applications tab is an important one, as that’s what you’ll use to keep track of the tokens used to connect to your self-hosted services.

How I combine Gotify with my setup

It’s the best companion for Uptime Kuma

Now that we’re done with the theory aspect and setup procedure for Gotify, I wanted to go over my current configuration. As an Uptime Kuma user, Gotify is my favorite companion app for the monitoring station. That’s because Uptime Kuma needs a notification service where it can send alerts in case my self-hosted stack becomes inoperational.

For a completely self-hosted setup, Gotify can act as the notification backend for Uptime Kuma – and it’s as simple as creating a new application on Gotify and copying the app token and the IP address of Gotify into Uptime Kuma.

TrueNAS Scale and Proxmox Backup also benefit from Gotify

Having experimented with several NAS distros and virtualization platforms over the years, I’ve settled on TrueNAS Scale for my storage server and Proxmox for my home lab. Luckily, both platforms pair well with Gotify.

Proxmox, for instance, supports Gotify by default. However, the option to link a Gotify server with Proxmox is hidden inside the Notifications menu of the Datacenter tab. Like Uptime Kuma, you can link the service with Proxmox by simply creating a new app inside Gotify and pasting its IP address and token under the Notification Targets section.

However, TrueNAS Scale requires a little bit of tinkering. I’ve used TrueNas Gotify Adapter to pair my NAS with the notification tool. This involves deploying a custom container featuring the Gotify Adapter inside TrueNAS Scale, where you’ll have to add the IP address of the Gotify instance alongside the app token. Then, you can use the Alerts Settings to link to this newly-created container with your TrueNAS Scale instance.

It can receive notifications from several other apps

Although I consider Gotify essential for Uptime Kuma, Proxmox, and TrueNAS Scale, it meshes well with tons of other services. On Home Assistant, you’ll find an integration to pair the smart home management to Gotify via HACS. Likewise, Jellyfin has a dedicated plugin that can push any alerts and notifications to a Gotify server. If you’re using Papra to manage your documents, you can use the webhook to alert Gotify whenever a new file is added to the server. Throw in the automation prowess of n8n, and you can even use Gotify with non-self-hosted apps, including Slack, Monday, AWS Lambda, and everything in between.