Gotify

Gotify is a lightweight, self-hosted server for sending and receiving push notifications in real time over WebSocket. It was created because most existing self-hosted push notification projects were abandoned or overly complex, and the maintainers wanted a simple alternative to relying on commercial or third-party push services (like Firebase Cloud Messaging) for personal and infrastructure alerting.

The server is written in Go on top of the Gin web framework, with GORM handling persistence across SQLite, PostgreSQL, or MySQL. Messages are created through a REST API scoped to per-application tokens, then fanned out over WebSocket to connected clients scoped to per-client tokens. A React and Material UI single-page app (in ui/) gives administrators a dashboard to manage users, applications, clients, and message history, and can be built into the same Go binary or run separately behind a reverse proxy.

Gotify is extensible through a native Go plugin system: plugins are compiled as shared-object files, loaded at runtime, and can hook into the message pipeline or expose their own configuration UI within the web dashboard. The project also maintains an official CLI (gotify/cli) and an Android app (gotify/android, distributed on Google Play and F-Droid), giving self-hosters a full notification stack without depending on any cloud vendor.

With over 15,000 GitHub stars, 70+ tagged releases, and continuous development activity, Gotify has become one of the most widely deployed self-hosted notification servers, commonly paired with monitoring stacks, home automation platforms, and CI/CD pipelines that need to reach a phone or desktop instantly.

What You Get

• A REST API for sending messages, authenticated per-application via scoped tokens
• Real-time WebSocket streaming so connected clients receive new messages instantly
• A React and Material UI web dashboard for managing applications, clients, users, and message history
• A native Go plugin system for extending server behavior with runtime-loaded, compiled plugins
• Support for SQLite, PostgreSQL, or MySQL as the persistence backend
• An official CLI and Android app for sending and receiving messages outside the web UI

Common Use Cases

• Wiring monitoring scripts, cron jobs, or CI pipelines to send instant failure alerts
• Pairing with home automation platforms to receive real-time smart-home alerts
• Replacing dependence on commercial push notification providers for personal projects
• Relaying custom webhook or script events (deployment finished, backup complete) to a phone or desktop
• Building custom Go plugins to bridge Gotify with other internal tools or notification channels

Under The Hood

Architecture Gotify follows a modular-monolith layered architecture: app.go is the single entry point that parses CLI arguments (serve/version/migrate-config) and wires together the config, database, router, and runner packages. The router package builds one gin.Engine, registering middleware (access logging, recovery, CORS, optional SSL redirect) and mounting the api, docs (swagger), and ui handlers. The api package holds one file per resource (application, client, message, user, session, tokens, oidc) and depends on a narrow database interface rather than talking to the ORM directly, with a dedicated stream sub-package handling WebSocket fan-out. The plugin package defines its own slim Database and Notifier interfaces so the plugin manager only depends on the slice of persistence and notification behavior it actually needs — a clean dependency-inversion boundary that every plugin loader and compatibility shim must honor if it changes. Configuration is parsed once at boot from environment variables and passed down explicitly instead of through globals. The plugin system, with dynamically loaded compiled plugins reacting to message events at runtime, is the one genuinely event-driven piece in an otherwise straightforward layered design.

Tech Stack The backend is Go on the Gin web framework, with GORM as the ORM layer supporting SQLite, PostgreSQL, and MySQL selectable purely through configuration. Real-time delivery uses gorilla/websocket, structured logging goes through zerolog, scheduled housekeeping uses a cron library, and authentication extends to OpenID Connect via a dedicated OIDC client library. The frontend is a Vite-powered React and TypeScript single-page app styled with Material UI and Emotion, with state managed through MobX, API calls via axios, and its own test suite. Build tooling is Make-driven with a comprehensive Makefile (build, test, lint, package, docs generation), golangci-lint with gofumpt/goimports formatting on the Go side, and yarn/eslint/prettier on the UI side. Deployment targets a single static Go binary or the official multi-architecture Docker image, with GitHub Actions running the full Go and JS test/lint/build pipeline and publishing releases to Docker Hub and GHCR on tagged pushes.

Code Quality Testing is extensive, with roughly a third of all Go files being test files, built on a suite-based testing pattern with shared fixtures for isolated temporary databases per test run. Error handling is explicit and consistent throughout: HTTP handlers propagate typed errors through a centralized error-handling middleware rather than swallowing failures, and errors are wrapped with context rather than passed through unadorned. The lint configuration enables a deliberate, non-default set of linters covering static analysis, resource-closing checks, and formatting consistency, enforced in CI on every push and pull request alongside a parallel lint/format/test pipeline for the TypeScript UI. This reads as a strictly linted, well-tested codebase with CI gating both halves of the stack.

What Makes It Unique Gotify’s most distinctive technical choice is its native compiled-plugin architecture: rather than webhooks or a scripting DSL, third-party extensions are compiled binary plugins loaded at runtime that can access a narrow persistence/notification interface and render their own settings UI inside the main dashboard, with example scaffolding plugins shipped in the repository as starting points. Combined with first-class OIDC support, database-agnostic persistence selectable purely via configuration, and an official CLI and mobile client maintained under the same project umbrella, Gotify covers ground that many single-purpose notification relays don’t attempt. It isn’t reinventing push-notification transport — WebSocket plus REST is a standard combination — and compiled-plugin-as-shared-object is a known if less common pattern with real portability tradeoffs across OS and toolchain versions, so this sits closer to well-executed standard architecture than genuinely novel technique.

Self-Hosting

Licensing Model MIT licensed — all features, including the plugin system, web UI, multi-database support, and OIDC authentication, are available in self-hosted deployments with no restrictions or license keys required.

Self-Hosting Restrictions None found — there are no ee/, enterprise/, or pro/ directories, no license-check code paths, and no feature flags gating functionality behind a paid tier.

Enterprise Features Not applicable — Gotify has no commercial or enterprise tier; it is a fully community-maintained open-source project.

License Key Required No — the binary and Docker image run with full functionality out of the box.