gotify/server: a self-hosted push server for your own alerts

What gotify/server is for

gotify/server exists because the authors wanted a simple server for sending and receiving messages in real time over WebSocket, and, as the README puts it, most of the existing open source options were abandoned. A second requirement was self-hosting. The project is aimed at people who run their own infrastructure and do not want their notifications to pass through a commercial push provider.

The practical shape of that is an alert endpoint you own. An application in Gotify holds a token; anything that can make an HTTP request can post a message to that token, and any client connected to the server receives it. The README lists the moving parts: a REST API for sending, WebSocket for receiving, user, client and application management, plugins, a web UI in the ui directory, a separate CLI at gotify/cli, and an Android app at gotify/android distributed through Google Play and F-Droid.

The audience is narrow on purpose. This is not a general messaging platform and it does not try to be one. If your problem is "my backup script finished and I want to know about it on my phone without handing the payload to a third party", that is the shape of problem the project was built for.

The REST in, WebSocket out architecture

The data flow is one-directional and easy to reason about. A producer sends an HTTP request to the REST API using an application token. The server stores the message and pushes it to every client currently subscribed to that application over WebSocket. The web UI in ui/ is itself one of those clients, which is why the README calls the UI part of the same product rather than a separate dashboard.

The Go module path is github.com/gotify/server/v3, and go.mod shows the stack: gin for HTTP routing, gorilla/websocket for the socket layer, gorm with sqlite, mysql and postgres drivers for persistence, zerolog for logging, and zitadel/oidc/v3, which indicates OpenID Connect support for authentication. There is also a plugin package and a dependency on github.com/gotify/plugin-api v1.0.0, so extensions compile against a published API rather than internal code.

Two consequences follow from this design. First, delivery is push-oriented: if no client is connected when a message arrives, the message is persisted and the client sees it on reconnect, but the server is not a queue with acknowledgement semantics that the README documents. Second, the WebSocket model means the server holds a connection per active client, which is fine for a household or a small team and is a different scaling problem from a stateless HTTP service.

Installing gotify/server and sending a first message

The README does not inline install commands. It points to https://gotify.net/docs/install for installation and https://gotify.net/docs/config for configuration, so the canonical steps live on the documentation site rather than in the repository README. The repository does ship a docker/ directory and a gotify-server.env.example file, which tells you the intended deployment shape is a container configured through environment variables.

The README's versioning section points to the tags on the repository for available versions, and the releases listed include v3.1.0 and v3.0.0. Because the README gives no run command, the only install fact you can take from the repository itself is that a Docker image is published at gotify/server on Docker Hub, which the README badge links to. Confirm the exact image tag, port and data volume path against the install page before you deploy.

Once the server is up, open the web UI and log in with the credentials the documentation gives, then change them. From the UI, create an application, which produces a token. The README also points to gotify/cli for a command line sender, so you do not have to hand-roll HTTP calls in scripts. The REST API reference lives at https://gotify.net/api-docs, and that page is where the message endpoint, its parameters and the token parameter are specified.

Where gotify/server stops being the right tool

The honest limitation is delivery semantics. The README describes sending and receiving in real time per WebSocket, and it describes persistence through the database layer, but it does not document an acknowledgement protocol, retry policy, or guaranteed delivery to a device that is offline. If you are building something where a missed alert has real cost, that gap matters, and you should not infer guarantees the documentation does not state.

The second constraint is operational. You are running a server, a database and an upgrade path yourself. go.mod carries three database drivers, so the choice of sqlite versus mysql versus postgres is yours to make and to maintain. The README does not document a migration or rollback procedure for the database, and neither does the release list explain what changed between v2.9.1 and v3.0.0 beyond the version numbers.

Third, the project is deliberately small. There is no team or organisation model described in the README, no message history search described, and no multi-tenant story. If you need those, you are looking at a different category of product.

How it compares with ntfy

The obvious alternative in this space is ntfy, which also offers a self-hosted server with an HTTP publish endpoint and mobile clients. The difference in approach is in the client contract. Gotify's receiving side is WebSocket plus a web UI that acts as a client, and its mobile story is a dedicated Android app; the README lists no iOS client. ntfy is built around HTTP publish and subscribe semantics with a documented topic model, which changes how you reason about who receives what.

For a script that fires an alert at one person's phone, both work and the choice comes down to which client you actually run. For anything where you want the delivery path to be plain HTTP on both ends rather than a persistent socket, Gotify's WebSocket-first design is the thing you would be working against rather than with. The README's own framing is that Gotify is a simple server for real-time message passing, and that framing is accurate about where its centre of gravity sits.

Maintenance, licensing and upgrade cost

The repository is not archived. The last push was on 2026-09-09, and the most recent release listed is v3.1.0 from 2026-08-27, following v3.0.0 on 2026-07-18 and v2.9.1 on 2026-02-28. The major version bump from 2.x to 3.x is the maintenance fact that matters most for an operator: the Go module path is versioned as github.com/gotify/server/v3, so anyone building against the code rather than running the container is pinned to that major line.

Upgrade cost is mostly the database. Because gorm sits in front of sqlite, mysql or postgres, a version change that alters the schema is your problem to handle, and the README does not describe a migration tool. The Makefile shows the project's own checks (test-coverage, check-go, check-swagger), which is useful if you build from source but tells you nothing about in-place upgrades of a running instance.

On licensing, the README states the project is licensed under the MIT License and points to the LICENSE file. The repository metadata marks the licence as NOASSERTION, meaning the automated classification did not resolve it. That discrepancy is worth reading the LICENSE file to settle before you depend on the terms; this is a factual check, not legal advice.

Editorial conclusion

Adopt gotify/server if you control a host and want your own alert endpoint instead of a commercial push service: the Docker image, the REST API and the Android app cover the common case. Do not adopt it if you need delivery guarantees to offline clients, per-message audit history, or a managed service with an SLA, because the README describes neither. Verify first that the licence file in the repository matches the MIT statement in the README, and check which database driver you will run, since go.mod ships sqlite, mysql and postgres drivers.

Frequently asked questions

Official sources

1. gotify/server on GitHub
2. Issues
3. Project website
4. README
5. Releases