What Gotify Does That Paid Services Don’t
Push notifications are everywhere, but control over them is rare. Most notification services – Pushover, Pushbullet, even Ntfy’s cloud tier – sit on someone else’s server, subject to someone else’s uptime, pricing decisions, and data policies. Gotify flips that by putting a lightweight notification server on your own hardware, letting you send and receive real-time alerts from any app or script you write, with no subscription fees and no third-party routing.
The appeal goes beyond privacy. Gotify gives you a WebSocket-based API that any script, home automation tool, or server monitoring job can hit with a simple HTTP POST request. That means your cron job, your Docker health check, your Raspberry Pi temperature sensor – all of them can push a message to your phone the moment something needs attention.
Setup takes about fifteen minutes.
Prerequisites and What You’ll Need
Gotify runs as a single binary or inside a Docker container. Docker is the cleaner path for most home server setups because it handles dependencies, keeps the app isolated, and makes upgrades a one-line command. You’ll need a machine running Docker and Docker Compose – a home server, a VPS, or even a Raspberry Pi 4 running 64-bit Raspberry Pi OS will work. Gotify’s memory footprint is minimal, usually under 50MB at idle, so it won’t compete with heavier services.
You’ll also want a domain or local hostname pointed at your server if you plan to access Gotify from outside your home network. A reverse proxy like Nginx Proxy Manager or Caddy sitting in front of Gotify handles HTTPS termination cleanly. If you’re staying strictly local, a bare IP and port is enough to get started. The Gotify mobile app for Android is available on both Google Play and F-Droid, and there are third-party iOS clients that connect via the same API.
Before writing any config, create a directory for Gotify’s data. Something like /opt/gotify/data works well. Gotify stores its SQLite database and configuration inside that folder, so keeping it outside the container means your data survives container rebuilds.
Deploying Gotify with Docker Compose
Create a docker-compose.yml file inside your Gotify directory. The core configuration looks like this:
- image: gotify/server
- container_name: gotify
- ports: “8080:80” (map host port 8080 to container port 80)
- volumes: ./data:/app/data
- restart: unless-stopped
- environment: GOTIFY_DEFAULTUSER_PASS=changeme
Run docker compose up -d from that directory. Docker will pull the image and start the container. Navigate to http://your-server-ip:8080 in a browser 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 under the Users menu. From there, the web interface is sparse but functional – it shows incoming messages in real time, lets you create applications, and gives you tokens for the API.
Each application in Gotify gets its own token. An application here isn’t necessarily a full program – it’s more like a labeled channel. You might create one called “Server Alerts,” another called “Home Assistant,” and a third called “Backups.” When a message comes in, it arrives under the right label so you can tell at a glance what triggered it. To create one, go to Apps in the web UI, click the plus button, name it, and copy the token that appears.
Sending Your First Notification
With a token in hand, sending a notification is a single curl command:
curl -X POST “http://your-server-ip:8080/message?token=YOUR_APP_TOKEN” -F “title=Test Alert” -F “message=Gotify is working” -F “priority=5”
Priority runs from 1 to 10. The Gotify Android app uses the priority value to decide how urgently to surface the message – low priority messages arrive silently, while higher values trigger sound and vibration. Setting priority 1 for routine log summaries and priority 8 for disk space warnings is a sensible starting point. You can adjust these thresholds inside the app’s notification settings per priority range.
From here, the integration options open up fast. A bash script monitoring a backup job can POST to Gotify on failure. Home Assistant has a native Gotify integration under its notification platform, requiring only the server URL and token in configuration.yaml. Uptime Kuma, the self-hosted monitoring tool, lists Gotify as a notification provider directly in its alert settings. If you run Jellyseerr for media requests, keeping your notification stack self-hosted alongside it fits the same philosophy – alerts for new requests hitting your Gotify server rather than a third-party webhook.
Putting a Reverse Proxy in Front
Running Gotify over plain HTTP on a local port is fine for a home network, but reaching it remotely over HTTPS requires a reverse proxy. With Nginx Proxy Manager, you add a new proxy host, point the hostname at gotify.yourdomain.com, set the forwarding IP to your server’s local IP and port 8080, and enable the WebSocket support toggle. That last step matters – Gotify’s real-time message delivery depends on a persistent WebSocket connection, and without that toggle enabled in the proxy, the connection drops and messages won’t update live in the app or web UI.
Caddy handles this with less configuration. A basic Caddyfile entry of gotify.yourdomain.com { reverse_proxy localhost:8080 } handles HTTPS certificates automatically via Let’s Encrypt and passes WebSocket connections through without extra configuration. Either approach works; Caddy is simpler if you’re starting fresh, Nginx Proxy Manager is worth using if you’re already managing other services through it.
Once HTTPS is live, update your mobile app’s server URL to the new domain. The app will reconnect and maintain the WebSocket link in the background, delivering notifications even when the app is closed – as long as your server stays reachable. At that point, Gotify behaves like any push service, except the entire pipeline runs on hardware you own, and there’s no monthly bill waiting at the end of the month.
