ombi's download table sends develop builds to an artefact server under the project's old name

The download table's two columns point at the same place

The table near the top is supposed to separate a stable line from a development one, and then it takes both apart. The build status row carries the same build workflow link in its stable cell and its develop cell, so it cannot tell you which branch you are looking at. The download row sends stable to the releases page and develop to a continuous integration artefact server, and then adds a third cell that repeats the releases link. Three header columns, and two rows that arrange their cells differently. So the table is not a matrix you can read across; it is one release link and one build badge wearing a matrix's clothes. That is not a criticism of the project so much as a reading instruction: take the develop column as an artefact server whose contents change, and do not expect the badge to distinguish the two lines.

Three links on the first screen still carry the old name

The project was renamed at some point, and the renaming missed three things that a reader meets in the first screen of the file. The develop download goes to a continuous integration artefact server whose project slug is the old name. The donation link points at a payment address whose label is also the old name. And the Android package identifier is built from the maintainer's own handle rather than from anything to do with the project, which is common and defensible and worth knowing before you assume the listing in a store is the project. None of those three is broken and the first two still resolve. They are the places where a reader is most likely to hesitate for a second, which is the only cost.

A landing page that reports whether your server is up

One feature bullet describes a landing page that gives the availability of your media server and lets you add custom text about downtime. The reason it exists is obvious and reasonable: your users should be able to see whether the service is up before they try to sign in. The consequence is equally obvious and is the thing to decide deliberately. Anything who can reach the port learns that a media server exists behind it and whether it is currently up, with no account and no rate limit, and the readme's only guidance on mitigating that is a separate page about reverse proxy configuration. It is a small disclosure and a normal one for a self-hosted service. It is also the kind that becomes a problem the day the port is forwarded rather than left on a home network.

The security bullet is one adjective and a misspelling

The feature list has ten entries and nine of them describe something the software does: it tracks requests, it updates their status, it accepts them from named accounts, it pushes approved ones to a download client. The tenth is a claim about secure authentication using best practices, in words that are not quite English. No mechanism, no scheme, no version, no reference. For a service whose job requires holding write access to four download clients and read access to a media library, that is the one bullet you would want substance behind, and the README offers none. It is not a claim you should treat as false, and it is not one you can check, which makes it the least useful line in the section.

Three media servers in the description, two in the feature list

The repository description asks whether you want a film or a show on any of three media servers, and the naming is deliberately prominent enough that a reader will remember all three. The feature list then names two of them, twice, and never mentions the third again. User accounts can come from the media service's own account system or from local accounts, which is the part that matters for a self-hosted service, since local accounts mean you own the identity layer. The download clients are named with an and others: four of them. So the integration surface described in the README is one media server family, two account sources and four download clients, and the description promises slightly more than the list delivers.

A migration tracked in a file in the root

The repository root contains a markdown file named for a standalone migration and its progress. That is a project tracking an in-flight architectural change in the root of the tree rather than in its documentation site or its issue tracker, which has two consequences. It will be stale the day the migration lands, and until then it is the best single signal in the repository about what is changing and how far along it is. Two neighbouring entries describe the toolchain rather than the product: a make file in lowercase in a project whose main language is a compiled one, presumably for assets, and a machine-readable version file whose naming lines up with the release tags. There is also a merge queue configuration and a translation platform file matching the badge at the top.

A container badge, no container definition, and no port

The first screen badges an image from a community container registry, the installation section links to a documentation site and to a page of reverse proxy examples, and the repository contains no container definition at all. So the image that most people run was built somewhere that is not this tree, which means the version inside it and the version in the source are tied together only by the release process and by whatever the third-party maintainers did. Everything else about deployment, including which port the service listens on, is on the documentation site rather than in the readme. For a self-hosted application whose whole audience will copy a command from somewhere, that split is the normal shape of the ecosystem and it does mean you are trusting a chain of four parties rather than one.

Editorial conclusion

Ombi is worth installing if your household or group argues about what to watch and you want requests to arrive in a download client without anyone editing files. Four things to know first. It holds write access to your download clients and read access to your media library, so treat its configuration as credentials rather than as settings. Its landing page reports whether your media server is up and is meant to be reachable before you sign in, which is a disclosure decision to make on purpose rather than inherit. Two links on the first screen of the readme still carry the project's previous name, and the mobile package identifier is a person's handle, so trace where you are being sent before you trust an artefact download. And the install instructions, including the port, are on a documentation site rather than in the repository, while the container image everyone uses is built outside this tree. Licence terms are GPL-2.0 and the last push is dated 2026-09-29.

Frequently asked questions

Official sources

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