Reiverr combines TMDB discovery and plugin-based playback in one UI

What Reiverr replaces: a request interface plus a media browser

Reiverr describes itself as an alternative to Overseerr. The repository description calls it a clean combined interface for Jellyfin, TMDB, Radarr and Sonarr, while the README states the aim as a single UI for interacting with TMDB, streaming content from various sources, and being an alternative to Overseerr.

The feature list backs that up. On the TMDB side Reiverr discovers trending movies and TV shows, produces personalised recommendations based on your TMDB ratings, lets you search, and shows details such as cast, crew, ratings and a trailer. On the playback side it exposes a plugin API so the same interface can pull media from external sources.

Two plugins ship in the box. The Jellyfin plugin reads from a Jellyfin server, and the torrent-stream plugin requires Jackett. That last dependency is the one to notice: it means the playback path can reach into the *arr indexer world, not just your own library.

Who this is for is a self-hosted media household or a small group running the Servarr stack, where the extra screen real estate on a television matters more than API purity.

Why 2.0 was rewritten with TVs in mind, and what that costs

The README is unusually direct about the state of the project. It says this project is still in early stages and that many features are still missing, being tested and changed. Then the 1.0 section explains the trade explicitly: the 2.0 line is a rewrite of the project with TVs in mind, it still lacks many features of the previous version, and if you want a more stable experience, or only care about the web app, you should look at the 1.0 branch.

That is the single most important adoption fact here. You are choosing between a moving rewrite optimised for television input and a stable branch that is not. The README also routes readers to the Reiverr Taskboard for planned features and known bugs, which is where you would check whether a missing piece is a bug or simply not built yet.

The repository layout shows how the rewrite is organised. There is a `src/` directory for the Svelte frontend, a `backend/` directory holding the NestJS service, a `tizen/` directory for the Samsung TV build, and generated API clients under `src/lib/apis/reiverr/`. The `package.json` scripts confirm the split: `build` runs the backend build and then a Vite production build into `backend/dist/dist`, so the compiled frontend is served by the backend rather than by a separate static host.

Installing with Docker is the recommended path, and it needs two volumes

The README calls Docker the easiest and recommended installation method and warns you to update the API keys and base URLs to match your setup. The CLI form publishes port 9494 and mounts two directories, config and plugins:

docker run -it --init \
  --name reiverr \
  --restart unless-stopped \
  -p 9494:9494 \
  -v /path/to/appdata/config:/config \
  -v /path/to/appdata/plugins:/plugins \
  ghcr.io/aleksilassila/reiverr:latest

The compose form is the one to copy if you want authentication set from the start, because it exposes two optional environment variables that the CLI example leaves out:

environment:
  - SECRET=your_secret_here
  - ADMIN_USERNAME=admin
  - ADMIN_PASSWORD=admin

The README explains what `SECRET` does in a comment in the compose file: it is used to sign JWT tokens for authentication, and if it is not set, sessions will not persist between server restarts. That is a real operational detail, so set a random string rather than leaving it empty.

The two volumes come straight from the Dockerfile, which creates `./config` and `./plugins` inside the image and symlinks them to `/config` and `/plugins`. Anything you drop into `/plugins` on the host appears in the plugins folder inside the container.

First run: an admin account appears from whatever you type

Account creation is unusual enough to spell out, because getting it wrong leaves you locked out or, worse, with an admin account named something you did not choose. The README says that to create the first user account you can log in with any credentials and an admin account will be created. Alternatively you can define the admin username and password using environment variables, as shown in the Docker Compose example. A new admin account is only created if there are no previous accounts with the same name.

That last clause is the catch. Once an account exists with a given name, the bootstrap path stops creating it, so if you log in casually first and then try to set `ADMIN_USERNAME` later to something else, the old account remains and the new one is not created.

After login, the README describes the rest of the setup. To get access to media playback you connect to plugins by adding media sources in the settings, and additional plugins can be installed by dropping them in the `/plugins` folder. To get the most out of Reiverr the README recommends also connecting to TMDB. For Jellyfin, the hint given is that the API key is located under Administration, Dashboard, Advanced, API Keys in the Jellyfin web UI.

