qui replaces the qBittorrent WebUI with a Go binary that fronts several instances at once, adds rule-based automations and cross-seeding, and ships under GPL-2.0-or-later. The trade-off is that it sits between your other tools and qBittorrent, so the proxy path becomes part of your stack.

Can I use autobrr/qui commercially?

Yes, with conditions. GPL-2.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.

Is autobrr/qui still maintained?

Yes. The repository received new commits within the last day.

What programming language is autobrr/qui written in?

Mainly Go, according to GitHub's language statistics.

autobrr/qui: qBittorrent web UI, Docker and cross-seed

At a glance

What is it?: qui replaces the qBittorrent WebUI with a Go binary that fronts several instances at once, adds rule-based automations and cross-seeding, and ships under GPL-2.0-or-later. The trade-off is that it sits between your other tools and qBittorrent, so the proxy path becomes part of your stack.
Who is it for?: Adopt qui if you run more than one qBittorrent instance, or if you want cross-seeding and rule-based automations inside the same process that renders the torrent list. Skip it if a single qBittorrent instance and the stock WebUI already cover your needs, or if you cannot accept a GPL-2.0-or-later dependency in front of your client.
Can I use it commercially?: Yes, with conditions. GPL-2.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
Is it still maintained?: Yes. The repository received new commits within the last day.
What is it written in?: Mainly Go, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.

DEEP OPEN-SOURCE ANALYSIS

Hysen Labs Editorial · September 15, 2026 · autobrr/qui

The problem qui solves: many qBittorrent instances, one interface

The stock qBittorrent WebUI is bound to one instance. If you run separate clients for different trackers, categories or seedboxes, you end up with a browser tab per instance and no shared view of what is seeding where. qui is built around that gap. The README describes it as a web interface that supports "managing multiple qBittorrent instances from a single, lightweight application", and the feature list repeats the point: multi-instance support, cross-seed, automations, backups and restore, and a reverse proxy.

The audience is narrower than "anyone who uses qBittorrent". It is for people who already operate more than one client and have felt the cost of switching between them, and for people who cross-seed across trackers and currently do that work by hand or with a separate script. If you run one qBittorrent instance with a handful of torrents, the multi-instance machinery is overhead you will not use.

How qui is put together: Go binary, embedded web app, qBittorrent API clients

The repository layout is a conventional Go service: cmd/ for entry points, internal/ for application code, pkg/ for shared packages, and web/ for the frontend that gets built and embedded into the binary. The Makefile has separate frontend and backend targets and a build target that runs both, which matches the "single binary" claim in the README: the UI is compiled in rather than served from a separate directory.

On the qBittorrent side, go.mod pulls in github.com/autobrr/go-qbittorrent, a client library for the qBittorrent WebUI API. That is the mechanism behind multi-instance support: qui is not patching qBittorrent, it is speaking the same HTTP API your browser would, once per configured instance, and merging the results. The dependencies also show what the automation and cross-seed features are built on. github.com/expr-lang/expr is an expression evaluation library, which fits the "rule-based torrent management with conditions and actions" description. github.com/moistari/rls parses release names, and github.com/autobrr/go-torrent handles torrent files, both of which are the kind of parsing cross-seed matching needs. github.com/autobrr/go-mediainfo and go-bdinfo point at media inspection.

Storage and transport choices are visible too: github.com/jackc/pgx/v5 with embedded-postgres, chi for routing, zerolog for logging, go-sse for server-sent events (which is how a web UI would push live torrent state without polling), and shoutrrr for notifications. The README defers configuration detail to getqui.com, so go.mod is where the shape of the system is actually legible.

Installing qui and reaching the web interface on port 7476

The README gives two install paths. The Linux x86_64 route downloads the latest release archive, extracts the binary into /usr/local/bin, and runs it. The command below is copied from the README; the curl call queries the GitHub releases API for the newest linux_x86_64 asset, so it needs network access and a working tar.

bash

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
qui serve

After `qui serve`, the README states the web interface is available at http://localhost:7476. That port is the one to remember; it also appears in the Docker example and is the value people search for when a container starts but nothing loads.

The Docker route mounts a config directory and publishes the same port:

bash

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

The volume matters. Without it, the configuration you create through the UI lives inside the container and disappears when the container is replaced. The image tag used in the README is ghcr.io/autobrr/qui:latest; the Makefile shows a local development image built as ghcr.io/autobrr/qui:dev, which is a different tag and not what you want in production.

Once the UI is up, the first real task is adding a qBittorrent instance, which means supplying its address and credentials so the go-qbittorrent client can authenticate. The README does not walk through that form, so treat getqui.com as the reference for the exact fields. The repository also exposes a `qui serve` subcommand through spf13/cobra, and the Makefile's dev targets (dev, dev-backend, dev-frontend) exist for people building from source rather than running a release binary.

Where qui gets in the way: proxy coupling and undocumented edges

The reverse proxy feature is the most consequential design decision in the README, and it is described in one line: a "transparent qBittorrent proxy for external apps". Read that as a warning as much as a feature. Tools such as Radarr and Sonarr, and the cross-seed scripts people already run, are configured with a qBittorrent URL. If you point them at qui instead, qui becomes a required hop in every one of those integrations. When qui is down for an upgrade, those tools lose their download client, even though qBittorrent itself is healthy. The README does not document rollback for the proxy path, and it does not describe how qui behaves when an upstream instance is unreachable, so the failure semantics of that hop are something you would have to observe yourself.

