MediaManager

Self-hosted media management, honestly reviewed. No marketing fluff, just what you get when you swap six config files for one.

TL;DR

• What it is: Open-source (AGPL-3.0) media management system — a single interface to replace the fragmented “Arr” stack (Sonarr, Radarr, Prowlarr) for managing your TV and movie library [README].
• Who it’s for: Self-hosters already running or planning a media server who are tired of maintaining half a dozen separate apps, each with its own UI, database, and configuration [README].
• Cost savings: The Arr stack itself is free, but the operational overhead of maintaining 4–6 separate services is real. MediaManager trades that complexity for a single Docker Compose file. No SaaS pricing to compare — there’s no cloud version [README].
• Key strength: Unified management of TV shows and movies with TMDB/TVDB metadata, OAuth/OIDC authentication, and a clean modern interface — all in one container stack [README].
• Key weakness: The project is young (3,144 stars, 72 forks as of this review), has a small contributor base (29 contributors), and no meaningful third-party reviews exist yet. You’re betting on an active solo maintainer with sponsor backing, not a battle-tested community product.

---

What is MediaManager

MediaManager is a self-hosted media management application written in Python (backend) and Svelte (frontend). Its positioning, from the README, is direct: “the modern, easy-to-use successor to the fragmented ‘Arr’ stack” [README]. That framing tells you exactly who it’s for and what problem it’s solving.

The “Arr” stack is the collection of apps most media homelabbers end up running: Sonarr for TV shows, Radarr for movies, Prowlarr or Jackett for indexer management, sometimes Lidarr for music, and Readarr for books. Each has its own web UI, its own SQLite or PostgreSQL database, its own port, its own update cycle, its own breaking changes. It works, but running four separate applications to do what is conceptually one job — find, download, and organize your media library — is a maintenance tax that compounds over time [README].

MediaManager’s bet is that you can collapse TV and movie management into a single interface backed by TVDB and TMDB for metadata. It’s a Python/Svelte stack, deployed via Docker Compose, with OAuth/OIDC authentication baked in from the start (something the Arr stack notoriously tacked on later or left to reverse proxy config) [README].

The project is maintained by Maximilian Dorninger, sponsored by DigitalOcean, and has attracted a modest but real community of sponsors including named individuals on GitHub and BuyMeACoffee. Twenty-six releases have shipped as of this writing. The pace is real [GitHub].

---

Why people choose it

There are no third-party reviews of MediaManager available at the time of this writing — the project is too young and too niche to have landed on Trustpilot, G2, or the major tech-review sites. What follows is based on the project’s stated design goals and the well-documented pain points of the Arr stack that motivated it.

The operational complexity problem. Running Sonarr + Radarr + Prowlarr means three separate web UIs to bookmark, three separate authentication setups, three separate backup jobs, three separate upgrade paths. When Docker Compose updates break something, you’re debugging three services. When you want to add a new team member or spouse to the household media setup, you’re creating accounts in three places. MediaManager’s value proposition is not that it does more than the Arr stack — it’s that it does the same core job with one service to manage [README].

The authentication problem. The Arr apps were not designed with OAuth in mind. Getting SSO working with Sonarr typically means routing through Authelia or Authentik as a middleware layer at the reverse proxy level. MediaManager ships OAuth/OIDC as a first-class feature, meaning your Google, GitHub, or corporate identity provider works out of the box without a separate authentication proxy [README]. For a household that uses Google accounts or a homelab running Authentik centrally, this is a real quality-of-life improvement.

The metadata story. Supporting both TVDB and TMDB gives MediaManager flexibility that individual Arr apps don’t all share cleanly. Sonarr defaults to TVDB; Radarr uses TMDB. If your library has both shows and movies, you’re already dealing with two metadata sources managed separately. MediaManager handles both in one place [README].

The greenfield advantage. The Arr stack carries years of accumulated technical debt and UI decisions that made sense in 2012 but feel dated now. MediaManager’s Svelte frontend and Python backend (with Alembic for database migrations) are built on modern tooling from the start. The screenshots in the README show a substantially cleaner interface than Sonarr or Radarr’s current UIs [GitHub screenshots].

---

Features

Based on the README and repository structure [README][GitHub]:

Core management:

• TV show and movie discovery, tracking, and library management
• TVDB and TMDB metadata integration for both content types
• REST API for programmatic access and third-party integrations
• Docker Compose deployment as the primary and documented install path
• Alembic database migrations (PostgreSQL-backed, with proper migration tooling)

Authentication:

• OAuth/OIDC support — connect to Google, GitHub, Authentik, Keycloak, or any compliant provider
• No third-party auth proxy required at the application level

Deployment:

