qui

A modern replacement for qBittorrent’s default interface, honestly reviewed. Not for casual torrent users — this is infrastructure for serious home media setups.

TL;DR

• What it is: A fast, single-binary web interface for qBittorrent that replaces the built-in web UI. Manage multiple qBittorrent instances from one dashboard, with cross-seeding, rule-based automations, and scheduled backups built in [README].
• Who it’s for: Home media server operators running *arr stacks (Sonarr, Radarr, autobrr), private tracker users who cross-seed aggressively, or anyone with multiple qBittorrent instances they’re tired of managing separately [docs].
• Cost savings: qui is free (GPL-2.0). There’s no SaaS alternative doing what it does. The value proposition isn’t escaping a recurring bill — it’s escaping the limitations of qBittorrent’s built-in interface, which has no multi-instance support, no automations engine, and no cross-seed awareness [README][docs].
• Key strength: Single binary, no dependencies. Download, run, done. That plus multi-instance management in one dashboard is the core value [README].
• Key weakness: Works only with qBittorrent. If you run Deluge, rTorrent, or Transmission, you can’t use it — and the project is explicit that support for other clients isn’t available yet [docs].

---

What is qui

qui (pronounced like the French word, or just “kwee” — the project doesn’t say) is a web application that sits in front of your qBittorrent instance and replaces the default web UI with something faster, more capable, and more opinionated. It’s built by the autobrr team — the same people behind autobrr, a popular IRC and RSS-based torrent automation tool with a substantial community in the self-hosted media space.

The pitch in the GitHub README is blunt: “A fast, single-binary qBittorrent web UI: manage multiple instances, automate torrent workflows, and cross-seed across trackers.” [README] That’s three distinct value propositions stacked together, which tells you something about the intended user. This isn’t for someone who downloads a movie occasionally. It’s for someone running a dedicated seedbox or home server with multiple qBittorrent daemons, tracker ratios to protect, and a *arr stack routing downloads through it.

The project sits at 3,516 GitHub stars, licensed under GPL-2.0-or-later, and distributed as a single binary for Linux (plus Docker) [README]. The website is getqui.com, with reasonably thorough documentation covering installation, configuration, and features.

What’s unusual about qui’s monetization is that the software itself is free and open source, but the project sells premium themes — purchasable directly from within the interface via Settings → Themes. Crypto donations get a 100% discount code. It’s a clever model: the GPL license means the core can’t be paywalled, so the team monetizes cosmetics instead of features [README].

---

Why people choose it

No substantial third-party reviews of qui were available at the time of writing — the project is newer and niche enough that mainstream tech media hasn’t covered it. What follows is grounded in the official documentation and the clear use-case signals the features themselves telegraph.

The people qui is built for are running what the self-hosted community calls an “*arr stack” — Sonarr for TV shows, Radarr for movies, Prowlarr for indexers, and something like autobrr for private tracker IRC announces. qBittorrent sits at the bottom of this stack as the actual download engine. Managing it through the default built-in web UI starts to break down when you have multiple instances (different VPNs, different categories, different disk pools), thousands of torrents, and automated workflows that need torrent-level metadata to make decisions.

The default qBittorrent web UI doesn’t know what cross-seeding is. It doesn’t let you write rules like “if torrent ratio > 2 and category is public, delete.” It can’t talk to autobrr via webhook to trigger cross-seed searches. qui does all of these things [docs][README].

For private tracker users specifically, cross-seeding is close to essential — it’s how you maintain ratio on competitive trackers without always being first to grab new releases. The fact that qui has a dedicated cross-seed module with autobrr webhook integration suggests the team built this from their own pain, not as a checkbox feature [docs].

The single-binary deployment model is another reason people reach for it. Self-hosted Docker fatigue is real — coordinating containers, volumes, networks, and compose files for every tool adds up. A tool that ships as a single static binary you extract and run (./qui serve) and exposes an interface at port 7476 has genuine ergonomic value [README].

