autobrr/qui: a single-binary qBittorrent web UI with cross-seed and rules

What qui actually replaces, and for whom

qui is not a torrent client. It is a web interface that sits in front of qBittorrent, and the README frames it as a fast, modern interface that supports managing multiple qBittorrent instances from one lightweight application. That single sentence carries the whole positioning: the unit of management is the instance, not the torrent.

The audience follows from that. If you run one qBittorrent container with one download category, the stock WebUI already does the job and qui adds a second service to keep alive. If you run several instances, for example one per tracker group or one per ratio strategy, the stock WebUI forces you to switch between URLs and log in repeatedly, and there is no shared view of what is downloading where. qui is built for that second case.

The feature list points the same way. Multi-instance support, cross-seed, automations, backups and a reverse proxy are all features that only make sense once you have more than one client or more than one tracker. The reverse proxy entry is worth reading literally: qui can act as a transparent qBittorrent proxy for external apps, which means Radarr, Sonarr or a seeding script can keep talking to a qBittorrent-shaped endpoint while qui decides which instance answers.

How qui is put together: one Go binary, an embedded web app

The repository layout is a Go service with a compiled frontend. The top level holds cmd/, internal/, pkg/ and web/, plus a Makefile whose build target runs frontend and backend in sequence. The frontend is built into internal/web, which is why the README can call the result a single binary with no dependencies.

The dependency list shows how the pieces connect. github.com/autobrr/go-qbittorrent is the client used to talk to your instances, so the qBittorrent WebUI API version you run has to be one that library understands. github.com/expr-lang/expr provides the expression language behind rule conditions, which is why automations are described as rule-based with conditions and actions rather than as a fixed set of toggles. github.com/go-chi/chi/v5 handles HTTP routing, github.com/tmaxmax/go-sse provides server-sent events for pushing live updates to the browser, and github.com/rs/zerolog plus gopkg.in/natefinch/lumberjack.v2 cover logging and rotation.

Storage is the part worth pausing on. go.mod includes github.com/jackc/pgx/v5 and github.com/fergusstrange/embedded-postgres, and the Makefile has a test-postgres target. That means qui is not a stateless proxy: it keeps its own state, and it can run an embedded PostgreSQL instance rather than requiring you to supply a database. For a self-hosted tool that is a real convenience, but it also means the /config volume is not disposable. Backups and restore are listed as scheduled snapshots with multiple restore modes, which only makes sense if qui owns data that qBittorrent does not have.

The reverse proxy feature sits on the same HTTP layer. External apps point at qui instead of at qBittorrent, and qui forwards to the right instance. The README does not document which qBittorrent endpoints are proxied and which are not, so treat full API compatibility as unverified until you check the documentation site.

Installing qui and adding your first qBittorrent instance

The README gives two paths. On Linux x86_64 you download the release archive and extract the binary into /usr/local/bin, then run it. The commands below are copied from the README.

