Download
depot / docs / nas & docker

DepotDownloader on a NAS

Running this on a Synology, unRAID, QNAP or TrueNAS box is a great fit — bulk storage for archived games, a place to seed dedicated-server files, downloads that run while your PC is off. The catch is that appliance OSes don't want you installing things into them, so the answer is a container. I run mine this way on my own box, and here's the image plus the three settings (volumes, permissions, login) that make the difference between "works" and "files owned by root in a folder that vanished."

~8 min read| updated june 2026| self-host

01Why a container

NAS appliance operating systems — Synology DSM, unRAID, QTS, TrueNAS SCALE — are deliberately locked down: you're not meant to install arbitrary software or a .NET runtime into the host. Every one of them, though, runs OCI containers (Container Manager, the Docker tab, Container Station, the Apps system). So the clean way to run DepotDownloader on a NAS isn't to install it — it's to run it as a container, where the .NET runtime is already inside the image and nothing touches your host OS. This is the same logic as the Docker recipe in automation, with the NAS-specific wrinkles that follow.

02The image

You have two paths. There's a maintained community image — sonroyaalmerol/steam-depot-downloader (on Docker Hub and ghcr.io), a minimal image wrapping SteamRE/DepotDownloader, multi-arch so it runs on both x86 and ARM NAS boxes. The simplest interactive run looks like:

$ docker run -it --name steamdd \ -v /mnt/user/depots:/out \ ghcr.io/sonroyaalmerol/steam-depot-downloader bash # then, inside the container: $ DepotDownloader -app 440 -depot 441 -manifest <id> -username you -dir /out

Or build your own — the automation page's DIY Dockerfile is a few lines on a slim .NET-free base and gives you a self-contained image you control. Either way, the operational details below are what matter on a NAS.

03The three settings that matter

Three things separate a smooth NAS run from a frustrating one:

  • Volume mounts (persistence). A container's own filesystem is ephemeral — anything not on a mounted volume disappears when the container is recreated. Mount a folder from your NAS array as the download target (-v /mnt/user/depots:/out and point -dir /out at it), so the files land on your real storage, not inside a container layer that evaporates.
  • PUID / PGID (permissions). By default a container runs as root, so the files it writes are owned by root and your NAS user can't move or delete them without a fight. Run the container as your own user's numeric UID and GID (Synology and unRAID expose these as PUID/PGID fields, or use --user 1000:1000 on the command line) so downloads are owned by you. This is the one I skipped my first time, and I spent an annoying evening chasing root-owned files I couldn't delete from the share — set it up front.
  • A second volume for login. If you're downloading owned games (not just anonymous server files), the login token needs to persist too — see the next section.

04Persistent login

Anonymous downloads (free dedicated-server files) need no login and are the easy case. For games you own, DepotDownloader stores a refresh token after the first login so later runs don't re-prompt — but in a container that token lives in the container's filesystem and dies with it unless you mount it. The fix mirrors the automation seeding pattern:

  1. Mount a small persistent volume for the config (so account.config survives), alongside your output volume.
  2. Run the container interactively once (-it … bash) and log in with -username you -remember-password — entering your password and any Steam Guard code at the prompt.
  3. After that, scheduled or detached runs reuse the stored token, no human needed. Treat that config volume as a bearer credential — it's a login, so protect the share it lives on.

05Synology, unRAID, QNAP, TrueNAS

The pattern is identical across appliances — pull the image, set volumes, set the user — only the UI differs:

  • Synology — Container Manager (formerly Docker): add the image, map volumes under "Volume", set PUID/PGID or run via SSH for the interactive login seed.
  • unRAID — add a container from the template/Community Apps style form; the PUID/PGID and path-mapping fields are exactly the ones above. unRAID's /mnt/user/... shares are your target.
  • QNAP — Container Station; same image, same volume and user settings.
  • TrueNAS SCALE — run it as a custom app / container with host-path volumes; SCALE's app system is OCI underneath.

If your NAS is ARM-based (some Synology and QNAP models), the multi-arch community image covers ARM directly; a DIY image just needs an ARM .NET base. No special handling beyond picking an image that has an ARM variant.

06Running it on a schedule

Once the login is seeded, a NAS is a natural home for scheduled jobs — keeping a dedicated server's files current, refreshing an archive. Use your appliance's task scheduler (Synology's Task Scheduler, unRAID's User Scripts, a cron container) to run the container detached on a sensible cadence — nightly with a randomized minute, per the good-CDN-citizen rules. The same failure-handling advice applies: branch on exit code, capture the log, and don't retry policy errors (a request-code refusal won't fix itself by running again). With the volumes and login sorted, the NAS quietly does the downloading your PC used to have to stay awake for. My rule of thumb: seed the login interactively once, confirm a scheduled run actually wrote files owned by my user, and only then walk away and trust it.

the scheduling & scripting sideHeadless automation & CI →