• Single Docker Compose file for the full stack
• Separate dev and production compose configs
• MkDocs-based documentation at maxdorninger.github.io/MediaManager
• Configuration via TOML file (config.toml)

Development:

• Python backend with uv for dependency management
• Svelte/TypeScript frontend
• Makefile for common development tasks
• Contributing guide and code of conduct in place
• 26 releases shipped, indicating active maintenance

What it explicitly doesn’t cover:

• Music (Lidarr’s domain)
• Books/comics (Readarr’s domain)
• Indexer management (you still need Prowlarr or similar)
• Media playback (you still need Jellyfin, Plex, or Emby)
• Torrent or Usenet client management (qBittorrent, SABnzbd remain separate)

This is important to set expectations correctly. MediaManager handles the management layer — finding what you want, tracking your library, pulling metadata — not the full pipeline. You’re consolidating two services (Sonarr + Radarr) into one, not replacing the entire stack.

---

Pricing: SaaS vs self-hosted math

There is no SaaS version of MediaManager. It is purely self-hosted [README].

MediaManager: $0 software cost. You provide a VPS or home server.

Typical hosting cost:

• Minimum viable: $5–6/mo Hetzner or Contabo VPS (shared with other services)
• Comfortable: $10–15/mo if running dedicated alongside a media server

Comparison baseline — what you’re replacing:

• Sonarr: free, self-hosted
• Radarr: free, self-hosted
• Prowlarr: free, self-hosted (still needed with MediaManager)

The Arr stack itself costs nothing in licensing fees, so the calculus here isn’t about dollar savings — it’s about operational overhead. If you’re paying a homelab-as-a-service provider or a managed hosting platform to run your stack, consolidating two services into one reduces the container count and complexity. The real cost savings argument for MediaManager is time, not money.

If you’re coming from a commercial service like Plex’s discovery features or a fully managed media solution, those comparison numbers depend entirely on your current setup. Data not available for a direct cost comparison there.

---

Deployment reality check

The install path is three shell commands:

wget -O docker-compose.yaml https://github.com/maxdorninger/MediaManager/releases/latest/download/docker-compose.yaml
mkdir config
wget -O ./config/config.toml https://github.com/maxdorninger/MediaManager/releases/latest/download/config.example.toml
docker compose up -d

That’s a genuinely clean onboarding story for a Docker-native user [README]. The configuration happens in a TOML file rather than environment variables scattered across a compose file, which is a thoughtful choice for legibility.

What you’ll need:

• A Linux host with Docker and docker-compose installed
• A domain and reverse proxy (Caddy or nginx) for HTTPS — MediaManager doesn’t ship TLS itself
• An OAuth/OIDC provider if you want SSO (or skip it for local-only access)
• Your existing download client (qBittorrent, NZBGet, etc.) — MediaManager doesn’t replace this
• Prowlarr or a configured indexer — also not replaced

What can realistically go wrong:

• The config.toml setup requires reading the documentation. The README is honest: “you probably need to edit the config.toml file” [README]. For a non-technical user, TOML configuration is less friendly than a first-run web wizard.
• The project is a solo-maintainer effort with sponsor support. If Maximilian Dorninger stops maintaining it, the bus factor is 1. The contributor count of 29 suggests some community involvement, but it’s not a broad maintainer base.
• AGPL-3.0 licensing means any modifications you make and deploy as a network service must be published. For personal home use this is irrelevant. For anyone building a product on top of MediaManager, it’s a real constraint.
• No documented migration path from Sonarr/Radarr yet. If you have years of library history in those apps, expect manual work to reconcile.

Realistic setup time for someone comfortable with Docker: 30–60 minutes to a working instance. For someone new to self-hosting: plan for an afternoon plus consulting the documentation site.

---

Pros and cons

Pros

• Clean, modern interface. Built with Svelte from scratch in 2024–2025, not retrofitted onto a decade-old jQuery foundation. The screenshots show a UI that looks like something built this decade [GitHub screenshots].
• OAuth/OIDC native. First-class support for SSO without a reverse-proxy authentication layer. This is a meaningful improvement over Sonarr/Radarr for anyone running a homelab with centralized identity [README].
• Dual metadata sources. TVDB and TMDB together, in one app, eliminating the split-brain problem of Sonarr (TVDB) vs Radarr (TMDB) [README].
• REST API included. Documented API surface means you can script against it or integrate with other homelab tools [profile].
• Actively maintained. 26 releases, 1,168 commits, DigitalOcean sponsorship. Not an abandoned project [GitHub].
• Fast install. Three commands to a working Docker stack is a legitimate quality signal [README].

Cons