---

Features

Based on the official documentation and README [README][docs]:

Core interface:

• Multi-instance management — connect multiple qBittorrent instances (different ports, different servers) and manage them from one interface [docs]
• Built for large collections — designed to handle thousands of torrents without the performance degradation the default UI shows at scale [docs]
• Multiple color themes, with premium themes purchasable in-app [README]
• Base URL support for reverse proxy subdirectory setups (e.g., /qui/) [docs]
• Incognito mode — disguises torrents as “Linux ISOs” for screen sharing, which is a real feature that real people asked for [docs]
• Browser extensions for Chrome and Firefox: right-click any magnet or torrent link to send it directly to your qBittorrent instances [docs]

Automation and management:

• Automations engine: Rule-based torrent management with conditions and actions. Conditions can check ratio, category, tracker, age, size. Actions include delete, pause, tag, and speed limiting. Cross-seed awareness built in [docs][README]
• Cross-Seed module: Automatically find matching torrents on other trackers and add them. Integrates with autobrr via webhook [docs][README]
• Orphan Scan: Find and remove files on disk not associated with any torrent — useful for cleaning up failed downloads or manually moved files [docs]
• Tracker Reannounce: Automatically fix stalled torrents when qBittorrent doesn’t retry announces fast enough (common problem on private trackers with strict announce windows) [docs]
• External Programs: Launch custom scripts from the torrent context menu [docs]

Infrastructure:

• Backups & Restore: Scheduled snapshots with three restore modes — incremental, overwrite, and complete [docs][README]
• Reverse Proxy mode: Transparent proxy that lets external apps (autobrr, Sonarr, Radarr) talk to qBittorrent through qui without sharing credentials [docs][README]
• OIDC Single Sign-On: Authenticate through any OpenID Connect provider — unusual for a torrent UI, but meaningful for people who’ve centralized auth with something like Authelia or Keycloak [docs]
• REST API: Available for programmatic integration [docs]
• Metrics: Documented support (likely Prometheus-compatible, though specifics weren’t available in the reviewed sources) [docs]

Deployment:

• Single binary (no runtime dependencies) [README]
• Docker image (ghcr.io/autobrr/qui:latest) [README]
• Reverse proxy ready [docs]

---

Pricing: what you actually pay

qui has no SaaS offering. It’s purely self-hosted, GPL-2.0 licensed software. The cost math is simple:

qui itself: $0 [README]

To run it:

• VPS or home server: $0 if you already have hardware; ~$4–8/mo on Hetzner or Contabo if you don’t
• Domain + reverse proxy: optional, ~$10/year for a domain if you want HTTPS and a real hostname

Premium themes: Price not published on the website or in the documentation. Purchasable directly inside the Settings → Themes page of your running instance. Crypto donations grant a 100% discount code [README]. Based on the positioning (volunteer-developed, community project), expect $5–15 per theme — but data isn’t available to confirm this.

The comparison isn’t “qui vs a paid SaaS alternative” because no meaningful paid SaaS alternative exists for this specific use case. The comparison is:

Option	Cost	Multi-instance	Automations	Cross-seed
qBittorrent built-in Web UI	$0	No	No	No
VueTorrent (open source alternative)	$0	No	No	No
Flood (multi-client UI)	$0	Yes (multi-client)	Limited	No
qui	$0 + optional themes	Yes	Yes	Yes

If you’re paying for a seedbox service (SeedHost, RapidSeedbox, UltraSeedbox), many offer qBittorrent with their default web UI. qui can replace that UI if you have SSH/Docker access, which most seedbox providers allow at mid-tier and above. No additional recurring cost [README].

---

Deployment reality check

The single-binary model is genuinely the smoothest deployment story in this space [README]:

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

Open http://localhost:7476, create an admin account, add your qBittorrent instance URL and credentials, done.

What you actually need:

