DI

Dim

Self-hosted media manager with automatic library scanning

Media Servers ★ 4.1k stars Medium setup GPL-2.0

Dim is a self-hosted media manager that automatically scans, identifies, and organizes your movies and TV shows. It transcodes media on demand and streams to a clean web interface.

Key features

  • Automatic media scanning
  • On-demand transcoding
  • Written in Rust
  • Clean web UI

Pros & cons

Strengths

  • Low resource usage
  • Single binary option

Trade-offs

  • Development pace varies
  • Fewer features than Jellyfin

Dim replaces

Last reviewed Sep 13, 2026 · 805 words

Check the commit graph before you install Dim. The project's catalogue entry says "development pace varies", and that is the polite version: Dim has had long quiet stretches, and a media server you cannot update against new ffmpeg builds, new codecs and new browser behaviour is a media server you will eventually replace. Everything good about Dim is real, a lean Rust single binary with automatic library scanning, on-demand transcoding and a clean interface, but Jellyfin is the safer pick for anyone who wants to set it up once and forget it.

What Dim does with a folder of films

Point Dim at a directory, tell it whether it holds films or television, and it scans, matches titles against online metadata, fetches posters and backdrops, and builds a browsable library. Playback streams to the web interface, transcoding with a bundled ffmpeg when the browser cannot play the file directly. State lives in a single SQLite database, which is why the catalogue lists it as needing about 512 MB and why backup is a matter of copying one file and a config directory.

That is roughly what Plex did in 2012 and what Jellyfin does today, so the question is what Dim adds. The answer is the implementation: Rust throughout, GPL-2.0, 4,118 stars, one binary or one container, no .NET runtime, no PHP, no JVM. Idle memory is genuinely low. For a small library on a low-power box, this is the appeal, and it is a legitimate one.

Running it takes one container

The dev image on GitHub Container Registry is the usual way in:

services:
  dim:
    image: ghcr.io/dusk-labs/dim:dev
    ports:
      - "8000:8000"
    volumes:
      - ./config:/opt/dim/config
      - /mnt/media:/media:ro
    restart: unless-stopped

Bring it up, open port 8000, create the first account, and add a library pointing at /media/films or wherever your files sit. Mount media read-only; Dim does not need to write to it and a media server should never be able to rename or delete your collection by accident. If you want hardware transcoding, you will need to pass through the GPU or VAAPI device and check whether the build you are running supports it, because acceleration support has been uneven across releases. On a modern Intel or AMD CPU, software transcoding of a single 1080p stream is fine; 4K HDR to a phone is not.

Where it falls short of Jellyfin

Client support is the largest gap. Jellyfin has official and community apps for Android, iOS, Apple TV, Android TV, Roku, Kodi, Samsung and LG televisions, plus the web player. Dim has the web player. Casting from a phone, watching on a television without a browser, and offline downloads are all outside its scope. There is an API, which is how the web interface talks to the server, but no ecosystem has grown on it.

Music, photos, books and live television are absent; Dim is films and series only. User management is basic. Subtitle handling and metadata correction tools are thinner. Plugin support does not exist. A household with a television and two phones will hit these limits in the first week. The Jellyfin vs Plex comparison lays out the two mature options; Emby is the third, and the media server category covers the rest.

Who should run Dim anyway

A Rust developer who wants a media server they can read and contribute to. A person with a small film collection on a single-board computer who watches only in a browser and wants the lightest possible service. Someone who likes the interface, which is clean, and is content to treat the project as an experiment. Those are real users, and Dim serves them. What it does not do is replace a working Jellyfin install for a family, and its development history means I would not build a viewing habit on it without a fallback.

If you want a low-resource server without the risk, Jellyfin on the same hardware is heavier at idle by a few hundred megabytes and otherwise fine on a 4 GB machine. That trade, a little RAM for a maintained project with clients everywhere, is the one most people should take.

What I'd do

Try Dim in the container above for a weekend if the Rust angle or the low footprint appeals to you, and see whether the web-only playback fits how you actually watch. Then run Jellyfin. Keep an eye on Dim's repository; if a sustained run of releases appears, it is worth a second look, because the architecture is sound and the hard parts, scanning, matching and transcoding, already work. Until then, treat it as a promising project rather than the service your household depends on.

Compare Dim

19 head-to-head comparisons.

Similar media servers apps