Remux: a Rust media server that speaks the Jellyfin API

One API, several kinds of source

The design decision that shapes the whole project is that the client side is not Remux. The server implements a Jellyfin compatible API, so Infuse, Swiftfin, Jellyfin for Android and any other Jellyfin compatible client work against it without changes, and the operator assembles the library behind that API from Stremio add-ons, local files, WebDAV servers or torrents, mixing them inside a single library. Torrents are handled as a first class source with streaming straight from them, so no separate download client is required and nothing has to be downloaded first. Which of those you point at is a configuration decision the operator makes, and the project says nothing about restricting them, which is worth thinking about before a container is exposed to a network.

A container for servers, a tray app for desktops

Two distribution paths cover most people. For a server, the documented Docker Compose service is short:

version: "3"
services:
  remux:
    image: ghcr.io/lostb1t/remux:latest # or nightly
    ports:
      - "3000:3000"
    volumes:
      - /remux/data:/data

The image is published to the GitHub container registry, the port mapping exposes 3000, and a single volume keeps the data directory, which is where the SQLite database in the environment example lives. The nightly tag is offered alongside latest, and the release list shows a nightly build tracked by version string, currently 0.36.1-nightly.20261015.gcdc2e521, published on 2026-10-15.

For a desktop, the project publishes installers for three platforms: an Apple Silicon build for macOS as a dmg, a Debian package for Linux on x86_64, and a zip for Windows on x86_64. The desktop application is a single install with no Docker and no terminal, and the server runs in the background as a tray app, so a machine that is not a server can still act as one.

Music is a separate pipeline, not a Stremio feature

Music is handled apart from the rest of the library. The documentation is explicit that music is not tied to Stremio and streams from its own sources, including remote ones, and that it has a dedicated pipeline. That separation matters in practice, because the streaming integrations that make video work well are built around catalogue and add-on behaviour that does not map cleanly onto music libraries, so a separate path avoids one compromise for the other. The rest of the feature set leans the other way: playback tracking with progress syncing across clients and a continue watching option, and a user management layer that can import users and their data from an existing Jellyfin server, which is the shortest path for someone moving over from a server they already run.

Probe data makes streamed files look like local ones

The detail that decides whether a Jellyfin client feels at home with Remux is probe data. For streamed content, audio and subtitle track selection is said to work out of the box, with the track metadata sourced from RemuxDB, so clients see the same experience as with local files rather than a bare stream with no track list. Without that metadata a client has nothing to show in its audio and subtitle menus, and the difference between a library that feels native and one that feels bolted on comes down to exactly this. The data source is a separate service the project depends on, and the documentation does not describe what happens to a library when that service is unreachable, so it is worth knowing before you rely on it.

Libraries are built by filtering, not by listing

Libraries are dynamic rather than static. They are built by filtering on tags, catalogues, popularity, release year and similar criteria, content can be excluded per user, and a library can be scoped to a specific audience, all without duplicating the underlying sources. For a household where several people watch different things, that is the difference between several copies of the same source list and one source list with rules on it. The same mechanism also raises a question the project does not answer: the filters are described in terms of catalogue metadata, and the interaction between an exclusion rule and a per-user library is not spelled out, so the behaviour is something to check with your own catalogue rather than assume.

Building from source with cargo-make and dioxus

Development needs a Rust toolchain plus two extra tools, and the project uses cargo-make as its task runner and the dioxus CLI for the web dashboard. The setup sequence given in the project documentation is:

cargo install --force cargo-make

cargo install dioxus-cli

cp .env.example .env

The Jellyfin web assets are built next, and then the development server is started:

cargo make jellyfin-web

cargo make dev

The environment file is small, and it tells you where the pieces live:

RUST_BACKTRACE = 0
WEB_PATH = "./jellyfin-web/dist"
DASHBOARD_PATH="./target/dx/remux-dashboard/debug/web/public"
DATABASE_URL = "sqlite://db.sqlite?mode=rwc"

The workspace is a Cargo workspace with resolver 3 and six members: remux-dashboard, remux-server, remux-macros, remux-sdks, remux-utils and remux-desktop, which matches the split between the server, the admin dashboard and the desktop shell. The repository also carries an AGENTS.md, a CLAUDE.md and a SECURITY.md, and release notes are generated from conventional commits with semantic release tooling.

AGPL, an AI policy, and thin documentation

The licence is AGPL-3.0, which for a server meant to run on a network is the part to read carefully before you deploy it, and no legal advice is offered here beyond that observation. The project is also unusually explicit about AI-assisted contributions. Using tools such as Copilot, Claude, ChatGPT or Cursor to generate code, draft tests, research the codebase or write documentation is allowed, but contributors have to understand what they submit, test it, communicate with maintainers as themselves, and disclose significant AI generated work in the pull request description. Pull requests that look AI generated without disclosure can be closed without review, and repeat offenders can be blocked.

The documentation itself is the other limitation. The project has a separate wiki for the guide pages, and the repository is thin on operational detail: how the desktop app discovers sources, how per-user exclusions resolve against catalogue filters, and what the upgrade path looks like between releases are all things the wiki has to answer. The project is moving quickly, with v0.36.1 on 2026-10-06, v0.37.0 on 2026-10-17 and the last push on 2026-10-20, so pinning a version rather than following the latest tag is a reasonable habit.

Editorial conclusion

Remux suits someone who already uses Jellyfin clients and wants one library across several source types without reconfiguring the apps on their television, phone or tablet, since the API compatibility is the point and the project names Infuse, Swiftfin and Jellyfin for Android as working clients. It is a poor fit if you want a server that only touches files you control, because the source list includes Stremio add-ons and torrents and the responsibility for what you configure sits with the operator, and it is a poor fit under a proprietary licence requirement, since the project is AGPL-3.0. Before deploying it, read the wiki for the configuration surface the repository does not cover, decide whether the container or the desktop build suits your setup, and check the release you pin, since v0.37.0 came out on 2026-10-17 with nightly builds published alongside it.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. lostb1t/remux on GitHub
3. Project website
4. README
5. Releases