• Any Linux machine (x86_64) or Docker [README]
• qBittorrent running with its web UI enabled (you’re just adding qui in front)
• A reverse proxy (Caddy, nginx, Traefik) if you want HTTPS — not required for local access
• An OIDC provider if you want SSO — optional [docs]

What can go sideways:

The biggest practical constraint is qBittorrent version compatibility. qui communicates through the qBittorrent Web API, which has changed between versions. The documentation references a “qBittorrent Version Compatibility” page [docs], implying some versions work better than others. If you’re running an older qBittorrent build because your seedbox hasn’t updated, check compatibility before assuming everything will work.

The multi-instance feature requires that each qBittorrent instance is reachable from wherever qui is running. If your instances are on different VLANs or behind different VPNs, network routing becomes your problem to solve — qui doesn’t do that for you.

The reverse proxy mode (letting Sonarr/Radarr/autobrr talk to qBittorrent through qui without sharing credentials) is a compelling security feature for *arr stack users. The setup requires some configuration to make external apps point at qui’s proxy address rather than qBittorrent directly [docs].

Realistic time estimates:

• Basic single-instance setup: 10–20 minutes
• Multi-instance with reverse proxy and HTTPS: 1–2 hours
• Full *arr stack integration with cross-seed and automations: a focused afternoon

Contributions are restricted to collaborators only (PRs from outside are blocked). Bug reports and feature requests go through GitHub Discussions or their Discord at discord.autobrr.com/qui [README]. This is a meaningful signal about the project’s development model — it’s not a sprawling open contribution project, it’s a tightly controlled codebase maintained by a small core team. That’s not inherently bad, but it means bug fixes depend on that team’s availability and priorities.

---

Pros and cons

Pros

• Single binary, zero dependencies. The cleanest deployment story in the category. No Node, no Python, no Ruby version headaches — download, extract, run [README].
• Multi-instance management. The only open-source qBittorrent UI that handles multiple instances from a single interface. This alone justifies switching if you run more than one qBittorrent [docs].
• Automations engine. Rule-based torrent management (ratio-based deletion, speed limiting by category, tagging by tracker) is genuinely useful and not available in the default UI [docs].
• Cross-seed with autobrr integration. Purpose-built for private tracker users who cross-seed. Integration with autobrr’s webhook system makes it part of an existing automation chain rather than a standalone tool [docs][README].
• GPL-2.0 license. Genuinely free software. No “fair-code” or source-available ambiguity — you can modify, redistribute, and self-host without restriction [README].
• OIDC SSO. Unusual for a torrent UI. If you’ve standardized on Authelia, Authentik, or Keycloak for your home server, qui plugs in cleanly [docs].
• Reverse proxy mode. Lets external tools (*arr apps, autobrr) authenticate through qui rather than holding raw qBittorrent credentials [docs].
• Browser extensions. Right-click-to-send for Chrome and Firefox is a quality-of-life improvement that the default UI and most alternatives lack [docs].
• Incognito mode. Niche but thoughtful — displaying torrents as “Linux ISOs” for screen sharing is the kind of feature that only gets built when the developers actually use the tool [docs].

Cons

• qBittorrent only. Explicitly documented: no support for Deluge, rTorrent, Transmission, or other clients [docs]. If you run a mixed-client setup or want to migrate away from qBittorrent, qui doesn’t help and may become a migration blocker.
• Tightly controlled contributions. Pull requests are restricted to collaborators. Community members can file issues and discussions, but can’t directly contribute fixes [README]. Bug fix pace depends entirely on the core team.
• Premium themes behind a purchase. The free themes cover basic needs, but premium cosmetics being paid is a minor friction point for a GPL-2.0 project. It’s a reasonable monetization model for volunteer developers, but worth knowing before you expect full parity [README].
• No pricing transparency for themes. The theme purchase flow requires running the app to see pricing, which is the least convenient place to put that information.
• Niche target audience. The cross-seed, automations, and multi-instance features are genuinely powerful — for private tracker operators who understand what those words mean. If you’re a casual user, most of qui’s unique features will sit unused, and the default qBittorrent UI is probably sufficient.
• No third-party reviews. At time of writing, there are no substantial independent reviews of qui. You’re trusting the official documentation and GitHub community feedback rather than having a range of external perspectives to triangulate from.
• Version compatibility dependency. qui talks to qBittorrent via its Web API, and not all qBittorrent versions are equally supported [docs]. This adds a layer of version-matching complexity that users of the default UI don’t have.

