rDownloader runs on a Synology NAS as a container from the published image ghcr.io/degoya/rdownloader, set up as a project in Container Manager. This page walks through it from empty folders to access from outside. The general container reference — every volume, variable and tool — is Docker and NAS.

• DSM 7.2 or later with Container Manager from the Package Center. On DSM 7.0 and 7.1 the package is called Docker and has no project page; the same compose file works there over SSH (sudo docker-compose up -d in the project folder).
• A 64-bit CPU: x86-64 or ARM64. The image exists for linux/amd64 and linux/arm64 only. Models with a 32-bit ARM CPU (ARMv7) cannot run it. Control Panel → Info Center → General names the CPU; over SSH, uname -m prints x86_64 or aarch64 on a supported model and armv7l on one that is not. If the Package Center does not offer Container Manager at all, the model runs no containers.
• Space for the downloads on the volume you mount, and a few hundred megabytes for /config (database, installed plugins, credentials).

The container needs one folder for its state and one for every place downloads go. A typical layout:

/volume1/docker/rdownloader/config     state: database, plugins, credentials, vendor/
/volume1/downloads                     the fallback destination
/volume1/media/movies                  optional: further storage roots

Create them in File Station — docker is the shared folder Container Manager creates, and downloads (or media) is a shared folder of its own made under Control Panel → Shared Folder.

rDownloader writes as the user named by PUID and PGID. That user needs read/write on every folder above: Control Panel → Shared Folder → Edit → Permissions, or File Station → right-click the folder → Properties → Permission.

Two sensible choices:

• Your own DSM user, so the downloads belong to you and are editable over SMB as usual.
• A user created only for the container (Control Panel → User & Group → Create, e.g. rdownloader), with read/write on exactly these folders and nothing else. This limits what the service can reach to what you granted.

Find its ids: enable SSH under Control Panel → Terminal & SNMP, sign in with an administrator account and run

id rdownloader
# uid=1030(rdownloader) gid=100(users) groups=100(users)

uid is PUID, gid is PGID. The first DSM user is usually 1026 and the users group 100, but read the real values — wrong ids are the most common reason downloads fail with permission errors on a Synology.

Not root (PUID=0). The service and every helper it starts — yt-dlp, ffmpeg, 7-Zip — would then run as root with access to every share on the NAS, and its files would belong to root.

Container Manager → Project → Create:

• Project name: rdownloader
• Path: /volume1/docker/rdownloader
• Source: Create docker-compose.yml, and paste:

services:
  rdownloader:
    image: ghcr.io/degoya/rdownloader:v1.7.0
    container_name: rdownloader
    restart: unless-stopped
    ports:
      - "8710:8710"
    volumes:
      - /volume1/docker/rdownloader/config:/config
      - /volume1/downloads:/downloads
      # Every further storage root needs a line of its own:
      # - /volume1/media/movies:/media/movies
    environment:
      PUID: "1026"
      PGID: "100"
      TZ: "Europe/Berlin"
      RUST_LOG: rdownloader=info,rd_=info

Replace PUID, PGID, TZ and the left-hand paths with your own values.

• The tag is a release version (vX.Y.Z); the newest one is on the releases page. A pinned tag changes only when you change it. :latest follows the newest release instead, so a recreated container can move to a new version without you deciding it.
• restart: unless-stopped brings the container back after a NAS reboot unless you stopped it yourself, and after rDownloader restarts itself to apply a plugin installed or updated.
• TZ decides when schedules, quiet hours and bandwidth windows fire; without it the container runs on UTC.
• The health check is built into the image; the compose file needs none.

Leave the optional web portal setting off and finish the wizard: Container Manager pulls the image and starts the container.

Open http://<nas-ip>:8710, for example http://192.168.1.20:8710.

Give it a minute or two. Before it listens, the service installs and loads the bundled plugins, which is slower on NAS hardware. The health check allows 90 seconds, and Container Manager may show the container as unhealthy until then. Container Manager → Container → rdownloader → Log shows progress; the line to wait for is rDownloader listening.

