Transmission

Last reviewed Sep 13, 2026 · 792 words

Transmission is the BitTorrent client you run when you want a daemon that costs 50 MB of RAM, gets configured once, and is then driven entirely by Radarr, Sonarr and a phone app over its RPC. It has fewer knobs than qBittorrent and no built-in search, and that is the point. The one thing that catches everyone in the first hour: the daemon writes its own settings.json on shutdown, so any edit you make while it is running gets silently overwritten. Stop the daemon, edit, start. Every "my config change didn't stick" thread on the internet is this.

The daemon and the two ports

transmission-daemon is the headless process. The web UI on port 9091 and every remote client (Transmission Remote GUI, the iOS and Android apps, transmission-remote on the CLI) talk to it over the same JSON-RPC on that port. Peers connect on 51413, TCP and UDP, and that is the port to forward or, better, to leave unforwarded behind a VPN container. The linuxserver image is the common route:

services:
  transmission:
    image: lscr.io/linuxserver/transmission:latest
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Etc/UTC
      - USER=admin
      - PASS=long-random-password
    volumes:
      - ./transmission-config:/config
      - /srv/data:/data
    ports:
      - "9091:9091"
      - "51413:51413"
      - "51413:51413/udp"
    restart: unless-stopped

The single /data mount is the same rule as everywhere in the arr stack: downloads and library on one mount, so imports hardlink rather than copy. Version 4, the C++ rewrite, made the web UI usable on a phone and improved throughput when seeding thousands of torrents, and it is what every current package ships.

settings.json, edited the right way

The keys that matter live in one file. rpc-authentication-required: true with rpc-username and rpc-password; the daemon hashes the password on next start and rewrites the file, which is the overwrite behaviour working for you for once. rpc-whitelist-enabled defaults to true with 127.0.0.1 only, so a container on a Docker network needs the whitelist widened or disabled, and forgetting this produces a "403: Forbidden" page in the browser. download-dir and incomplete-dir both belong under /data. ratio-limit with ratio-limit-enabled handles seeding targets, and speed-limit-up in KB/s keeps a home upload usable for everyone else in the house. alt-speed-enabled with alt-speed-time-begin and alt-speed-time-end (minutes after midnight) gives a scheduled slow mode for the evening, and blocklist-url pulls a peer blocklist on startup if you want one. When the daemon is up, change settings through transmission-remote or the web UI rather than the file.

Feeding the arr stack over RPC

Radarr and Sonarr have Transmission as a first-class download client: host, port 9091, username, password, and a category, which Transmission implements as a subdirectory rather than a label. Watch folders (watch-dir-enabled) let a script or browser extension drop .torrent files into a directory and have them picked up, which is the poor person's automation and works fine. The RPC has no per-torrent tags or categories in the way qBittorrent does, so tooling that filters on those (some post-processing scripts, cross-seeding helpers) either understands Transmission's directories or does not support it at all. Check before committing.

Transmission or qBittorrent

qBittorrent has the built-in search, RSS auto-download rules, categories and tags, sequential download, and a web UI that exposes nearly every option the desktop app has. It also idles around 100 to 200 MB and carries a much larger web UI, which is more surface to keep patched if it is ever reachable beyond the LAN. Transmission has none of the extras, 50 MB of RAM, a small attack surface, and a codebase that has shipped in every major Linux distribution for well over a decade. If the arr apps do all the deciding and the client's only job is to move bytes, the features Transmission lacks are features you were never going to use.

What I'd do

Transmission on any box where RAM matters or the client is purely a back end for Radarr and Sonarr: the daemon in a container, RPC auth on, whitelist covering the Docker network, peer traffic through a VPN container rather than a forwarded port, one /data mount, and a ratio limit set the day it goes live. qBittorrent only when I personally want to manage torrents by hand with RSS rules and tags. Among the media-server plumbing, it is the piece I have never had to think about after the first evening, which is the highest compliment a daemon can get.