Archiving your Steam library with DepotDownloader

01The honest part first

Two things to get straight before any commands, because they change what you should even attempt.

This is personal backup of games you own. DepotDownloader downloads content your account holds a license to — that's the whole mechanism, and it's the whole permission. Archiving the games in your library is the legitimate, sensible thing this page is about. It does not let you keep a game after a refund (the license is gone), and it does not let you download something you never bought. If that's what you were hoping for, the honest answer is here, not a workaround.

You don't need to mirror everything, and shouldn't. A modern library is many terabytes; trying to archive all of it is a storage project, not a preservation one, and most of it is effort spent guarding against a risk that doesn't exist — Steam will happily re-serve your currently-listed games tomorrow, next year, after a reinstall. The content worth your disk space is the small slice that's genuinely going somewhere.

02What's actually worth keeping

Archival is triage. Sort your library into three buckets and only the first two deserve a backup:

Bucket	Risk	Archive?
Delisted games you own	Pulled from the store; future availability not guaranteed. Steam keeps them in your library for now, but a delisted title is the textbook at-risk case.	Yes — top priority
Games with a version you care about	A bad patch broke your mods, your save format, or multiplayer with friends, and the old build is what you actually want to keep.	Yes — pin the build
Currently-listed games, current version	None worth planning around. Steam re-serves these on demand.	No

The first bucket has its own walkthrough — archiving delisted games you own — and is the strongest reason to do any of this. The second is the entire downgrade side of this site: a specific old build, pinned by manifest, which the universal downgrade guide and the preservation tiers map out game by game — and it isn't only games, since the same manifest pinning is how you handle downgrading non-game software on Steam when an app update breaks your workflow. If you find yourself adding bucket-three games "just in case," stop — that's the instinct that turns a useful archive into an unfinishable one.

03There's no "download everything" button

Worth saying plainly because people look for it: DepotDownloader takes one app per run. There is no -all-apps, no "download my library" flag, and the tool can't even list what you own — it only fetches IDs you hand it (a long-standing limitation, issue #260). So "archive my library" really means: get a list of app IDs, then loop the tool over it. That's two jobs — building the list, and running the loop — and the next two sections are exactly those.

04Getting the list of what you own

Since DepotDownloader won't enumerate your library, you produce the app-ID list elsewhere:

The Steam Web API. IPlayerService/GetOwnedGames returns your owned app IDs as JSON. You need a free Web API key and your SteamID64, and your profile's game details must be public:
https://api.steampowered.com/IPlayerService/GetOwnedGames/v0001/?key=YOURKEY&steamid=7656119XXXXXXXXXX&include_appinfo=true&format=json
Pull the appid values out of that and you have your loop input.
SteamDB's calculator. steamdb.info/calculator reads a public profile and lists owned apps — handy for eyeballing and for grabbing IDs without writing code.
steamctl. The Python sibling tool (in the ecosystem) has the enumeration DepotDownloader lacks: steamctl apps list ("list owned or all apps") and steamctl apps licenses list for true entitlements. If you're scripting many apps, it's a natural way to generate the list — and the comparison page covers where each tool fits.

One nuance worth knowing: "games you own" (apps) and "licenses you hold" (packages) aren't identical — bundles, free weekends and family content blur the line. The same is true of bonus content like soundtracks: a game's OST and soundtrack files often live in their own depot or DLC app, so archiving them is its own small job worth doing alongside the game. For a personal archive the owned-apps list is plenty; only license-level archaeology needs the authenticated licenses list route.

05The loop — and the two gotchas that bite

With a list in hand, the pattern is a plain shell loop: authenticate once, give each app its own folder, and pace it. A bash example:

$ for app in 220 400 620 do
    ./DepotDownloader -app $app -dir ./archive/$app \
        -username you -remember-password -max-downloads 4
    sleep 30
  done

The -remember-password on the first iteration stores a session token, so the rest of the loop doesn't re-prompt for login or Steam Guard (the authentication page covers what's actually saved). On Windows the same shape works as a PowerShell foreach. Now the two things that trip up everyone who scales this up:

Gotcha 1 — give every app its own -dir, always

If you don't set a distinct -dir per app (and ideally per manifest), files with the same name across different games or versions overwrite each other — the exact footgun reported in issue #148. A per-app folder like ./archive/$app isn't tidiness, it's correctness.

Gotcha 2 — Steam rate-limits a long run

Hundreds of back-to-back requests will eventually earn a RateLimitExceeded (also issue #148). One person reported throttling after roughly 110 manifest requests followed by about an hour's cooldown (issue #674) — not an official number, but the right order of magnitude to plan around. Two defences: pace the loop (the sleep above), and stay logged in with one session rather than re-authenticating each run, which compounds the limit. If you parallelise, each concurrent instance needs its own -loginid or they'll knock each other's connection out.

The takeaway: this scales to a curated few dozen at-risk games comfortably. It does not scale to "kick off all 900 tonight" — both the rate limit and the terabytes are telling you the same thing the triage did.

06Cataloging cheaply with `-manifest-only`

Before you spend disk on anything, there's a near-free move that's perfect for an archivist: -manifest-only downloads a human-readable file list for a depot without fetching the content. It writes a manifest_<depotid>_<manifestid>.txt into the output folder, listing every file with its size and hash.

$ ./DepotDownloader -app 220 -depot 221 -manifest ... -manifest-only

Two good uses. First, build an index of what a game contained at a given version — a catalog you can keep even for builds too large to store, and the same file-list view is the starting point for datamining a game's assets when you want to know what's inside before fetching it. Second, and more practically, record exact manifest IDs so you can pin a specific build later with -manifest (the durable lock the branches reference argues for over a moving branch). It costs almost nothing per app — though note it's a request like any other, so the same rate limit applies if you sweep hundreds at once.

07Keeping it fresh, and what not to use

Refreshing an archive is cheap by design. DepotDownloader keeps a .DepotDownloader folder in each output directory recording which manifest you have; re-run the same command and it compares against the live build and pulls only the changed chunks, not the whole game again. So a "keep my at-risk games current" job is just the same loop on a schedule — the automation page has the systemd/cron recipes for that. One caveat if your archive's whole point is an old build: pin it with -manifest and keep that copy separate from any auto-refreshing folder, so a refresh never quietly walks it forward.

And two things people reach for that are the wrong tool here:

SteamPrefill is not an archiver. It looks adjacent — it downloads games — but it deliberately writes nothing to disk; its job is warming a Lancache, not keeping files. Point it at your library and you'll get a warm cache and an empty drive.
Copying steamapps/ isn't an archive. It only captures what you have installed, at the current version, and without the appmanifest_*.acf files Steam may not even recognise the copy. It's a folder of the present moment — the opposite of what you're trying to preserve.

So: archive the at-risk slice, not the whole shelf. Build a list, loop with a per-app -dir and a sleep, catalog cheaply with -manifest-only, pin the old builds you actually care about, and let the incremental update keep the rest current. That's a real, maintainable preservation copy of the games you own — which is the only kind worth having.