Your backup script finished at 3am. The log says success. You found out it failed when a client called because their site was down — not because anything pinged your phone. Email alerts go to spam. Discord webhooks get muted in a channel you never check. You need a pipe that actually reaches your pocket, on infrastructure you control.
Gotify is that pipe. ~15k GitHub stars, MIT-licensed, and a dead-simple push notification server — send messages via REST API, receive them in real time over WebSocket, read them in a clean web UI or the official Android app. One container, app tokens for each service, your alerts stop depending on a US push vendor.
What it actually does
Gotify is a self-hosted message broker for humans and scripts. Not email. Not a full chat platform. POST a message, it shows up everywhere you're subscribed.
REST API in, WebSocket out. Cron jobs, Uptime Kuma, n8n, backup scripts, home automation — anything that can HTTP POST sends to Gotify. Clients (web UI, Android app, custom integrations) listen on WebSocket and display messages instantly.
Applications and tokens. Create an "application" per source — monitoring, backups, homelab NAS — each gets its own token. Revoke one without rotating everything. Priority levels (1–10) so disk-full alerts look different from "deploy finished."
Web UI included. Browse message history, manage users, configure clients. No separate front-end project required.
Android app. Official client on Google Play and F-Droid — point it at your self-hosted URL, get push-style notifications without Firebase if you run it on your network (or with TLS on a public domain).
CLI and plugins. gotify/cli for shell one-liners. Plugin system for extending the server — check gotify.net docs for what's available.
Gotify vs Uptime Kuma vs ntfy
Easy to confuse the notification stack:
- Uptime Kuma — monitors URLs and ports; sends alerts to Gotify, Telegram, Discord, etc.
- Gotify — receives and displays messages; doesn't monitor anything itself
- ntfy — similar push-notification server (we haven't blogged it yet); Gotify has a longer track record and a bundled web UI
Typical homelab wiring: Kuma watches services → Gotify notifies your phone. Or n8n workflow completes → Gotify tells you. Gotify is the last mile, not the sensor.
Why self-host?
Alert content stays yours. "Database replication lag on client-prod-03" isn't a message you want on a third-party push relay with unclear retention. Self-hosted Gotify on a Canadian VPS keeps notification text and metadata on your disk.
No vendor sunset. Push services get acquired and killed. Gotify is MIT, self-hostable, and has been around long enough that homelab guides still reference it — because it keeps working.
One hub for many sources. Instead of fifteen different Discord bots and SMTP configs, centralize on Gotify and read one app. Uptime Kuma, changedetection, custom bash — all POST to the same server.
Lightweight. Single Go binary or Docker container, SQLite by default. Runs on the same box as your monitoring stack without a PostgreSQL cluster.
What running it takes
docker run -d -p 8080:80 \
-v ./gotify_data:/app/data \
-e GOTIFY_DEFAULTUSER_PASS='change-me' \
gotify/serverUI on port 80 inside the container — map to 8080 or put nginx in front with TLS. Back up /app/data — SQLite database, uploaded images, certs if you enable Let's Encrypt in Gotify config.
Change the default admin password immediately. Create an application token for each integration. Point Uptime Kuma's Gotify notification provider at your instance URL and token. Test with curl before you rely on it at 3am:
curl -X POST "https://gotify.yourdomain.ca/message?token=YOUR_APP_TOKEN" \
-F "title=Test" -F "message=It works" -F "priority=5"Multi-arch image — amd64, arm64, armv7, even riscv64. Raspberry Pi friendly for homelab alert hubs.
Who it's for (and who should skip it)
Good fit: homelabbers centralizing alerts, small teams wanting self-hosted push without Slack dependency, devs wiring CI/CD and cron output to a phone, anyone already running Uptime Kuma who wants a dedicated notification receiver.
Maybe skip it: you live in Slack/Teams and everyone reads those channels — Gotify adds a layer you won't use. You need full two-way chat — this is one-way push. You won't put TLS on a public URL — the Android app needs a reachable HTTPS endpoint for reliable mobile delivery.
Hosting it in Canada
Gotify is tiny — but alert delivery needs a stable URL and valid TLS for mobile clients. We run instances on Canadian Docker hosting with persistent volumes and reverse proxy in front.
Tell us what services will POST alerts — we'll wire the box and help you test end-to-end before the first real outage.