# Download and extract the latest release
wget $(curl -s https://api.github.com/repos/autobrr/qui/releases/latest | grep browser_download_url | grep linux_x86_64 | cut -d\" -f4)
sudo tar -C /usr/local/bin -xzf qui*.tar.gz qui

# Run
qui serve

After qui serve starts, the README states the web interface is available at http://localhost:7476. That port is the one to remember for every later step, including reverse proxy configuration.

The Docker path is shorter and is the one most self-hosted users will pick. It publishes the same port and mounts a config directory.

docker run -d \
  -p 7476:7476 \
  -v $(pwd)/config:/config \
  ghcr.io/autobrr/qui:latest

The /config mount is where qui keeps its state. Because qui runs an embedded PostgreSQL dependency and offers scheduled backups, that directory is the thing you back up, not the container.

Once the UI loads, the first real task is adding an instance. The README does not show the connection form, so the exact field labels are not quoted here. What it does establish is that qui talks to qBittorrent through go-qbittorrent, so you need the qBittorrent WebUI reachable from the qui container or host, with its own credentials. If qui runs in Docker and qBittorrent runs on the host, localhost inside the container is not the host, and that is the first thing to check when an instance will not connect. The README also does not document rollback or downgrade steps for the embedded database, which is worth knowing before you upgrade across a major version.

Cross-seed and automations: what the README claims and what it leaves open

Cross-seed is described as automatically finding and adding matching torrents across trackers. Automations are described as rule-based torrent management with conditions and actions. Those are the two features that justify running qui next to qBittorrent rather than instead of it.

The mechanism for cross-seed is not spelled out in the README. Finding a matching torrent across trackers requires matching release names, file layouts and piece sizes, and the go.mod hints at the tooling involved: github.com/moistari/rls for release name parsing, github.com/autobrr/go-torrent, github.com/autobrr/go-bdinfo and github.com/autobrr/go-mediainfo for inspecting torrent and media metadata. That is a plausible pipeline, but the README does not state the matching criteria, so you cannot tell from the repository alone whether a near-match will be added or skipped.

The same gap applies to automations. expr is an expression language, so conditions are written rather than clicked, but the README gives no example rule. Before relying on this, read the documentation at getqui.com, because the difference between a condition that fires on the wrong torrents and one that does not is entirely in the expression, and there is no dry-run mode mentioned in the README.

The honest summary is that these are the features to evaluate first and the ones the README documents least. That is not unusual for a project whose documentation lives on a separate site, but it does mean the README alone is not enough to plan a rollout.

Where qui is the wrong tool

The clearest case against qui is a single-instance setup. If you have one qBittorrent and no cross-seeding, qui adds a Go service, a config volume, an embedded database and an upgrade path, in exchange for features you will not use. The stock WebUI is already there and costs nothing to keep.

The second case is mobile. The README's own alternatives list includes iQbit, described as a mobile-focused WebUI and PWA, and qBitController, described as a native app for Android, iOS, Linux, macOS and Windows. qui's feature list says nothing about a PWA or a native client, and the README does not document a mobile layout. If your main use is checking downloads from a phone, one of those two is a better fit.

The third case is API compatibility. qui advertises a transparent reverse proxy for external apps, but the README does not enumerate which qBittorrent endpoints are covered. If you depend on an unusual endpoint, or on an app that talks to qBittorrent in a non-standard way, you are betting on undocumented coverage. Verify against your specific client before you move Radarr or Sonarr onto the qui endpoint.

Finally, there is the dependency on qBittorrent itself. qui does not replace the client, so anything that breaks qBittorrent breaks qui. The README lists Flood as an alternative that supports qBittorrent and other torrent clients, which is the escape hatch if you want one interface across clients rather than a deep interface for one.

Maintenance, licensing and the upgrade cost

The repository is not archived, and the last push was on 2026-09-14. Releases are frequent: v1.27.0 on 2026-08-26, v1.28.0 on 2026-09-01 and v1.29.0 on 2026-09-12. That cadence is the useful maintenance signal here, not any counter on the repository page.

Upgrade cost depends on which install path you chose. With the Docker image, pulling ghcr.io/autobrr/qui:latest and recreating the container is the whole operation, and the /config volume carries your state across. With the binary, the README's own extraction command overwrites /usr/local/bin/qui, so the old binary is gone unless you keep a copy. Neither path is documented with a rollback procedure, and because qui runs an embedded PostgreSQL, a schema change in a new release is the scenario where a rollback would actually matter. Back up /config before upgrading. The README does document scheduled snapshots with multiple restore modes, so qui has its own answer to this, but it is not the same as an external backup you control.

The licence is GPL-2.0-or-later, stated at the end of the README and in the LICENSE file. For self-hosting that is unremarkable. If you plan to modify qui and distribute it, or to bundle it into a product, the copyleft terms apply to what you distribute, and that is a question for your own legal review rather than something this article can settle.

There is one commercial element to note: premium themes are sold through Settings, and a licence also unlocks custom themes, with community themes published in a separate repository. The application itself is not gated behind that purchase according to the README, which describes theme purchases as support for development.

Editorial conclusion

Adopt qui if you run more than one qBittorrent instance, or if you want cross-seed and rule-based automation in front of the client you already have. Skip it if you want a WebUI that stays inside one instance, or if you cannot run a second service next to qBittorrent. Before committing, check that your qBittorrent version is supported by the bundled go-qbittorrent client, and confirm how qui reaches your torrent files, because cross-seed and automation both depend on that access.

Frequently asked questions

Official sources

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