TideTorrent downloads with a calmer control surface

Install with Docker Compose

Tide listens on port 3000 inside the container. This example binds it to loopback on port 3001, which is the right default until you have set a username and password:

services:
  tide:
    image: getcoral/tide:latest
    restart: unless-stopped
    user: "${PUID}:${PGID}"
    ports:
      # loopback only until TIDE_AUTH_USERNAME / TIDE_AUTH_PASSWORD are set
      - "127.0.0.1:3001:3000"
    environment:
      TIDE_DATA_DIR: /data
      TIDE_DOWNLOADS_DIR: /library/downloads/complete
      TIDE_MEMORY_LIMIT_MB: "4096"
      TIDE_MEMORY_PAUSE_MB: "3584"
      TIDE_MEMORY_RESUME_MB: "3072"
    volumes:
      - ./tide-data:/data
      - ./library:/library
    mem_limit: 4g
    networks: [coral]

Two things in there are load-bearing rather than decorative.

mem_limit is required. Tide reads the container’s memory cap from cgroups and pauses torrents as it approaches it. With no limit set there is nothing to read and nothing to pause against, and a big swarm will happily consume whatever the host has.

./library is one mount, not several. Tide derives its in-progress directory as a sibling of TIDE_DOWNLOADS_DIR, so /library/downloads/complete implies /library/downloads/incomplete. When both sit under the same mount, finishing a torrent is a rename — near-instant, no extra disk. Mount them separately and every completed download turns into a full copy. The same rule is why Librarian and Jellyfin mount that identical ./library tree at the identical path.

For a quick look without Compose:

docker run -p 3000:3000 \
  -e TIDE_DOWNLOADS_DIR=/downloads \
  -e TIDE_AUTH_USERNAME=admin \
  -e TIDE_AUTH_PASSWORD=change-me \
  getcoral/tide:latest

Queue control, not just a list

Most torrent web interfaces show you a table and let you start things. Tide’s default view is a board built around the questions you actually ask: what is running right now, what is waiting, what has stalled, and what is seeding past its goal.

The limits are enforced rather than advisory. Set a maximum number of active downloads and active seeders and Tide holds the rest in a queue, promoting them as slots free up. Default ratio and seed-time goals apply to every torrent as it arrives, so you are not configuring retention one item at a time.

When you do need the deep view it is there: per-file priorities driven by piece selection, a compact piece map showing exactly what has landed, tracker health, and the peer list. That detail is one click away rather than being the default surface.

Access control

Tide has no authentication on by default, which is why every example here binds it to loopback. There are two ways to open it up.

HTTP basic auth is the simple one — set TIDE_AUTH_USERNAME and TIDE_AUTH_PASSWORD and you are done. The other is Jellyfin sign-in, added in 1.3.0: point TIDE_JELLYFIN_URL at your server and people sign in with the Jellyfin account they already have, with torrent management restricted to administrators. Tide uses Jellyfin purely as an identity provider and stores no API key for it.

If you lock yourself out, TIDE_REQUIRE_LOGIN=false overrides whatever is in SQLite and gets you back in.

Tide vs qBittorrent

qBittorrent is the default answer for self-hosted torrenting, and for good reason: it is mature, it has an RSS engine, and every guide and every *arr integration assumes it. If you are building an automated acquisition pipeline today, that ecosystem is a real argument.

Tide is aimed at the person running downloads by hand who finds that interface heavier than the job warrants. The queue rules are first-class rather than buried in settings, the memory guard is built in rather than something you enforce from outside, and Jellyfin sign-in means one fewer separate credential. It is also one container with no plugin layer.

Where qBittorrent wins outright: RSS automation, maturity, the breadth of tooling that already speaks to it, and the ability to pin a version. The full side-by-side is in Tide vs qBittorrent.