// the find
gotify/server
A simple server for sending and receiving messages in real-time per WebSocket. (Includes a sleek web-ui)
Gotify is a self-hosted push notification server — you deploy it, send messages via a simple REST API, and receive them in real-time over WebSocket. It ships with a React web UI, an Android app, and a plugin system. The target user is anyone who wants self-hosted push notifications without handing data to a third-party service.
1. The scope is deliberately narrow and the API surface reflects that — send a message, receive a message, done. No feature creep. 2. The plugin system uses Go's native plugin loading (`.so` files), which is a real extensibility point rather than a config-file hack. 3. OIDC support is built in and tested against both Authelia and Dex, so it actually works in homelab SSO setups rather than being theoretical. 4. Test coverage is solid — every `api/` handler has a corresponding `_test.go` and the database layer tests run against a real DB, not mocks.
1. Go's native plugin system requires plugin and server to be compiled with the exact same Go version and module versions — a plugin compiled against an older gotify release will silently crash at load time, which makes the ecosystem fragile in practice. 2. Messages are stored forever by default with no TTL or retention policy built in; high-volume use cases will quietly bloat the SQLite/PostgreSQL database until something breaks. 3. No end-to-end encryption — messages travel plaintext between server and clients unless you put TLS in front of it, and even then the server itself can read everything, which undercuts the privacy angle. 4. The Android app requires Google Play Services for real-time delivery on most devices (F-Droid build uses polling instead), so the 'no third party' story breaks on the most common mobile platform unless users know to configure the F-Droid variant correctly.