• Young project, small community. 3,144 stars and 29 contributors is early days. Sonarr has 10,000+ stars and years of production hardening. You may hit rough edges [GitHub].
• No third-party reviews. Zero coverage on Trustpilot, G2, Reddit’s r/selfhosted megathreads, or tech blogs as of this writing. You can’t read other people’s production horror stories before committing.
• AGPL-3.0 is more restrictive than MIT. For personal use it’s fine. For embedding in a product or offering as a hosted service, AGPL requires publishing your modifications — which Sonarr (GPL v3) also requires, but worth knowing [GitHub license].
• Partial stack replacement. You still need Prowlarr, a download client, and a media player. MediaManager consolidates Sonarr + Radarr, not the entire pipeline [README].
• No migration tooling. Moving years of Sonarr/Radarr library data into MediaManager requires manual work. No import wizard documented [README].
• Solo maintainer bus factor. Active and sponsored, but a single point of human failure for now.
• No music, books, or podcasts. If you want a truly unified library management solution across all media types, this isn’t it yet [README].

---

Who should use this / who shouldn’t

Use MediaManager if:

• You’re setting up a new self-hosted media stack and don’t want to inherit the Arr stack’s complexity from the start.
• You’re already running Sonarr + Radarr and find the dual-UI maintenance annoying enough to justify a migration.
• You want OAuth/OIDC authentication without bolting Authelia onto your reverse proxy.
• You’re comfortable being an early adopter on a project that’s moving fast but hasn’t accumulated years of community vetting.
• Your library is TV shows and movies — the two content types the project explicitly supports.

Skip it (stick with the Arr stack) if:

• You have years of history in Sonarr/Radarr that you don’t want to risk on a migration.
• You depend on the breadth of Sonarr’s customization options — custom formats, quality profiles, release groups, import lists. The Arr stack’s configurability is exhaustive; MediaManager is simpler, which means less rope in both directions.
• You need music, books, or podcast management — Lidarr and Readarr have no equivalent here.
• You’re running a production service or building a product — AGPL-3.0 imposes obligations that MIT does not.
• You want a project with 5+ years of production use and a large support community.

Skip it (use Jellyfin instead) if:

• You’re confused about the distinction between media management (finding and organizing content) and media playback (streaming it). Jellyfin is a player. MediaManager is a manager. You need both, but they solve different problems.

---

Alternatives worth considering

The Arr stack (Sonarr + Radarr + Prowlarr): The incumbent. More mature, more configurable, larger community, extensive documentation, years of Reddit threads covering every edge case. Harder to maintain across multiple services. Still the safe choice for anyone who prioritizes stability over UI cohesion.

Jellyfin: A media player, not a manager — solves a different problem. Manages and streams your existing library but doesn’t automate finding and downloading new content. You’ll likely run both.

Plex: Closed-source media player. Plex Pass ($4.99/month or $119.99 lifetime) adds features. Not a manager. Same comparison as Jellyfin — different job.

Overseerr: A request management layer that sits on top of Sonarr/Radarr rather than replacing them. Solves the “I want family members to request content without giving them Sonarr access” problem, not the “I want fewer services to manage” problem.

Komga / Kavita: If books and comics are your primary concern, these are purpose-built for that. MediaManager doesn’t cover it.

For someone building a new media stack from scratch, the realistic choice is MediaManager vs. Sonarr + Radarr. Pick MediaManager if you want simplicity and are comfortable being an early adopter. Pick the Arr stack if you want the most-documented, most-supported option that every self-hosting guide in existence covers.

---

Bottom line

MediaManager is an honest attempt to solve a real frustration in the self-hosted media space: the operational overhead of running separate apps for TV and movie management when they’re doing essentially the same job. The design is clean, the OAuth/OIDC support is a genuine differentiator, and the install story is as painless as Docker Compose gets.

The honest caveat is that you’re betting on a young project at an early stage. Three thousand stars and two dozen contributors is not the same as ten thousand stars and a decade of production use. There are no third-party reviews to read, no Reddit horror stories to calibrate against, and no migration tooling to soften the move from the Arr stack.

If you’re starting fresh and the Arr stack’s fragmentation already sounds annoying, MediaManager is a reasonable default. If you’re migrating years of production use from Sonarr and Radarr, wait another 6–12 months for the project to accumulate community vetting first.

If the Docker setup is the blocker, that’s what upready.dev deploys for clients — one-time fee, done, you own the infrastructure.

---

Sources

1. maxdorninger/MediaManager — GitHub README — Primary documentation: features, quick start, license, architecture. https://github.com/maxdorninger/MediaManager
2. MediaManager GitHub repository — Stars, forks, contributors, release history, commit count, language breakdown, license (AGPL-3.0). https://github.com/maxdorninger/MediaManager
3. MediaManager Documentation — Official docs site built with MkDocs. https://maxdorninger.github.io/MediaManager/