Then the setup assistant opens:

• The password is always required. Switching the administrator login off applies only to requests from the machine's own loopback address, and behind the container's port mapping no request comes from there.
• Storage roots use the paths inside the container — /downloads, /media/movies — never the DSM path. A root at /volume1/downloads is not mounted inside the container: rDownloader badges it NOT PERSISTENT, and everything written there is lost the next time the container is recreated, which includes every update. See Mount every path you use as a storage root.

A further storage root later means: add its volume line to the project, rebuild it (below), then add the root under Settings → Storage & rules → Storage roots.

Do not forward port 8710 in your router. The service speaks plain HTTP; put DSM's reverse proxy in front, which adds TLS and a certificate DSM renews for you.

The certificate. A host name such as rd.example.com has to point at your public address — a DNS record of your own, or a Synology DDNS name under Control Panel → External Access → DDNS. Control Panel → Security → Certificate → Add obtains a Let's Encrypt certificate for it. Your router forwards port 443 to the NAS.

The proxy rule. Control Panel → Login Portal → Advanced → Reverse Proxy → Create:

No custom headers are needed: the live updates are Server-Sent Events, not WebSockets, and keep within DSM's default timeouts. Afterwards assign the certificate to the new entry under Control Panel → Security → Certificate → Settings.

Tell rDownloader about it. Under Settings → Security → Reachability & reverse proxy:

• External URL — https://rd.example.com. This makes the session cookie Secure, and it is what passkeys are bound to.
• Trusted proxies — the container network, 172.16.0.0/12. DSM's proxy reaches the container through the port mapping, so its requests arrive from Docker's bridge, not from loopback. sudo docker network inspect rdownloader_default over SSH shows the actual range.
• Allowed host names — the external URL's host, any IP address and a name that exists only on the local network — a single label such as diskstation, or a name under .local, .home.arpa or .internal — are always accepted. Any other name you open the service by, such as nas.example.com, is refused with 403 and request.host_not_allowed until it is listed here, one bare name per line. Open the interface by its IP address to add one.

The details are on Reverse proxy.

1. Take a full backup first. Backup and restore describes the scheduled full backup and Back up now. Its Folder or NAS destination must be a mounted path, for example - /volume1/backup/rdownloader:/backups in the project and /backups as the folder.
2. Change the image. With a pinned tag, stop the project, change the tag in its YAML (Container Manager → Project → rdownloader) and rebuild it; Container Manager pulls the new image and recreates the container. With :latest, Container Manager → Image offers the update for the image when a newer one exists.
3. Wait for rDownloader listening in the log, as on the first start.

Everything in /config stays — database, settings, plugins, credentials — and so do the downloads on their volumes. The database migrates forward only: the first start of a new version updates it, and an older version is not designed to run on it afterwards. Going back means the older tag and the backup taken before the update.

The image brings ffmpeg, yt-dlp, streamlink, gallery-dl, 7-Zip with the RAR codec, par2 and Apprise, so media downloads, streams, galleries, unpacking, PAR2 repair and Apprise notifications work without installing anything on the NAS. Settings → Tools → Status shows each version and where it was found.

yt-dlp ages fast. A newer binary dropped into /volume1/docker/rdownloader/config/vendor (that is /config/vendor inside the container) is used before the bundled one. rclone is not in the image; it goes there too if you use it. See External tools.

The desktop capture agent does not run on the NAS; the browser extension is its companion there. Press Pair under Settings → Clients & API → Browser, and enter the token and the NAS's address in the extension's options — http://192.168.1.20:8710 at home, or https://rd.example.com through the reverse proxy — then Test connection and Save. The browser asks once for permission to reach that address.

Over plain HTTP the token travels unencrypted, so outside your home network use the https address. The desktop capture agent, run on your PC against the NAS, refuses a non-https address at pairing time for the same reason.

More in Troubleshooting.

• Docker and NAS
• Reverse proxy
• Backup and restore
• First run
• Browser extension