qBittorrent vs Transmission

qBittorrent tries to be the one torrent app you need. On top of downloading it ships a plugin-based search engine, an RSS reader with auto-download rules (grab anything matching a pattern from a feed), a bandwidth scheduler, IP filtering, sequential downloading, and per-torrent limits, categories, and tags. The desktop build and the headless server build expose nearly all of it. If you want the client itself to find and fetch things, qBittorrent does that out of the box.

Transmission goes the other way. It does one job, download torrents you hand it, and does it with almost no configuration. There is no built-in search and no RSS. That sounds like a gap until you remember how most homelabs actually run: Sonarr and Radarr do the searching and feed the client over an API, so the client only needs to download reliably. For that role, Transmission's simplicity is a feature, not a limitation.

If you are not running the Servarr apps and want the client to handle discovery and automation on its own, qBittorrent is the clear pick. If something upstream is already doing that work, the extra features in qBittorrent are weight you may never touch.

On a server you run both without a desktop. qBittorrent ships qbittorrent-nox, a no-GUI daemon whose web UI is close to a one-to-one copy of the desktop app. You get the full settings tree, drag-to-reorder, categories, the search tab, RSS rules, and live transfer stats in the browser. It listens on port 8080 by default. Newer releases print a temporary random Web UI password to the log on first start if you have not set one, so check the container logs the first time.

Transmission's daemon (transmission-daemon) includes a built-in web client on port 9091, but it is deliberately plain: add a torrent, see a list, basic controls. Many people replace it with a nicer front end such as Flood or Transmission Web Control, which talk to the same RPC backend. That works well, but it is one more piece to run and update. Out of the box, qBittorrent's web UI is simply more capable.

Both have mature Docker images. The LinuxServer.io images for each are the common starting point, and for qBittorrent the binhex arch-qbittorrentvpn image bundles a VPN client, which is a popular pattern. If you prefer to keep the VPN separate, a gluetun container in front works for either client. Either way, run them in containers and manage the stack with something like Dockge or Portainer; if containers are new to you, the Docker vs Podman rundown covers the runtime.

This is where Transmission earns its reputation. The daemon is a small C program that idles in the tens of megabytes of RAM and barely touches the CPU, so it is the natural pick for a Raspberry Pi, an old thin client, or a NAS where you want to spend resources on other services. It will happily seed a large library on hardware that would make a heavier client sweat.

qBittorrent is not heavy by modern standards, but it uses more: figure on roughly 100 to 250 MB of RAM depending on how many torrents are loaded, more with a large active queue. On a mini PC, a real NAS, or any box with 4 GB or more to spare, you will not notice. On a Pi Zero or a 1 GB box running several other containers, you will.

Neither client downloads faster than the other in any way you will see. Real throughput is set by your connection, the swarm, your port forwarding, and disk speed, not by the client. Pick on features and footprint, because speed is a wash.

Both are first-class download clients in Sonarr, Radarr, Lidarr, and Prowlarr. You add the client by host, port, and credentials, and the Servarr app pushes torrents and tracks them to completion. The usual advice to reach for qBittorrent here is about categories: qBittorrent's category system maps cleanly to the per-app folders the Servarr suite expects, so imports and cleanup stay tidy. Transmission supports this too, through labels and a download directory per client, it just takes a touch more care to lay out.

The other reason qBittorrent shows up in so many stack guides is the RSS and search features overlap with what Sonarr and Radarr already do, so you have a safety net and a manual option when an indexer misbehaves. That redundancy is handy while you are still tuning Prowlarr and your indexers.

For a pure hands-off stack where the Servarr apps do everything, Transmission is a perfectly good back end and the lighter one. For a stack you tinker with, or one where you also grab things by hand, qBittorrent's extra surface area pays off. Both ultimately feed a media server like Jellyfin or Plex, and neither choice changes anything downstream of the download folder.

Treat the web interface on either client as something that should never face the raw internet. Transmission's RPC has been the target of real attacks when exposed without authentication, and any torrent client's web UI is a control panel for writing files to your server. Turn on authentication (Transmission has rpc-authentication-required; qBittorrent prompts for a Web UI login), use a strong password, and do not port-forward 8080 or 9091 to the world.

If you need to reach the client from outside the house, put it behind a reverse proxy with TLS, covered in Nginx Proxy Manager vs Traefik, or reach it over a VPN back to your network. For the torrent traffic itself, route the client through a VPN so your home IP is not in every swarm. The binhex qBittorrent-with-VPN image and a gluetun sidecar are the two common ways to do that, and both work with a kill switch so downloads stop if the tunnel drops.

None of this is unique to one client. It is the same checklist for either. The point is that choosing qBittorrent or Transmission does not change your security posture; running it carelessly behind an open port does.