The documentation is also thin in a way that matters for adoption. The README is a landing page: features, install, community links, donation addresses. Configuration, instance management, automation rule syntax, backup restore modes and cross-seed behaviour all live on getqui.com, which is outside the repository. The repository itself contains docs/ and documentation/ directories, but their contents are not surfaced by the README. If you need to evaluate automation rules before deploying, you are evaluating a website, not a spec.

One more boundary: qui is a UI and an orchestrator over the qBittorrent API, not a torrent engine. It depends on qBittorrent doing the actual downloading. Nothing in the README suggests it replaces libtorrent or the client itself, and the topics list includes libtorrent alongside qbittorrent-webui for that reason.

qui compared with VueTorrent and Flood: different layers, not just different skins

The README lists its own alternatives, and the list is useful because the projects do not occupy the same layer. VueTorrent is described there as "a modern, responsive alternative WebUI". That is a replacement for the qBittorrent web frontend, installed inside qBittorrent's own WebUI directory and talking to one instance. It does not add a second process, does not manage multiple instances, and does not intermediate the API for other apps. If your problem is that the stock UI looks dated, VueTorrent is the smaller change.

Flood is the closer comparison, because the README says it "supports qBittorrent and other torrent clients". That is a genuine architectural difference: Flood abstracts over client backends, so the same UI can drive rTorrent or qBittorrent. qui is qBittorrent-specific and spends its complexity budget elsewhere, on cross-seeding, automations and backups. If you have a mixed fleet of clients, Flood's abstraction is the feature you want. If everything is qBittorrent, qui's narrower focus is not a limitation.

qBitController, described as "a native app for Android, iOS, Linux, macOS, and Windows", is a different form factor entirely: a native client rather than a self-hosted web service. It does not compete on cross-seed or automations. The README also points to the qBittorrent wiki's longer list of community WebUIs, which is the right place to look if none of these four fit.

Maintenance cadence, upgrade mechanics and the GPL-2.0-or-later licence

The last push to the develop branch was on 2026-09-14, and the most recent releases are v1.29.0 on 2026-09-12, v1.28.0 on 2026-09-01 and v1.27.0 on 2026-08-26. Three releases in roughly three weeks, with a push on the same day as the latest data point, is a fast cadence. That cuts both ways: fixes arrive quickly, and so does churn. The default branch is develop, not a stable branch, which means the code you see on GitHub is ahead of the tagged releases you install. Pin to a release tag rather than tracking develop.

Upgrade cost is low on the binary path. Download, extract over the existing binary, restart. The Docker path is a pull and recreate, and because the config volume is separate, your instance configuration survives. The repository includes .goreleaser.yml and .goreleaser.release.yml, and go.mod depends on github.com/creativeprojects/go-selfupdate, which is a self-update library; the README does not document an in-app update command, so whether that dependency is wired to a user-visible upgrade path is not something the README confirms.

The licence is GPL-2.0-or-later. For self-hosted use that is unremarkable. It matters if you intend to redistribute qui, bundle it into a product, or link it with code you do not want to license under GPL terms. The premium themes mentioned in the README are a separate commercial arrangement handled through Settings, and a theme licence key is not the same thing as the software licence. This is a description of what the repository states, not legal advice; if redistribution is on your roadmap, have someone qualified read the licence.

Editorial conclusion

Adopt qui if you run more than one qBittorrent instance, or if you want cross-seeding and rule-based automations inside the same process that renders the torrent list. Skip it if a single qBittorrent instance and the stock WebUI already cover your needs, or if you cannot accept a GPL-2.0-or-later dependency in front of your client. Before committing, verify that your qBittorrent version is accepted by the bundled go-qbittorrent client, and confirm the reverse proxy behaviour against the external apps that currently talk to qBittorrent directly.

Frequently asked questions

What is autobrr/qui?

It is a web interface for qBittorrent written in Go and distributed as a single binary. The README describes it as supporting management of multiple qBittorrent instances from one lightweight application, with cross-seed, automations, backups and a reverse proxy.

How do I install autobrr/qui with Docker?

The README gives a single docker run command that publishes port 7476 and mounts a config volume at /config, using the image ghcr.io/autobrr/qui:latest. Keep the volume mount, or your configuration is lost when the container is recreated.

What port does autobrr/qui use?

Port 7476. The README states the web interface is available at http://localhost:7476 after running qui serve, and the Docker example maps 7476:7476.

Does autobrr/qui support cross-seeding?

Yes. The feature list includes cross-seed, described as automatically finding and adding matching torrents across trackers. The go.mod dependencies include release-name and torrent-parsing libraries that such matching would rely on.

What is the difference between autobrr/qui and VueTorrent?

VueTorrent is described in the README as a modern, responsive alternative WebUI, meaning it replaces the qBittorrent frontend for one instance. qui runs as a separate application and adds multi-instance management, cross-seed, automations, backups and a reverse proxy for external apps.

Is autobrr/qui the same as autobrr?

No. qui is a separate project in the autobrr organisation, and go.mod depends on github.com/autobrr/autobrr as a library. autobrr itself is an IRC announce filter for torrent trackers; qui is a qBittorrent web UI and management layer.

Official sources

Community notes