Set Up Gotify as a Self-Hosted Notification Server

Push Notifications Without the Middleman

Every major notification service – Pushover, Pushbullet, Firebase – routes your alerts through a third-party server you don’t control. Gotify changes that. It’s a lightweight, open-source notification server you run on your own hardware, giving you real-time push alerts for scripts, monitoring tools, and home automation without handing your data to anyone.

What Gotify Actually Does and Why It Matters

Gotify operates on a simple client-server model. You run the server on a machine you own, create applications within the Gotify dashboard, and each application gets a token. Anything that can make an HTTP POST request – a bash script, a cron job, a Python application, a home assistant workflow – can send a message to your Gotify server using that token. The Gotify Android app (available on F-Droid and GitHub) connects to your server directly and receives those messages in real time over a WebSocket connection.

The server is a single Go binary. There’s no Node.js runtime to babysit, no dependency tree to untangle, no database server to configure separately. Gotify uses SQLite by default, which means setup takes minutes rather than an afternoon. The web UI is clean and functional – you can read messages there, manage applications, create user accounts, and configure plugins, all from a browser without touching a config file after the initial setup.

One detail that surprises new users: Gotify distinguishes between “applications” and “clients.” Applications are the senders – your scripts, your monitoring tools. Clients are the receivers – the Android app, a web browser session, any consumer of the WebSocket stream. This separation matters when you want fine-grained control over who receives what. A single Gotify server can handle notifications for an entire homelab, with different applications sending alerts to different users.

Gotify also supports message priorities. Send a routine backup completion notice at priority 1 and a disk-full warning at priority 8, and the Android app can treat them differently – silent for low priority, heads-up notification for high priority. That kind of control is exactly what disappears when you rely on a free tier from a commercial notification provider.

Setting Up Gotify With Docker

Docker is the fastest path to a running Gotify instance. Before starting, make sure Docker and Docker Compose are installed on your server. You’ll also want a domain or subdomain pointed at your server’s IP if you plan to access Gotify outside your local network – SSL makes the Android app work reliably, and a reverse proxy like Nginx Proxy Manager or Caddy handles that cleanly.

Create a directory for Gotify and a docker-compose.yml file inside it. A working compose configuration looks like this:

version: "3"
services:
  gotify:
    image: gotify/server
    container_name: gotify
    ports:
      - "8080:80"
    volumes:
      - ./gotify-data:/app/data
    environment:
      - GOTIFY_DEFAULTUSER_PASS=changethispassword
    restart: unless-stopped

Run docker compose up -d and Gotify starts listening on port 8080. Open a browser, navigate to your server’s IP on that port, and log in with the username admin and whatever password you set in the environment variable. The first thing to do after logging in is change that password in the user settings and create a dedicated non-admin account for everyday use. Running day-to-day operations under the admin account is unnecessary and easy to avoid.

Once you’re logged in, go to the Apps tab and create your first application. Give it a name that reflects what will be sending messages – “Backup Scripts,” “Uptime Monitor,” “Home Assistant” – and Gotify generates a token. That token is all a sender needs. A curl command shows the whole flow immediately:

curl -X POST "https://your.gotify.domain/message?token=YOUR_APP_TOKEN" \
  -F "title=Test Alert" \
  -F "message=Gotify is working." \
  -F "priority=5"

If the message appears in the Gotify web UI within seconds, the server is working. Now install the Gotify app on Android, point it at your server URL, log in with your non-admin account, and that same message should already be sitting there. Future messages arrive as push notifications. The WebSocket connection the app maintains is persistent – there’s no polling delay, and no dependency on Google’s FCM infrastructure if you install the app via F-Droid rather than the Play Store.

Putting Gotify to Work

The real value of Gotify shows up when you wire it into things that are already running. A simple bash function dropped into /etc/profile.d/ or sourced in your scripts can send a Gotify notification with one line. Cron jobs that previously ran silently – or emailed a root account nobody checks – can push a message directly to your phone when they succeed or fail. If you’re already running a self-hosted web monitor like Changedetection.io, it supports custom notification URLs out of the box, and Gotify’s HTTP endpoint fits right into that field.

Gotify’s plugin system extends the server’s capabilities. The plugin API is documented and open, though the ecosystem is smaller than commercial alternatives. For most homelab use cases – server health alerts, backup confirmations, smart home triggers – the core HTTP API covers everything without needing a single plugin.

One limitation worth knowing before you commit: there is no official iOS client, and the project’s maintainers have stated that delivering persistent WebSocket notifications on iOS without Apple Push Notification Service involvement is not something they plan to solve. If your household mixes Android and iPhone users, Gotify handles one side of that cleanly and leaves the other out entirely.