---

Who should use this / who shouldn’t

Use qui if:

• You run more than one qBittorrent instance and managing them through separate browser tabs is grinding you down.
• You’re on private trackers where cross-seeding matters and you want it integrated into your existing autobrr setup.
• You want rule-based automation (delete when ratio reaches X, pause when disk drops below Y) without writing a separate script.
• You’ve centralized home server auth with OIDC and want torrent management to fit that pattern.
• You care about the reverse proxy mode to avoid sharing raw qBittorrent credentials with Sonarr and Radarr.
• You want a single binary that doesn’t add Docker-layer complexity to an already-complex stack.

Skip it (use the default qBittorrent Web UI) if:

• You have one qBittorrent instance and don’t cross-seed or need rule-based automations.
• You download casually and the existing interface is fine.
• You want software with a larger community and more third-party documentation.

Skip it (use VueTorrent) if:

• You want a modern-feeling qBittorrent interface but don’t need multi-instance or automations.
• You prefer a project with broader community contributions and a less restricted development model.
• Theme and visual customization matters more to you than workflow features.

Skip it (use Flood) if:

• You need a unified UI across multiple different torrent clients (qBittorrent, Deluge, rTorrent, Transmission).
• You’re not locked into qBittorrent and want flexibility to switch clients without changing your management tool.

---

Alternatives worth considering

• qBittorrent default Web UI — functional, zero setup, but no multi-instance, no automations, no cross-seed. Fine for single-instance casual use.
• VueTorrent — popular open-source alternative qBittorrent UI, cleaner design than the default, active community. No automations or multi-instance. Pick this if you want a UI upgrade without the complexity.
• Flood — multi-client UI supporting qBittorrent, Deluge, rTorrent, and Transmission. Better choice if you run a mixed-client setup. Less opinionated about automations than qui.
• autobrr (from the same team) — complements qui rather than replacing it. autobrr handles IRC announces and RSS feeds; qui handles the management interface. They’re designed to work together [docs].
• qBitManage — a CLI-based script for automated qBittorrent tag and category management. Overlaps with qui’s automations feature. Less user-friendly but more programmable.
• Sonarr/Radarr built-in download client management — the *arr apps manage some torrent behavior directly. qui’s reverse proxy mode is specifically designed to integrate cleanly with this rather than compete with it [docs].

---

Bottom line

qui is a focused tool for a specific kind of user: private tracker operators with complex qBittorrent setups who’ve outgrown the default interface. The multi-instance management and cross-seed integration are genuinely differentiated features — no comparable open-source alternative has both. The single-binary deployment is the best in class for this type of tool. The GPL-2.0 license is clean. The automations engine replaces scripts that most serious seedbox operators are already writing themselves.

What holds it back from broader adoption is honest: qBittorrent-only support is a hard wall, the core team controls contributions tightly, and the project is new enough that there’s little third-party evidence to set expectations. But for the person it’s built for — running a multi-instance setup with cross-seeding, autobrr, and a *arr stack — qui is solving a real problem that no other single tool was addressing.

If you’re that person, the download is free, the install takes 15 minutes, and the only thing you’re risking is an afternoon.

---

Sources

1. qui — GitHub README (autobrr/qui, GPL-2.0, 3,516 stars). https://github.com/autobrr/qui
2. qui — Official Documentation: Introduction. https://getqui.com/docs/intro
3. qui — Official Website. https://getqui.com