Building from source needs two npm installs and a preview build

The source path is short but has a wrinkle that catches people: the frontend and the backend have separate dependency trees. The stated requirements are Node v18.14.0 or higher and NPM v9.3.1 or higher. The Dockerfile pins the runtime to `node:18-alpine` and installs with `npm i` at the root and `npm ci --prefix backend` in the backend, which matches the documented sequence:

npm install
npm install --prefix backend
npm run preview

`npm run preview` is not just a dev server. In `package.json` it expands to `npm run build && npm run --prefix backend start:prod`, so it performs a production build and then starts the compiled backend. Reiverr is then reachable on port 9494, the same port the Docker image publishes.

That is also why the compose example in the README mounts host directories at `/config` and `/plugins` rather than at a relative path: the image symlinks both to `/usr/src/app/config` and `/usr/src/app/plugins`, so the two mount points are interchangeable from outside the container.

The repository also carries a swagger-spec.json and the `openapi:codegen` script, which regenerates the TypeScript client at `src/lib/apis/reiverr/reiverr.generated.d.ts` from the backend spec. Useful if you are extending the backend, irrelevant if you only want to run the app.

Samsung TVs need a separate backend host and a manual Tizen build

A TV app cannot host its own server, and the README says so plainly: to use Reiverr on TVs you still need to host the backend server on a separate device, set up using the methods described earlier.

The app itself has to be built and installed by hand. There are plans to attempt getting the app into the official store, but until then the README describes installing Tizen Studio or the CLI tools from the official website, connecting Tizen Studio to the TV, and then running a build command. The published form is a chained sequence of `tizen.bat build-web`, `tizen.bat package` and `tizen.bat install`, wired together by `npm run build:tizen` and semicolons, with the paths pointing at `C:\tizen-studio\tools\ide\bin\tizen.bat` and the device identifier being the TV model number.

The README flags both path and device id as things to replace for your installation. Anyone deploying this to more than one television should expect to edit that command per device.

Platform reach beyond the browser is limited to what the roadmap lists as planned: Android TV and WebOS, a Windows desktop app and a macOS desktop app. There is also a `deploy:electron` script in `package.json`, which runs electron-builder for both x64 and arm64 macOS targets, but the README does not describe an Electron app as a supported release, so treat that script as groundwork rather than a shipping target.

AGPL-3.0 and the difference from a pure request tool

The licence is AGPL-3.0, which is the first thing to check if you intend to modify and host Reiverr rather than just run it. That is a licensing fact about the terms, not advice about your deployment; if the copyleft reach of the AGPL matters to your organisation, read the licence text before you build on it.

Reiverr documents a UI spanning TMDB discovery and plugin-based playback. Its built-in Jellyfin plugin provides playback from a Jellyfin server, while the torrent-stream plugin requires Jackett. The project therefore combines discovery and playback rather than presenting only a request interface.

The cost is that everything is coupled. A broken Jackett indexer shows up as a playback failure inside Reiverr rather than as a request that never arrives, and the plugin API means a broken third-party plugin can affect the app without anything in the Servarr stack changing. Maintenance: the repository is not archived and the last push was on 2026-10-14, but the newest tagged release is v2.2.0 from 2025-02-22, with v2.0.0-alpha.6 before it. The installation examples use the `latest` tag on ghcr.io.

Editorial conclusion

Consider Reiverr if you want a single TV-oriented interface for TMDB discovery and plugin-based playback, and if the AGPL-3.0 licence suits your deployment. Do not adopt it if you need a stable feature set, and do not skip the 1.0 branch check: the README says 2.0 lacks many 1.0 features. Verify first that your Jellyfin API key and TMDB credentials load in the settings, that a plugin you drop into `/plugins` actually registers, and, on Samsung TVs, that your `tizen.bat` paths and device identifier match your machine.

Frequently asked questions

Official sources

1. aleksilassila/reiverr on GitHub
2. Issues
3. License: AGPL-3.0
4. README
5. Releases