Notifiarr client: a Discord and notification layer for media servers

What the Notifiarr client watches

The repository describes itself as the unified client for Notifiarr.com, written in Go and Svelte, and working on most operating systems. The feature list is long, and reading it as a group explains the shape of the product: this is a notification and automation layer for a media server stack, not a media server itself.

The watched applications are visible in the feature list and in the dependency list. Plex appears repeatedly, with scheduled session notifications, finished-watching notifications, automated trash emptying, Tautulli user map integration and Plex watch history through the Tautulli integration. The *arr applications appear as Radarr collection gaps, TRaSH profile syncing into Radarr and Sonarr, MDBList and library syncing, and backup corruption checks for all starr applications. Download clients are supported too: the module file pulls in libraries for qBittorrent, Deluge, NZBGet, rTorrent and Transmission.

Two features are not notification related at all. Media requests can be made from Discord, and scripts and commands can be triggered from Discord. Those two turn the chat app into a remote control for the whole stack, which is the reason a lot of people end up running it.

The client also checks service and network health, and offloads scheduled website tasks. The dependencies confirm the mechanism: `github.com/go-co-op/gocron/v2` is the scheduler, `github.com/prometheus/client_golang` is there for metrics, `github.com/gorilla/websocket` and `github.com/gorilla/mux` for the web side, and `github.com/shirou/gopsutil/v4` for host information.

One Go binary with a Svelte interface built into it

The repository layout separates the two halves of the project. There is a `frontend/` directory, a `pkg/` directory for the Go packages, `main.go` at the root, and `init/` for start-up logic. The front end is a Svelte application whose built assets are served by the Go binary, which is the usual way a self-hosted web interface is shipped: one process, one port, no separate web server to install.

The Makefile shows how that build works. The `generate` target creates the front end output directory and then runs the Go generators:

mkdir -p ./frontend/dist
go generate ./frontend/src/api
go generate ./frontend

The full target also writes a placeholder into the output directory so that a developer build has something to serve:

echo "Fake frontend build." > ./frontend/dist/index.html

The API generator step is worth noting, because it means the TypeScript definitions for the client's HTTP API are generated from the Go side rather than written by hand. That keeps the two halves in step, and it also means the API surface is a generated artifact you can inspect in the repository rather than something you have to infer from documentation.

The `userscripts/` directory at the root points at the other side of the integration: browser-side scripts that a user can install to interact with the client, which is a common pattern when a service wants to add buttons to third party web pages without shipping a browser extension.

The scheduler behind snapshots, dashboards and URL polling

A large share of the feature list is scheduled work, and the scheduler is explicit in the dependencies: `github.com/go-co-op/gocron/v2` at version 2.22.0. The scheduled items listed are system snapshot notifications, media and downloads dashboard notifications, scheduled URL polling to custom notifications, and scheduled Plex sessions notifications.

The URL polling entry is the most general of these and the most useful to understand, because it turns the client into a generic poller: you give it a URL, it checks it on a schedule, and the result is delivered as a custom notification. That is a small feature that covers a large number of ad hoc monitoring needs, such as checking a page that changes when a backup job finishes, without wiring up a separate monitoring service.

The dashboard notifications are the other half of the story. A media and downloads dashboard delivered on a schedule gives a periodic snapshot of the stack, which is the difference between finding out about a stalled download immediately and finding out a week later.

The dependency list also shows where the client sits in the data path. It talks to the download clients over their own APIs, uses `github.com/nxadm/tail` to follow files as they grow, and `github.com/jaypipes/ghw` and `gopsutil` to describe the host machine. The host information matters for the system snapshot feature, since that notification presumably reports on the machine the client runs on.

Installing the client: the wiki, the examples, and the build

The README deliberately does not carry install steps. It says the project maintains a wiki with the install instructions, and points at https://notifiarr.wiki/pages/client/install/. The same pattern repeats for configuration at https://notifiarr.wiki/pages/client/configuration/ and for troubleshooting at https://notifiarr.wiki/pages/client/troubleshooting/. The README even notes that the configuration section that used to live in the repository is no longer relevant, and that the wiki holds it instead.

That is a documentation decision with consequences. Everything needed to run the client lives outside the repository, so an offline or mirrored copy of the source is not enough to install it, and a change to the wiki is not versioned with the code. If you are evaluating the project, read the wiki install page as part of the evaluation rather than as a later step.

