Ombi: self-hosted media requests for Plex, Emby and Jellyfin

What Ombi does that a chat message cannot

A private media server usually has one administrator and a handful of viewers. The administrator adds titles through Sonarr, Radarr or Lidarr, and the viewers ask for things in a group chat. That works until the same film is requested three times, or someone asks for a series that is already on the server. Ombi turns that conversation into a catalogue: users request Movies, Music and TV Shows, whether the entire series, an entire season, or single episodes, and the request is tracked instead of remembered. The README also says Ombi will show if the request is already on Plex or even if it is already monitored, which is the part a chat thread cannot do. It is aimed at the person running the server, not the viewer. The viewer gets a web page and mobile apps; the administrator gets a queue, a user list and a set of approval rules.

How Ombi sits between your users and Sonarr

Ombi is a C# application with a web front end, and it is a middle layer rather than a media tool. It authenticates users against plex.tv, Emby or local accounts, holds their requests, and then talks to the services that actually fetch files. The README names those services directly: Sonarr, Radarr, Lidarr and Couchpotato. The data flow is therefore one direction for requests and another for status. A user submits a title; Ombi stores it and, depending on the user, either waits for approval or passes it to the relevant service. When the title later appears on Plex or Emby, Ombi updates the status of the request, so the original requester sees that it arrived. There is also a landing page that reports the availability of your Plex or Emby server and can carry custom notification text for downtime. The repository layout matches that shape: src/ holds the application, tests/ holds the test projects, and the README points at docs.ombi.app for installation and reverse proxy configuration.

Install Ombi and approve your first request

The README does not give command line steps, and it does not publish a compose file or a list of environment variables. What it gives is a set of destinations. The Installation Guide lives at docs.ombi.app/installation/, reverse proxy examples at docs.ombi.app/info/reverse-proxy/, and the badge row points at the linuxserver/ombi image on Docker Hub. The release page on GitHub carries the standalone builds, and the README also links a Google Play listing and an App Store listing for the mobile clients. So the practical first step is to open the installation guide and pick the deployment you can maintain; the README does not recommend one over another. Once Ombi is running, open the web interface and complete the setup wizard. The first account you create is the administrator. From there you connect your media server, then add Sonarr, Radarr or Lidarr under the settings for the relevant media type, using the API key from each of those applications. After a service is connected, create a second, ordinary user and sign in as that user to submit a request. If the request appears in the administrator queue and then moves to available after the title lands on Plex, the chain is wired correctly. The port you reach it on, and the volume or environment settings your deployment needs, are documented in the installation guide rather than the README.

Ombi is a request broker, not a downloader

The most common wrong expectation is that Ombi fetches media. It does not. It has no indexer, no download client and no library management; those remain with Sonarr, Radarr, Lidarr and whatever downloader sits behind them. If you have no such service, Ombi has nothing to hand a request to, and the approval step becomes a to-do list for you. There is a second boundary around exposure. Ombi authenticates users, but the README's security claim is only that authentication uses best practices, and the project separately publishes reverse proxy configuration examples, which tells you the maintainers expect it to sit behind a proxy rather than face the internet directly. Treat the proxy as part of the deployment, not an optional extra. A third limitation is documentation depth: the README is a feature list and a set of links. It does not document rollback, backup of the configuration database, or what happens to pending requests during an upgrade. The repository has a CHANGELOG.md and a STANDALONE_MIGRATION_PROGRESS.md, so version-to-version changes are recorded there, but you will be reading release notes rather than a migration manual.

Ombi against a plain shared spreadsheet

The obvious alternative for a small server is a shared document: a spreadsheet or a pinned message where people list what they want, and the administrator works through it. The difference is not cosmetic. A spreadsheet has no accounts, so it cannot tell who requested what, and no connection to the media server, so it cannot mark a title as already available or already monitored. It also cannot be scoped per user: Ombi lets you set specific users to automatically have requests approved and added to the relevant service, while everyone else waits. That distinction is the whole point of running it. The cost is that you now operate another service with its own database, its own port and its own upgrade path, and you have to keep its connections to Sonarr, Radarr and Lidarr working. For two or three trusted users, the spreadsheet is genuinely less work. Ombi starts paying for itself when the request volume or the number of requesters makes manual triage the bottleneck.

Maintenance, releases and the GPL-2.0 licence

Ombi is not archived, and the last push to the develop branch was on 2026-09-04. Releases are frequent and small: v4.60.16 on 2026-09-04, v4.60.15 and v4.60.14 on 2026-08-06. That cadence is worth noting for upgrades, because the patch numbers move quickly and the README does not describe a rollback procedure. Take a copy of your configuration before you pull a new image, and read CHANGELOG.md for the version you are moving to. The project is licensed GPL-2.0, which matters if you plan to modify and redistribute it: derivative distributions have to carry the same licence. Running it on your own hardware for your own users does not trigger that obligation. If you only consume the official builds or the linuxserver image, the licence is a detail you can note and move past. The README also points to Crowdin for translations and to a Feature Upvote board for feature requests, which tells you where maintainers want suggestions to go rather than into the issue tracker.

Editorial conclusion

Adopt Ombi when several people share a Plex, Emby or Jellyfin server and you are tired of taking requests by chat: it needs a host, a database, and API keys for Sonarr, Radarr or Lidarr, plus a reverse proxy if it is exposed. Skip it if you are a single user who adds media directly, or if you want the request tool to also download and organise files, which Ombi does not do. Before exposing it, confirm in the installation guide how your chosen deployment stores its configuration, since the README only links to that guide.

Frequently asked questions

Official sources

1. License: GPL-2.0
2. Ombi-app/Ombi on GitHub
3. Project website
4. README
5. Releases