Sportarr: a Sonarr-style PVR for sports events

The same idea as Sonarr, pointed at fixtures

The README positions Sportarr in one line: like Sonarr and Radarr, but for sports events. The mechanism behind that is a familiar one. It monitors sports leagues, searches your indexers for releases, and handles file renaming, organization and media server integration. The What It Does section expands that into six capabilities. It tracks events across all major sports, naming fighting sports, football, soccer, basketball and racing among them. It searches Usenet and torrent indexers automatically and upgrades quality when better releases appear. It organizes files with customizable naming schemes, including multi-part events for fighting sports, which is the part with no equivalent in the film and television apps, since a numbered fight card is several files rather than one. It integrates with Plex, Jellyfin and Emby through dedicated metadata agents. It records live events from IPTV sources with automatic scheduling, which is labelled alpha. And it fetches subtitles through Bazarr or Bazarr+ and notifies through Discord, ntfy, Apprise, webhooks or custom scripts.

Running it in Docker, and what the volume layout does

The Quick Start is a compose file, and it is short enough to read as the deployment guide:

version: "3.8"
services:
  sportarr:
    image: sportarr/sportarr:latest
    container_name: sportarr
    environment:
      - PUID=99
      - PGID=100
      - UMASK=022
      - TZ=America/New_York
    volumes:
      - /path/to/sportarr/config:/config
      - /path/to/data:/data
    ports:
      - 1867:1867
    restart: unless-stopped

The two volumes have distinct jobs. The config volume holds the application configuration, and the data volume is where the media library is mounted, so a sports library can live on a NAS and be shared with the media servers. The PUID, PGID and UMASK settings are the usual mechanism for making the container's file ownership match the host's, and the port is 1867, which the compose file in the repository annotates as the Sportarr default port. After starting, you open http://your-server-ip:1867 and follow the Initial Setup guide. The repository's own docker-compose.yml uses a variable for the image, ${DOCKER_USERNAME:-sportarr}/sportarr:${TAG:-latest}, and there are example files for Docker secrets and for a non-Docker path. Native builds for Windows, macOS and Linux are on the releases page, and Sportarr is listed in the TrueNAS SCALE, HexOS and Unraid app catalogs.

SQLite by default, and the one-way door to PostgreSQL

The compose file carries a warning that is worth reading before you deploy anything. Sportarr uses SQLite by default and nothing below is required, but PostgreSQL support is for fresh installs only, because there is no SQLite to PostgreSQL migration path, and the README's Database section is referenced for the full list of variables, the FILE__ secrets convention and backup notes. The commented block shows the shape of that configuration, with a Sportarr__Database__Provider setting and the host, port, name, username and password keys following it, and a matching postgres:16-alpine service defined below it. The unprefixed keys in the shipped compose file are the readymade version of the same thing, and docker-compose.example.yml does the same setup using Docker secrets instead of a plaintext password. The practical consequence is that the database decision has to be made on day one. Adding PostgreSQL later to an installation that already has a library of metadata and history is not something the project supports, so treat the default as a decision rather than a starting point you will certainly outgrow.

The integration surface is the actual feature list

The documentation wiki is where the depth is, and the Integrations page names the pieces you connect. There is Prowlarr for indexers, Bazarr and Bazarr+ for subtitles, Maintainerr, Homepage, autobrr and the media server agents. That list tells you the shape of the system: Sportarr is the application layer of a stack you already run, not a replacement for it, and the indexer search is expected to run through Prowlarr. There is also an Application API for tools that need to drive Sportarr, a live metadata API explorer for poking at the endpoints, a page on building from source, a dedicated page on IPTV DVR recording, and a troubleshooting page. The notification options are the same flexibility you would expect from the wider ecosystem, with Discord, ntfy, Apprise, webhooks or custom scripts, and the subtitle path goes through Bazarr rather than being built in. The net effect is that the quality of the setup depends more on the quality of the surrounding stack than on Sportarr's own defaults.

IPTV recording, and why it is marked alpha

The newest and least settled feature is recording live events from IPTV sources with automatic scheduling, and the README is explicit that it is alpha. The wiki has a dedicated page for it, and the topics list includes iptv alongside pvr and dvr. This is the feature that most distinguishes Sportarr from the wider *arr ecosystem, since the other applications deal with libraries of files that already exist while this one is about capturing a broadcast as it happens. It is also the feature that carries the most uncertainty, since recording a live source involves timing, stream reliability and rights that the file-based applications never have to think about. The distinction is worth holding onto when reading the rest of the feature list: the indexer search and quality upgrade behaviour borrows proven ideas from Sonarr and Radarr, while the DVR side is new ground.

Where this is the wrong tool

Three limits are structural. The first is scale. The whole design assumes a growing library, with quality upgrades, renaming schemes and multi-part events, and it assumes you want an automated pipeline that keeps a collection current rather than a one-off way to watch a fixture that is on tonight. For someone who wants a single match recorded and watched, an IPTV player or a DVR box does the job with far less configuration. The second is that Sportarr assumes you already run, or are willing to run, the surrounding *arr stack, since Prowlarr, Bazarr, Maintainerr, autobrr and the media server agents are the documented integration points, and the notification options are drawn from the same ecosystem. Third, the alpha marker on IPTV recording means the feature most likely to matter for live sport is the one with the least stability guarantee. And underneath all of it is the operational fact that the tool exists to fetch content from Usenet and torrent indexers, so the legal and practical questions about the indexers you point it at are yours to answer, and the project offers no guidance on that.

Where the project stands, and the shape of the codebase

The release history shows a busy project. The newest tag is a development build from 2026-10-20, the latest release is v4.1.10.1120 from 2026-10-17 and before that v4.1.9.1119 from 2026-09-27, with the last push to the repository on 2026-10-20. The version string carrying both a semver and a build number in the same field is characteristic of the *arr family, which treats each build as a shippable artefact. The repository layout is the same shape, with a src/ directory, a frontend/ directory, a Sportarr.sln solution, an installer/ directory, a tests/ directory, an assets/ directory and an agents/ directory for the media server metadata agents. The Dockerfile shows the build and runtime split: the image is a runtime stage only on the .NET 8 ASP.NET base, with no build stages, because the application is expected to arrive as pre-built binaries from CI, and it also installs hardware acceleration drivers for Intel QSV, AMD and Intel VAAPI and NVIDIA NVENC, with a host runtime required and the Intel packages installed only on amd64. The image publishes amd64 and arm64. The licence is GPL-3.0, and funding runs through Open Collective, Ko-fi and Bitcoin.

Editorial conclusion

Sportarr suits someone already running the *arr stack who wants their sports library handled the same way as films and series, with the same indexer search, the same renaming and the same media server agents, and the fact that it reuses that ecosystem's conventions is the main argument for it. It is the wrong tool if you only watch a handful of live fixtures, because the whole design is around a growing library rather than a single recording. It is also the wrong tool if you need the IPTV recorder today, since recording live events from IPTV sources with automatic scheduling is marked alpha. Verify first which of your indexers and media servers you want connected, because those are the integrations that make or break the setup, and note that the newest release is v4.1.10.1120 from 2026-10-17 with development builds tagged daily.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. Sportarr/Sportarr on GitHub