The repository still carries runnable material under `examples/`. There is a `compose.yml` for a Docker deployment, a `notifiarr.conf.example` configuration file, a `prometheus.yml` for metrics scraping, a `dashboard.json` for a dashboard, and a `MANUAL.md`. The presence of a Prometheus example is the clearest signal that the client exposes metrics in the format Prometheus expects, which makes it usable from an existing monitoring stack rather than only through its own notifications.

Building from source is a Go build with a generated front end, and the Makefile handles both. The `all` target runs `clean`, `generate` and the binary target in order, and the `clean` target shows the range of release artefacts the project produces, including macOS, freebsd, linux and windows packages and their archives:

rm -f notifiarr notifiarr.*.{macos,freebsd,linux,exe}{,.gz,.zip} notifiarr.1{,.gz} notifiarr.rb

The module file requires Go 1.27.0, and the build flags include `-tags osusergo,netgo`, which is how the project gets a static binary with no cgo dependency.

MIT licence, GoReleaser Pro, and how releases are cut

The licence field on the repository says MIT, and the README spells it out as MIT with a copyright line for Go Lift, so use of the code in a self-hosted deployment is straightforward.

The release process has one wrinkle worth understanding before you fork or build internally. The first line of the Makefile says that releases are produced with GoReleaser Pro, with a pointer to `.github/workflows/README.md`. GoReleaser Pro is the commercial edition of the release tool, which means the automated release path in this repository depends on a licence that the open repository itself does not carry. The `.goreleaser.yaml` file in the root defines the artefact matrix, and the Makefile shows the packages it builds, including deb, rpm, txz and zst formats and a service file.

The version history gives the cadence. v0.9.7 was released on 2026-08-30, preceded by v0.9.5 on 2026-03-08 and v0.9.4 on 2026-02-25. The last push to the repository was on 2026-10-17, and the project is not archived. The version numbers are still below 1.0, which is a signal that interfaces, configuration keys and the HTTP API may still move between releases, so a long-lived deployment should pin its version and read the notes before each bump.

The `pkg/` directory is where the Go code lives, and the `golift.io/` dependencies that fill the module file are shared libraries for the individual services: `cnfg` and `cnfgfile` for configuration, `cache` for caching, `mulery` for the web interface, and one library per download client or starr application. Depending on shared libraries from the same author means the client picks up behaviour changes in those services indirectly, which is another reason to track upstream versions rather than only this repository.

Where the Notifiarr client is the wrong tool

The clearest wrong-tool case is a stack that does not use Discord. Every documented feature is a notification, a dashboard, a request or a command, and the channel for all of them is Discord. Health checks, Plex session alerts, backup corruption checks and scheduled snapshots are all described as Notifiarr notifications. If your team lives in Slack, email or a pager, this client does not meet you where you are, and the Prometheus example is the only route out of that box, since it exposes metrics rather than messages.

The second case is a media server that is not Plex plus the *arr applications. The integration list is specific. Tautulli, Radarr, Sonarr, MDBList, TRaSH, the Go Lift download client libraries, Deluge, qBittorrent, NZBGet, rTorrent and Transmission all appear, but nothing suggests a generic or pluggable adapter, and the feature list does not mention Jellyfin, Emby or a bare HTTP target beyond the URL polling item.

The third is a requirement to run without any connection to Notifiarr.com. The repository presents itself as the client for that service, and the documentation for installation and configuration lives in its wiki, but the README does not describe an offline mode or a local-only configuration. If the service were to be unavailable, or if your policy forbids depending on a hosted endpoint for internal alerts, you would need to establish that behaviour for yourself before relying on it.

The alternative approach, and the one many homeserver operators end up with, is a small set of per-application scripts wired directly into each service's own notification hooks, with a separate metrics pipeline for dashboards. The difference in approach is that Notifiarr centralises the routing in one binary with one configuration and one chat surface, while the script approach keeps every integration in the tool that owns it and needs a separate place to send the result. Notifiarr costs you a dependency on a hosted service and on Discord; the script approach costs you the duplication.

Editorial conclusion

Adopt the Notifiarr client if your household or team runs the *arr applications and Plex and already lives in Discord, because that is the channel every documented feature routes through. Do not adopt it as a general monitoring stack, since the health checks, dashboards and scheduled notifications are described as Notifiarr notifications rather than as a standalone pager. Verify two things before installing: that the wiki install page at notifiarr.wiki matches the version you are about to run, and that the GoReleaser Pro based release process does not block your own builds, since the Makefile states that releases are produced with GoReleaser Pro.

Frequently asked questions

Official sources

1. License: MIT
2. Notifiarr/notifiarr on GitHub
3. Project website
4. README
5. Releases